Learning these 5 microservice patterns will make you a better engineer

For a lot of engineers, getting into microservices can be tough, because it’s hard to decide where lines should be drawn. For me, 99% of services fall into one of five categories, and dividing the responsibilities this way allows you to think of how to engineer features by piping pieces services together kinda like you would do in Unix shell scripting.

Let’s for a moment talk about what all microservices have in common. Eric Evans, the father of Domain Driven Design, defines them as the following: “[services] that can consume and produce messages.”

With that in mind, for each service pattern, I will talk about the types of messages that are produced or consumed.

These messages again, can be subdivided into two categories: Events, and Commands.

Before we get started though, and because context is important, I first heard of these microservice patterns from Matt Walters, the creator of the library servicebus. Servicebus is a Node adaptation of a popular .Net library called NServiceBus, which was created and popularized by Udi Dahan.

Servicebus allows you to easily write send and listen commands, and publish and subscribe events using AMQP as a universal language, with JSON payloads. This means other programming languages could easily implement the same interfaces and be able to seamlessly participate in a system composed of parts written in many languages.

If you’re a Go, or Python developer, who would like to contribute to that cause, send me a message!

And without further ado, the 5 microservice patterns.

1. Model Services

If MVC comes to mind, then you are on track with this type of service. The Model Services are where your models should live. The boundaries are typically made at the Aggregate or Entity level, depending on the complexity of the domain.

Model services consume messages about things that are relevant within their context. For example, if you had an Inventory Service, some command messages that would be relevant to consume would be inventory.product.create, or inventory.product.increaseStock. In response, you’ll want to produce some Event messages so the rest of the system can be aware of how the model is changing, and respond to those changes. The event messages produced in this example would be inventory.product.created and inventory.product.stockLevelIncreased.

2. Denormalizer Services

Denormalizers are exactly what Relational databases are doing, except, for a distributed system. They are joining together multiple normalized sources of input into a readable data structure that a client can consume.

For example, imagine you have an e-commerce app. When stock levels increase or decrease, or, become available in your inventory, your application should know about it.

This means with a denormalizer service you are subscribing to the events being emitted from the Model service above, and if you are using MongoDb, using something like mongoose to persist that data in a perfect structure for that particular application to consume.

Imagine if you’re application engineers are using something like Meteor with MongoDB — they just got real time inventory from an external system without having to write a line of code. This also works great with RethinkDB paired with GraphQL subscriptions!

3. Gateway Services

Gateway Services can be used very similarly to Denormalizers. Instead of connecting to a database, however, it is a connection to an API.

I was recently working with a recommendation engine, called LiftIgniter, with which our inventory needed to be synchronized. The service subscribes to inventory.product.updated and inventory.product.added events, and simply POSTs the formatted data to the appropriate endpoints.

Later on, an additional service was added that listened for the same events, and by building a Magento Gateway service, we were able to keep an ecommerce store up to date with the changing inventory levels as well!

4. Ingestor Services

All we’ve talked about so far is working with data that is propagating through the system, or created in Model services. However, it’s a frequent requirement to get external data INTO the system. Conceptually, data from an outside source needs to be ingested into the universal language the rest of the system speaks. This is the job of an ingestor service.

Ingestor services are typically only producing messages. These services usually involve either receiving an API POST over HTTP, or, running a CRON job, and scraping at an interval. The fetched or received data is then published to the system using the universal language (AMQP w/ JSON).

5. Adapter Services

An adapter service is a more rare use case, but worth mentioning. Similar to a Gateway service, an Adapter consumes messages, then uses that data to invoke a library on the system. An example of this might be using a graphics manipulation tool like ImageMagick. ImageMagick is a powerful tool, but does not have Node.js bindings. An adapter service solves this by executing a child process, and then producing messages with the results, in the universal language of the system.

Unidirectional Systems

Using these above patterns allow you to work with immutable events in a unidirectional workflow. If you’re into application development, you are no doubt familiar with how Redux has changed the game for state management. Having one store with state that trickles down the component tree allows you to easily reason about how actions affect the state because they are simple immutable facts that all occur in a centralized location.

If you follow the above patterns, you will be using what is sometimes more complicatedly called Command Query Responsibility Segregation, or CQRS. Commands are consumed by Model Services, and Events are produced that are consumed by Denormalizer or Gateway Services.

Because you are using immutable messages, this makes Event Sourcing the perfect pattern for building your Model services. Another creation of Matt Walters worth checking out, is a micro-framework called [sourced](https://github.com/mateodelnorte/sourced) that works perfectly in harmony with servicebus, to easily add Event Sourcing capabilities to consume your service’s Events, and persist them to a database.

Conclusion

Finally, it’s worth mentioning, that with simplicity of services, some complexity is necessarily moved to the architecture. Hopefully I’ve provided you a way of mentally building microservice systems in your head with some generic lego blocks.

If you haven’t read my other article, “What makes a microservice architecture?” read that as well! It covers the components that make a microservice architecture.

If you want to skip the part where you spend months learning how to set this all up yourself, I am preparing a web course that will show you how I’ve systemized the process, and codified the system, so you can be up, running, and efficient with Microservices in the quickest time possible! Sign up now to get access before everyone else! Visit Microservice Driven for info!

Thanks for reading! If you follow me and give me 50 claps so it would really help me reach more people! Click and #HODL the clap button below ;)

For information about consulting, send me a message on LinkedIn.

Learning these 5 microservice patterns will make you a better engineer was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.