Designing Microservices: Boundaries, Communication, Data

Microservices are not a goal; they're a trade-off. You accept distributed-system complexity in exchange for team autonomy, independent scaling, and fault isolation. Good design answers four essential questions.

(1) Where are the boundaries?

• Decompose by bounded context (DDD): Orders, Inventory, Payment, Catalog, Customer, Shipping
• Each context owned by one team; own data model; evolves independently
• Not by technical layer; auth-service and email-service cause every feature to span services
• Event storming or domain mapping to find bounded contexts
• Characteristics: own ubiquitous language; one aggregate root; one team; few external dependencies
• A service should have enough meaningful logic to justify its operational cost

(2) How do services communicate?

• Sync (REST or gRPC) when caller must wait: public APIs, internal critical-path calls
• Async (Kafka or SQS) when caller doesn't need to wait: events, notifications, workflows
• Rule: sync when you must wait for a response; events for everything else
• Risks of sync chains: cascading failure, latency multiplication, tight coupling
• Mitigations: tight timeouts (2 to 5 seconds), circuit breakers, bulkheads, service mesh
• Event-carried state transfer: include enough data that consumers don't need to call back
• Saga + outbox for reliable distributed operations

(3) Who owns which data?

• Database per service: hard rule, non-negotiable
• No shared tables; foreign keys only within own schema
• Cross-service data via events or API calls, never direct DB access
• Data duplication is expected; Order has snapshot of customer, updated via events
• CDC (Debezium) replicates changes cleanly
• No 2PC; use sagas and accept eventual consistency
• Polyglot persistence per service: Postgres for transactional, Redis for cache, Elasticsearch for search

(4) How do they deploy and operate?

• One service equals one team; team owns code, deploy, monitoring, on-call
• Containerized with Docker; Kubernetes is the 2026 default
• Service template with logging, metrics, tracing, health pre-wired
• CI/CD template: build, test, contract test, security scan, deploy
• Platform first: API gateway, service mesh, observability, event bus, secrets, feature flags
• Without platform, each team reinvents: 20 services means 20 buggy logging setups

The failure modes to prevent

Distributed monolith

• Services must deploy together; shared DB; tight coupling
• Worst of both worlds
• Fix: restore proper boundaries or merge services

Nano-services

• 50 tiny services with almost no logic
• Operational cost dominates
• Aggregate related capabilities

Chatty interfaces

• A calls B calls C calls D; 4 hops; 100ms baseline
• Redesign boundaries; pre-load via events; BFF aggregates

Shared database

• Couples schemas, prevents independent deploys
• Database per service plus event sync

Missing observability

• 20 services, no tracing; debugging takes hours
• Invest in distributed tracing (OpenTelemetry) from day 1

Overuse of sync

• Every call is HTTP request-response
• One slow service cascades
• Move to events for non-critical paths

Platform engineering — invest before scaling service count

• API Gateway: Kong, Envoy, AWS API Gateway
• Service mesh: Istio or Linkerd; mTLS, retries, observability
• Observability: OpenTelemetry + Jaeger/Tempo + Prometheus + Grafana, or Datadog
• Event bus: Managed Kafka + Schema Registry
• Secrets: Vault, AWS Secrets Manager
• Feature flags: LaunchDarkly, Unleash, Flagsmith
• Incident platform: PagerDuty, runbooks, blameless postmortems

Testing strategy

• Unit tests many and fast
• Contract tests (Pact) replace many integration tests
• Integration tests per service with real DB via Testcontainers
• Few end-to-end tests (smoke the happy path)
• Chaos engineering in non-prod

Team topology

• Conway's Law: systems mirror communication structures
• Stream-aligned teams own 1 to 2 services each
• Platform team builds shared capabilities
• Avoid shared services teams; creates bottleneck

When microservices are wrong

• Team under 20 engineers; modular monolith usually better
• Simple domain without real autonomy pressure
• Pre-product-market-fit startup
• No platform engineering capacity

When microservices shine

• 50+ engineers with distinct domains
• Parts of system have very different scaling needs
• Fault isolation critical

Modular monolith is often right

• Spring Modulith, ArchUnit, DDD give 80% of benefits with 20% of cost
• Only extract when specific pain demands

DORA metrics prove success

• Deployment frequency (target: daily per team)
• Lead time (commit to prod)
• Change failure rate (under 15%)
• Mean time to recovery
• If teams deploy independently daily, microservices work; if together weekly, distributed monolith

The strategic answer

• Microservices are a trade-off, not a goal
• Decompose by bounded context, not technical layer
• Database per service, events for sync, platform first
• One team per service
• Invest in observability and CI/CD before scaling count
• Measure with DORA; adjust based on evidence
• Modular monolith often beats microservices; only extract for specific pain