Slice by business capability
Draw boundaries around business domains and clear responsibilities. Technical layers such as APIs, workers, and persistence usually belong together when they serve the same capability.
English version
Microservices that stay domain-focused, loosely coupled, and operable.
This page summarizes practical guidance for microservices and event-driven architecture: service boundaries, event contracts, observability, deployment, and team ownership.
Foundations
Service boundaries
A microservice is not just a small deployable. It encapsulates a business capability, data ownership, and operational responsibility.
Respect data ownership
Each service owns its data. Other services should not read its database directly; they should use APIs, events, or replicated read models.
Actively reduce coupling
Use synchronous calls deliberately, define timeouts and fallbacks, and avoid publishing internal models as public contracts.
Protect delivery autonomy
A service should be testable, deployable, scalable, and rollbackable on its own. Keep shared libraries small and stable.
Event-driven architecture
Events as business facts
Events decouple workflows, but they increase the need for discipline around contracts, idempotency, ordering, and error handling.
Name events in past tense
An event describes what happened: OrderPlaced, PaymentCaptured, or ContractCancelled. It is not a hidden remote procedure call.
Version contracts
Schemas are production interfaces. Changes must be planned for compatibility, documented, and covered with consumer tests.
Build for idempotency
Consumers must tolerate duplicate delivery. Event IDs, Aggregate IDs, Inbox/Outbox patterns, and traceable retry strategies are core building blocks.
Design consistency intentionally
Eventual consistency is a design decision. User interfaces, SLAs, and support processes must make delays and intermediate states understandable.
Operations
Production readiness from the start
Distributed systems require operational discipline. Without observability, clear ownership, and resilience, small services quickly become large dependencies.
Standardize observability
Carry metrics, logs, traces, and correlation IDs across services and events. Dashboards should combine business and technical signals.
Isolate failures
Timeouts, circuit breakers, bulkheads, and dead-letter queues prevent cascading failures. Retries need limits, backoff, and clear alerting.
Keep deployment risk small
Automated tests, contract checks, database migrations, and progressive releases reduce risk. Rollback should be a normal procedure.
Make ownership visible
Every service needs a team, contact path, runbooks, service level objectives, and explicit rules for breaking changes.
Practical
Go-live checklists
These questions make architecture decisions concrete and keep risks visible early.
Service design
- Can the business responsibility be explained in one sentence?
- Does the service own its data and migration strategy?
- Are public APIs and events documented and versioned?
- Can the team release and rollback independently?
Event flow
- Are producers, consumers, and expected latencies known?
- Are event schemas compatible and tested?
- Are consumers idempotent and retry-capable?
- Is there monitoring for lag, errors, and dead letters?
Operations
- Are SLOs, alerts, and runbooks available?
- Does tracing cross synchronous and asynchronous boundaries?
- Have secrets, access, and data classification been reviewed?
- Are capacity, costs, and scaling limits understood?