Stefan Tilkov at microXchg Berlin: Microservice Patterns and Antipatterns

| by Jan Stenberg Follow 38 Followers on Mar 26, 2018. Estimated reading time: 4 minutes |

Stefan Tilkov explained in his presentation at microXchg 2018, held in Berlin, a series of patterns and antipatterns in microservice projects from his perspective, especially noting that some of the patterns he considers to be good patterns other people may see as antipatterns and vice versa.

The talk began with a discussion that microservices is a pattern where we design modules as separate deployment and operational units, with large degrees of freedom for their implementation. Enforcing communication over a network creates a boundary between modules that promotes encapsulation, thus making it harder to violate how modules were designed to interact and collaborate.

For Tilkov, co-founder of INNOQ, the consequences of using microservices includes isolation, autonomy and flexibility, but he noted that when building modular software along with his definition, there is no real need at all for microservices. However, since we often fail to design large-scale modular software effectively, we still need the microservices pattern.

Evolutionary Architecture

Instead of creating the right architecture from the start when building a system, you can create an "Evolutionary Architecture" that is constructed for adaptability and can be changed to become the right one at a particular point in time. For Tilkov, the approach in such an architecture includes:

  • Separation of large domain into what he calls "islands of change"
  • Design for replacement, not for reuse
  • Minimizing of shared dependencies, with a focus on autonomy and redundancy instead of on reuse

One advantage is that it enables experimentation, for instance using A/B testing.

Distributed Monolith

Tilkov’s first antipattern was the "Distributed Monolith", or microservices gone bad, which he described as:

A system made up of arbitrarily sized, tightly coupled modules communication over network interfaces

For Tilkov this is often a hype- or conference-driven architecture lacking a focus on the business domain. Common consequences using this pattern include:

  • Ripple-effect of changes
  • Complex environment
  • Hard to understand and maintain

At the negative extreme this can become a mix of technologies and frameworks that nobody can manage. 

Decoupling Illusion

In Tilkov’s experience, teams often introduce microservices in order to be more flexible and able to quickly adapt to changes. "Decoupling Illusion" is an antipattern in which you split a system up in modules but due to lack of domain knowledge you haven’t solve the fundamental problem — isolating stakeholders and business requirements from each other. Instead you have created modules that now get requirements from two or more stakeholders, and which are dependent on other modules. These modules then have to evolve and be deployed together.

Micro Platform

An antipattern orthogonal to the previous is the "Micro Platform", in which you standardize all internal/operational service aspects into a framework and force all teams to use it. A problem you now have is a technical dependency in every single service, and one stakeholder that is interested in all services. The primary motivation for this antipattern is the goal of standardization, which probably looks reasonable — especially early in a project — but it also creates the need for coordinating new features and updates across multiple teams. To mitigate this, Tilkov recommends that the usage of the framework should be optional.

Entity Service

An "Entity Service", for example an order service, may look like a reasonable and useful service in a retail business. The problem with this antipattern is that all services with an interest in that service will also force their needs onto it, thus causing the entity service to end up being a mix of all interests from all clients using it. Tilkov claimed that often this entity service is not needed at all; its responsibilities belong in other services with their own view of an order. He claimed that the only reason it’s being created is the appearance of "order" in the name, and referred to the ideas of an enterprise data model (EDM) where you try to create a common definition of an order.


Tilkov often meets clients that have complex business applications composed of different parts — bounded contexts. When these contexts are combined with microservices you end up with the "Distributed Domain-Driven Design (DDDD)" pattern where communication typically is asynchronous, maybe using business events, with data redundantly stored. These services are loosely coupled and more autonomous while the size of each service often is as big as a bounded context. For Tilkov the key motivation for this approach is to enable separate evolution.

Self-Contained Systems (SCS) is similar to the DDDD pattern, the difference is that each service also contains its own UI component, with a light-weight integration of the services often done in the frontend. This minimizes the infrastructure needed, and for Tilkov this is the best suited model for decoupling development teams.


