Microservices Architecture for the Enterprise

Microservices architecture structures an application as a set of small, independent services, each owned by a team, deployed and scaled independently, and communicating via lightweight protocols. Done well, it unlocks agility and scale that monoliths cannot. Done poorly, it produces a distributed monolith — all the complexity of microservices with none of the benefits.

The decision to adopt microservices is not primarily technical; it is organisational. Microservices succeed when teams are organised around domains and given the autonomy to ship independently; they fail when imposed on teams organised by technology layer with centralised release coordination. Conway's Law is not optional — it is the strongest predictor of microservices outcomes.

This page covers the principles, the domain-driven decomposition that defines boundaries, the enterprise patterns (API gateway, service mesh, saga, CQRS, event sourcing), the trade-offs, and the organisational prerequisites that decide whether microservices deliver their promise.

The defining property of a microservice is independence: it can be deployed, scaled, and failed without coordinating with other services. Everything else — size, technology, protocol — is secondary. A 'microservice' that cannot deploy without coordinating with three others is not a microservice; it is a distributed component.

Microservices are not 'small services'. A service that does one thing well but shares a database with five other services is a tightly coupled distributed monolith. The independence must extend to data: each service owns its data and exposes it only through its API. Shared databases are the most common silent killer of microservice architectures.

The decision is a trade, not an upgrade. Microservices add operational complexity (distributed systems concerns: network failure, partial failure, eventual consistency, observability) in exchange for agility and scale. An enterprise that cannot absorb the operational complexity should not make the trade — a well-structured modular monolith is often the better answer.

The right way to decompose into microservices is by business domain, using Domain-Driven Design (DDD). DDD's bounded context — a boundary within which a domain model is consistent — is the natural unit of a microservice. Each bounded context has its own ubiquitous language, its own model, and its own data.

Decomposing by domain (order management, inventory, billing) rather than by technical layer (UI, business logic, data) produces services that align with business capabilities and can evolve independently. Decomposing by layer produces 'services' that are coupled to every other layer and cannot change independently — the distributed monolith.

Getting bounded contexts right is the single highest-leverage decision in a microservices architecture. Boundaries that cut across domain semantics force every change to coordinate across services; boundaries that align with domain semantics let services evolve independently. This is why EA's capability map is such a powerful input to microservice decomposition.

Several patterns recur in enterprise microservices architectures. The API gateway provides a single entry point for clients, handling routing, authentication, rate-limiting, and sometimes aggregation. The service mesh handles service-to-service communication, observability, and policy (mTLS, retries, circuit breaking) without application code changes.

For cross-service transactions, the saga pattern coordinates a sequence of local transactions with compensating actions on failure — because distributed transactions (two-phase commit) do not scale. For read-heavy services with complex queries, CQRS (Command Query Responsibility Segregation) separates the write model from read models, often materialised from events.

Event sourcing — persisting state as a sequence of immutable events — pairs naturally with CQRS and provides an audit log and the ability to rebuild state. These patterns are powerful but each adds complexity; the architect applies them where the problem justifies them, not universally. A system where every service uses event sourcing and CQRS is over-engineered; one where none are used may be under-engineered.

The most common and most damaging anti-pattern in microservices is the shared database. When multiple services read and write the same database, they are coupled at the data layer: a schema change by one breaks others, and the database becomes a monolith that the service decomposition only pretends to split.

The principle is database-per-service: each service owns its data and exposes it only through its API. Other services that need the data call the API or consume events. This enforces the bounded context at the data layer and is what makes service independence real.

The objection is performance and query convenience — cross-service joins are impossible without a shared database. The answer is CQRS and materialised views: replicate the needed data into read models via events, accepting eventual consistency. This is more work, but it preserves the independence that is the entire point of microservices.

Microservices move complexity from the application to the operational layer. A single failed request may traverse five services; finding which one failed requires distributed tracing, not log grep. Observability — metrics, logs, and especially distributed traces — is not optional in microservices; it is the precondition for operating them.

Resilience patterns must be designed in: timeouts, retries with backoff, circuit breakers, and bulkheads prevent a single failing service from cascading. Without these, a microservices architecture is brittle in a way a monolith is not — partial failures propagate where a monolith fails atomically.

The platform investment required to operate microservices (service mesh, observability, automated deployment, contract testing) is substantial. An enterprise that underinvests in the platform gets the complexity of microservices without the tooling to manage it — the worst of both worlds. This is why platform engineering and microservices adoption are inseparable.

Conway's Law — 'any organisation that designs a system will produce a design whose structure copies the organisation's communication structure' — is the strongest predictor of microservices outcomes. A team structure organised by technology layer (a UI team, a back-end team, a DBA team) will produce a layered architecture regardless of intent; a structure organised by domain will produce domain-aligned services.

The implication is that microservices adoption is an organisational change as much as a technical one. Team Topologies (stream-aligned, platform, enabling, and complicated-subsystem teams) provides a vocabulary for organising teams to produce the architecture you want. Adopting microservices without reorganising teams produces a distributed monolith operated by a layered organisation.

The healthy pattern is to design team boundaries and service boundaries together, so each service has a team that owns it end-to-end. A service owned by multiple teams is owned by no one; a team owning multiple services is fine if each is independently deployable, but watch for cognitive overload.