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?
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).