Before we go further into distributed systems in regard to consistency and scalability, let's look at an example of how consistent the real world is. Enterprise applications are typically built with the aspiration to provide full consistency. The real world, however, is highly distributed and not consistent at all.

Imagine you're hungry and you want to eat a burger. So you go to a restaurant, sit at a table, and tell the waiter that you would like to have a burger. The waiter will accept your order. Now, although your order has been accepted this doesn't necessarily mean that you will receive your meal. The process of ordering a meal is not fully consistent.

A lot of things can go wrong at this point. For example, the chef may tell the waiter that unfortunately the last burger patty was just used and there won't be more burgers for the day. So although your order has transactionally been accepted, the waiter will come back and tell you that the order won't be possible.

Now, instead of asking you to leave, the waiter might suggest to you an alternative dish. And if you're hungry and fine with the substitute you might eventually receive a meal.

This is how the highly distributed real world handles business use case transactions.

If the restaurant would be modeled in a fully consistent way the scenario would look different. In order to guarantee that an order is only accepted if it will be possible to provide the prepared meal, the whole restaurant would need to be locked down. The customers would have to wait and hold the conversation while the waiter goes into the kitchen and orders the meal from the chef. Since many other things can go wrong after ordering, the whole order transaction would actually have to block until the meal is fully prepared.

Obviously, this approach would not work. Instead, the real world is all about collaboration, intentions, and eventually dealing with issues if the intentions can't be fulfilled.

This means that the real world operates in an eventually consistent way. Eventually, the restaurant system will be in a consistent state, but not necessarily at all times, which leads to initially accepting orders that are actually not possible.

Real-world processes are represented as intentions or commands, such as ordering a burger, and atomic outcomes or events, such as that the order has been accepted. Events will then cause new commands that result in new outcomes or failures.