Microservice architecture patterns

Why do you need a microservice architecture?

Decrease blast radius of problems and increase flexibility.
You want technology diversity in your company.
You want to scale your app more granular according to consumer needs.
You want newcomers to be productive earlier.
You want your company structure to be mirrored with technical responsibilities (it’s mainly about SOA in general, not only about microcervices; more on that).

What is a microservice oriented application

It is a set of small loosely coupled services, which communicate with each other through some protocol (defined in a policy).
Each service has its own storage (DB) and can be developed and deployed independently.


While making your service simpler, this approach makes your entire application architecture more difficult.
You have to deal with partial failures, slower responses caused by more network interactions.
Cross-service features are harder to develop and release.
The major problem is data consistency problem. When you have to store some change (commit a transaction) in multiple services (like order service and user account service).
Significantly increased employee amount.


(picture taken from Microservice architecture)

The most important are:

  • Split services by business needs
  • Database per service
  • (Server side) service discovery
  • Framework for faster development, unification and standards support
  • Log aggregation (with graylog)
  • Application metrics (prometheus+grafana is a good thing)
  • Distributed tracing (like opentracing and jaeger)
  • Healthcheck API (framework+kubernetes, for instance)

Full list:

Event sourcing for data consistency across microservices

You should want to atomically update data in several microservices. For example, you want to decrement user’s account on order event.

You can try to use Event sourcing
It is when you store all state-changing events for your entities. In this case, entities are like a state machine but any state can be rolled back to the previous one.
And to recreate the entity’s state, you have to replay all the log. To fasten this operation, the application makes snapshots from time to time.

CQRS for retrieving data in applications with event sourcing

CQRS stands for Command Query Responsibility Segregation.

If you have a storage of state-changing events for your entities, it’s really hard to retrieve a list of all the entities in some state, or entities with some attribute.
To solve this, you can have a separate database, which is used only for querying and is populated with data based on system events. So, it subscribes to all events related to needed entities and represents a current state of the system (like a DB view).

Further reading:
Microservice architecture
Event sourcing

Similar Posts