Microservices Have Relationship Issues: From Context Mapping to Runtime Communication

Microservices are supposed to be independent. Yet they keep calling each other, relying on each other's data and capabilities, and forcing us to coordinate releases. So our services are bound to have some relationship issues, and might need some marriage counselling.

We draw boxes for services, arrows for API calls and messages, and call it an architecture. But those arrows tell us surprisingly little about the actual relationships between our services.

Who depends on whom? Who gets to make the decisions? Who has to adapt when something changes?

In this talk, we'll explore these relationships using concepts from DDD context mapping, such as upstream/downstream, conformist and anti-corruption layers, without having to fully adopt DDD.

But understanding relationships is only half the story. How do we translate them into actual architecture decisions? When does synchronous communication make sense? When should we use events, commands, replicated data, or perhaps no communication at all? And does replacing a synchronous API call with a message really make our services more independent?

Through practical examples and architectural trade-offs, we'll explore how relationships influence communication, coupling, consistency and ownership.

Good microservice architecture isn't about avoiding dependencies. It's about understanding them and making deliberate choices.