Currency Conversion: Synchronous RPC vs Dataflow (local replica) Diagram

A purchase event arrives; the item is priced in one currency but paid in another, so the processor needs the current exchange rate
It calls the exchange-rate service with a synchronous request/response and blocks until the rate comes back
The call adds latency to the purchase and introduces a failure dependency on another service
A local cache would avoid the call — but keeping that cache fresh requires polling for updates or subscribing to a change stream anyway

The purchase processor subscribes to the stream of exchange-rate updates ahead of time
Whenever the rate changes, the update is pushed and recorded in a local database inside the processor
When a purchase event arrives, the processor queries this local replica — no network call at all
The fastest, most reliable network request is no network request

Instead of RPC there is now a stream join between purchase events and rate update events
The join is time-dependent: the exchange rate at reprocessing time differs from the rate at purchase time
Reconstructing the original output requires the historical exchange rate at the original time of purchase
This time dependence must be handled either way — whether you query a service or subscribe to a stream