Asking another service for data

Each service owns its data, so sooner or later one service needs something another one holds. Orders wants to know whether Inventory has stock, or Notifications needs a customer’s email address. There are four ways to get it: a direct call, request-reply over messages, a fat event, or a local read model. They trade freshness against independence.

The four ways

A direct call is an HTTP or gRPC request to the owner. The answer is current and immediate. If the owner is down or slow, the caller is too, so it needs a timeout and a plan for failure (see retries and backoffRetries and backoffRun a failed message again after a growing, randomised delay, and stop after a limit.Opens in a new tab).

Request-reply does the same over messages. The requester sends a request to the owner’s queue and waits for an answer on a different one. Two things make that work: a correlationId in the request, copied into the reply, so the requester can match each reply to the question it asked, and a replyTo address that tells the owner where to send the answer. The Enterprise Integration Patterns catalogue calls these the Correlation Identifier and the Return Address.

// The request names who is asking and where to send the answer.public record GetStockLevel(Guid CorrelationId, string ReplyTo, string Sku); // The reply carries the same CorrelationId back.public record StockLevel(Guid CorrelationId, string Sku, int Available);

The owner reads ReplyTo, looks up the stock level and publishes a StockLevel to that address with the same CorrelationId. Azure Service Bus messages have built-in ReplyTo and CorrelationId properties, so a library is not required to do this. The request can wait in the queue while the owner is down, but the caller still has to give up after a timeout, and a late or duplicate reply has to be ignored. Microsoft’s guidance notes that waiting on the reply effectively turns the exchange back into a synchronous one.

A fat event avoids asking at all: the data arrives with the event, as described in event notification vs state transferEvent notification vs state transferA thin event says that something happened. A fat event also carries the data.Opens in a new tab. It suits data used once, in the flow that the event starts, such as the shipping address on OrderPlaced.

A local read model is a table the consumer fills from the owner’s events and queries as often as it likes. Notifications can keep a small table of customer emails, updated from CustomerRegistered and EmailChanged, and never call the Customers service. It is the read side of CQRSCQRSSeparate models for changing data and for reading it.Opens in a new tab. Building it needs the owner’s events to be replayable, or a one-time copy of the existing data to start from (see broker vs event streamBroker vs event streamA broker hands messages out and removes them once acknowledged, a stream keeps a log that consumers read at their own pace.Opens in a new tab).

Which one

The catch

The first two keep one owner and one copy, and they couple the caller to the owner’s availability. The last two remove that coupling and leave copies that can be stale (see eventual consistencyEventual consistencyAfter a change, other services catch up later, and the design has to allow for the gap.Opens in a new tab). Do not copy data that a decision depends on being exact, such as the stock level used to accept the last unit. Ask the owner, or let the owner make the decision.