When a remote call should become a local rule
A calculation calls another service fourteen times for one answer. Is the problem the network or the design?
In service systems the hidden cost is the multiplication of calls. A loop preparing the data of fourteen add-ons and querying a service for each one is slow because it does fourteen times a job that can be done once. Twelve calls at 150 milliseconds cost more than one at 200.
The two moves
The first is batch loading. A facts registry gathers in advance everything the calculation will ask for and fetches it with a single query, then the loop reads from memory. Fourteen preparations become one: about 1.8 seconds less on the slowest path, and overall response time down by 30%.
The second is moving the rules. If a remote service is called only to answer yes or no to a blocking rule, and the rule depends on data the caller already has, the rule can live in the caller. You remove a network call from every offer evaluation, and remote latency disappears from the path.
The criterion
A remote call is justified when the other service owns data or decisions the caller must not know about. When instead the caller already has everything and only asks for a rule to be applied, it is paying for the network for nothing. The question to ask is who owns the rule. If the answer is the caller, you bring it home.
The next step, when the remaining latency lies in data volume, is the progressive response: showing the first offers while the rest arrive. It lowers perceived latency without touching the calculation.
Describe the system. We'll tell you what we see.
Ten minutes, one question at a time. At the end, our honest read of the case. It's the filter, before the call.