From The Tao of Microservices by Richard Rodger

The term microservices invites you to think in terms of services. You are naturally drawn to ask the question, What are the microservices in this system? Resist that temptation. Microservice systems are powerful because they allow you to think in terms of messages. If you take a messages-first approach to your system design, you free yourself from premature implementation decisions. The intended behavior of the system can be described in terms of a language of messages, independent of the underlying microservices that generate and react to those messages.


Save 37% on The Tao of Microservices. Just enter code fccrodger into the discount code box at checkout at

Messages are first class citizens

A messages-first approach is more useful than a services-first approach to system design. Messages are a direct expression of intent. Business requirements are expressed as the activities that should happen in the system. Strangely, we are traditionally taught to extract the “nouns” from business requirements, so that we can build objects. Are business requirements really so obscure? Perhaps we should pay more attention to the activities they describe.

If you take business requirements and break them down into activities, this naturally suggests the messages within the system. Messages represent actions, not things. Take, for example, a typical e-commerce website. You put some items in your shopping cart, and then you proceed to checkout. On checkout, the system records the purchase, sends you an email confirmation, and sends the warehouse a delivery instruction, among other things. Doesn’t that just naturally break down into some obvious activities? How about: checking out; recording the purchase; sending an email confirming the purchase; and delivering the goods. You’re one step away from the messages that contain the data that describe these activities.

Write down the activities in a table, and write down a code name for each activity (that gives you a name for the message), and write down the data contents of the message. By doing this, you can see that there’s no need at this level of analysis to think about which services will handle these messages. An example of this can be seen in table 1.


Table 1: Messages representing activities

Analytical thinking in terms of messages can scale, in the sense that you can develop a good understanding of the system design at this level.

  1. Designing the system in terms of services does not scale in the same way. Although there are fewer kinds of services than messages, in practice it’s hard not to think of them from the perspective of network architecture.
  2. You have to decide which services talk to which other services. You have decide which services handle which messages. You have to decide whether services observe or consume messages.

Additionally, you end up having to think about many more different kinds of things. Even worse, you end up making premature architectural decisions. And even worse again, your thinking is static from the start, rather than allowing you to adapt message behavior as requirements change and emerge.


The quality of “good” in this sense means that your understanding generates “true” statements.

That is, statements that the business stakeholders will agree with.

Adrian Cockcroft, a former Netflix engineer, and proponent of microservices, likens the network and server centric view points as being analogous to keeping pets. You care about your pets, and know them by name. Microservices, in contrast, are like a herd of cattle, and need to be treated as such.

You can see an example of using messages to take business requirements to technical specifications in terms of system design (figure 1).

Figure 1: Conceptual levels of system design.

That’s all for this article.

For more on Microservices, check out the whole book on liveBook here.