Microservices

Independently releasable services modeled around a business domain that own their own data — and why information hiding and independent deployability are the whole game.

Microservices buy you options — technology heterogeneity, targeted scaling, robustness, organizational alignment — at a real and significant cost in distributed-systems complexity.

Microservices are a bad fit for unclear domains, true startups, and customer-installed software — and the biggest reason not to adopt is simply not having a good reason.

Where to draw the lines — using information hiding, coupling/cohesion, the four (or five) types of coupling, and just-enough domain-driven design (aggregates and bounded contexts) to find stable boundaries.

Migrate functionality out of a monolith incrementally by wrapping it, intercepting calls, and redirecting them to new services one slice at a time — with rollback at every step.

Microservices must own their data, so migration means splitting the shared database — coping patterns, ownership transfer, and the hard losses of joins, foreign keys, and ACID transactions.

Beyond the strangler fig — branch by abstraction for functionality deep inside the monolith, parallel run to verify a risky replacement, plus decorating collaborator and change data capture.

Choose the communication style before the technology — request-response vs event-driven, synchronous vs asynchronous — and understand temporal coupling, cascading failures, and what goes in an event.

Two ways to coordinate a multi-service business process: a central orchestrator that commands the flow, or choreographed services reacting to broadcast events — and when to choose each.

Coordinate multiple state changes across services without long-held locks by modeling a process as a sequence of local transactions, with compensating actions for rollback.

Life after ACID across services — the CAP theorem, eventual consistency, the canonical source of truth, idempotency, and designing boundaries around transactions.

Deploying many interdependent services: the five principles of deployment, the options from VMs to FaaS, and progressive delivery — separating deployment from release to control the blast radius.

The test pyramid in a distributed world — why end-to-end tests turn brittle, why consumer-driven contract tests replace them, and how to test safely in production.

From monitoring to observability — log aggregation with correlation IDs, metrics, distributed tracing, and SLO/SLI/error-budget thinking for understanding production you never anticipated.

Stability patterns for distributed systems — timeouts, retries, bulkheads, circuit breakers, and idempotency — plus the four aspects of resilience and why it's ultimately a people property.

Systems mirror the communication structure of the organizations that build them — so align teams to business domains, use the four Team Topologies team types, and apply the Inverse Conway Maneuver incrementally.

Strong, active service ownership at scale, and the platform/enabling teams that provide a non-mandatory 'paved road' of self-service tooling — plus governance as guardrails, not gatekeeping.