Tilkov’s final pattern is the "Monolith", which he believes is still ideally suited for many cases, like a single small team. It’s a standard application with straightforward development, is easy to refactor, and does not contain any artificially introduced distribution:

A highly cohesive, tightly integrated, single unit of deployment application


In his presentation, Tilkov focused on the size of services, and the challenges of getting this sizing correct. He believes that an architecture composed of 2,000 things sitting next to each other will be hard to understand. Therefore, he is advocating a little more structure on top of that, by grouping or clustering. He summarized by emphasizing that none of the patterns are the right model — they all depend on your context. The solution chosen should always be driven by the domain and desired business benefits. He also points out that if possible you should strive for an evolutionary architecture that can grow with your requirements.

The presentations at the conference were recorded, some are already published with more to come.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

It's all about identifying service boundaries by Vadim Samokhin

And it's amazing how few of us realize its importance.
I would say that every time you create (micro-)services with reuse being its primary motivational force, you're wrong. Reuse is a fallacy -- it inherently leads to tight coupling. And very often to synchronous communication as well -- just like an entity antipattern approach. It's ridiculous, but in 2018 the default service communication pattern is synchronous request-reply. Ok, its drawbacks are:
* it's unreliable. If one service is down then the whole system is down.
* what about consistency? How would you enforce it? I bet you don't want to mess with distributed transactions.
* scaling? You have to scale the whole system instead of only those parts that really need it -- say, some step that requires synchronous communication with external systems.
And not to mention service orchestration and centralized data. I even wrote a post describing the wrong ways of identifying service boundaries in detail.

And Stefan fails to describe the steps one needs to take to define service boundaries correctly. Saying that they should coincide with bounded context boundaries is not enough, since there is an infinite number of ways to identify a bounded context.

The approach I follow is to identify business capabilities first. It is something that organization does to keep it running. Organizational structure could help with it, though it might be misleading. The better approach is a Value-chain analysis. What are the primary steps that your enterprise undertakes to make money? You produce something, find customers and sell your product to them, right? Well, the chances are that those three steps are your business-capabilities, and hence, services. So here is where I agree with Stefan: he says that his SCSs are typically bigger than microservices. But here is the kicker: business-capabilities can be nested, as well as your services. So as a result, their communication most of the time will be an event-based, without moving any data back and forth.

Here is an example of how this approach works in real life.

Re: It's all about identifying service boundaries by Jan Stenberg

I just want to point out that Stefan's presentation was an exploration of (anti)-patterns in microservice projects and their consequences. It was not about how to solve specific challenges, like finding the correct service boundaries.
Finding service boundaries is a large subject in itself with many tools available, Event Storming, Domain Storytelling and others, but people is of course the most important when working with these kind of business-related issues, and the ideas from Domain-Driven Design of course.
Finding service boundaries and the tools that can be used have been the subject for many news and articles here on InfoQ.
Thanks, Jan

Re: It's all about identifying service boundaries by Daniel Bryant

Hey Shaun,

Although I agree with Jan's reply that Stefan's presentation was aiming for a higher level approach to identifying patterns and antipatterns within architecture in general, you make several interesting comments, and I have also enjoyed reading your Medium articles.

Would you be interesting in summarising some of these thoughts for a full length InfoQ article? I'm sure readers would very much enjoy your insight.

Best wishes,

InfoQ News Manager

Re: It's all about identifying service boundaries by Wrong About

Sure, why not.

Re: It's all about identifying service boundaries by Vadim Samokhin

Sure, why not.

Re: It's all about identifying service boundaries by Jan Stenberg

I agree with Daniel, the articles are very interesting. They remind me of the original idéas about microservices, business capabilities and so on, from James Lewis and Martin Fowler. I should have found the articles earlier and made a news about them.


Re: It's all about identifying service boundaries by Daniel Bryant

Great -- could you share an email address with me please (daniel dot bryant at infoq dot com), and I can send through more details?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss