When eventual consistency is a problem for one service, but no other?

Question

I have a Sales service, which takes payments and raises events when a sale is confirmed.

I have an Order service, which consumes this event and records everything that was purchased as part of the trade. Therefore this purchased information is eventually consistent shortly after a sale has been confirmed.

The nice thing about this architecture is that the Sales service has huge volume demand on it, so making it as lightweight as possible is ideal.

Problem is... when a sale is confirmed the Sales service needs to know what has been purchased before any further trade can take place for that customer. This is because there are limits on how many items they can buy etc, and other constraints. It can't rely on the Order service to provide this information at any time, as there may be a backlog in processing orders.

I could solve this by having the Sales service also record all this information immediately when a sale is confirmed, but then I'm introducing substantially more logic and processing into the Sales service. In addition to writing the event,it's now calculating everything purchased as part of the order and pushing it all into its database.

Are there any patterns for solving these types of problems? Am I effectively forced to make the Sales service also understand how to process and store Orders?

Answer 1

If the order service depends on events from the sales service to make decisions and the sales service needs to be strongly consistent with decisions made by the order service, that strongly suggests that they are in fact the same service. If they happen to be deployed separately, they form a distributed monolith (quite possibly the worst of both worlds).

Answer 2

Your choices are either building a monolithic application that uses a single database or embrace eventual consistency and rely on compensations if things go wrong.

Note that in any non-toy application you have to support compensations anyway. For example, the last item that was promised to the customer was damaged during packaging. It would require the order to be canceled or delayed. Handling of such a situation is not much different from the sales service handling not up to date information about the item availability.

Handling all such edge cases is practically impossible when using queues and independent services. It becomes a tractable problem when employing a centralized orchestration solution like temporal.io.

Disclaimer: I'm tech lead of the Temporal open source project.