Now back to the topic of distributed systems. In the same way as for a restaurant, distributed systems that communicate in a consistent way, via distributed transactions, won't be able to scale.

Event-driven architectures solve this issue. The communication in these architectures happens via asynchronous events that are published and consumed reliably.

By doing so, consistent use case transactions get split up into multiple, smaller-scaled transactions that are consistent in themselves. This leads the overall use case eventually being consistent.

Let's see an example of how the use case of ordering a burger is represented in an event-driven architecture. The restaurant system consists of at least two distributed applications, the waiter and the chef. The restaurant applications communicate by listening to each other's events. The client application will communicate with the waiter in order to initiate the use case:

The client orders a meal at the waiter application, which results in the OrderPlaced event. Once the event has been published reliably, the orderMeal() method's invocation returns. The client therefore is able to perform other work in parallel.

The chef system receives the OrderPlaced event and validates whether the order is possible with the currently available ingredients. If the order wouldn't be possible, the chef would emit a different event, such as OrderFailedInsufficientIngredients. In that case, the waiter would update the order status to failed.

When initiating the meal preparation was successful, the waiter receives the MealPreparationStarted event and updates the status of the order, what results in OrderStarted. If the client would ask the waiter about the status of their order, it could respond appropriately.

At some point the meal preparation would have been finished, resulting in a MealPrepared event, which notifies the waiter to deliver the order.