Designing architecture for a scalable system always involves thinking asynchronous parts. For example: placing an order to a system. At first sight this process of course requires feedback. What happens if the order is invalid because it contains incorrect data? Especially for the non-technical stakeholders it is hard to imagine how this can be accomplished. Therefor it is always helpful to have an example that is taken from the non- technical world.

I often tend to take examples from the gastronomy branch. Its plain clear why: everybody has to eat.

Have you ever you ever ordered a menu in a fast food restaurant?

Did it ever happen to you that at least one part of the menu was not on stock? What happens in that situation? Do you stay waiting in the queue - blocking other people from placing their order and blocking business to be made by stopping the sale of more food? No! What you get instead of the missing piece is information that indicates that they still owe you. When the missing part is ready you can exchange the information for the missing menu part. How the exchange is instantiated depends on the restaurant.

In most coffeehouse’s they will call your name, prior written on the cup; others will deliver to your desk.

A question of culture, communication and message exchange patterns (MEPs).