Microservices are hard. That is probably the only thing we all agree on when it comes to microservices.

The promise is autonomy, scalability, and independent delivery. The reality is often something very different: distributed spaghetti or lasagna. Blobs of responsibility spread over the network, synchronous call chains everywhere, unclear ownership, fragile transactions, and teams arguing about where the “real” business logic should live.

This session looks at microservices from a pragmatic architecture perspective rooted in real experience. Not as a hype pattern or an anti-pattern, but as a set of trade-offs around boundaries, ownership, communication, and consistency.

We will explore how Domain-Driven Design can help define service boundaries, but also where DDD terminology gets misused. What is a bounded context? How large should a service be? Can one microservice contain multiple APIs or workers? When does orchestration make sense? Should we layer services at all?

The goal of this talk is not to sell microservices or dismiss them. The goal is to give developers and architects better mental models for designing services that are cohesive, autonomous, and understandable.

Learn from successes and especially from failures.

Attendees will leave with practical heuristics for spotting bad service boundaries, avoiding accidental distributed monoliths, and choosing communication patterns that fit the business problem instead of the architecture diagram.