Microservices

Start with a monolith

Most products don't need microservices. A well-structured modular monolith — clear internal module boundaries, one deploy, one database — is faster to build, easier to debug, and trivially consistent. Split out a service only when you have a concrete reason: independent scaling, team ownership, isolation of a risky/heavy component (e.g. an ML inference service), or a different language/runtime need.

Drawing boundaries

• Split by business capability / bounded context, not by technical layer. "Billing", "Notifications", "Inventory" — not "the database service" and "the API service".
• Each service owns its data. No other service reaches into its database directly; access is only through its API or events. Shared databases recreate all the coupling you were trying to escape.

Communication

• Sync (REST/gRPC) when the caller needs an answer now. gRPC for internal, high-throughput, typed contracts; REST for external/public.
• Async (events) when the caller can fire-and-forget. Async is the default for cross-service side effects — it removes temporal coupling and improves resilience.
• Avoid deep synchronous call chains (A→B→C→D). One slow link stalls the whole request and multiplies failure probability.

Distributed data & transactions

• No cross-service ACID transaction. Use the Saga pattern: a sequence of local transactions, each with a compensating action to undo on failure. Orchestrate sagas with Temporal for sanity.
• Accept eventual consistency as the cost of the architecture. Design UX and reads around it.

Resilience — assume things fail

• Timeouts on every network call (never infinite).
• Retries with exponential backoff + jitter — but only for idempotent operations.
• Circuit breakers to stop hammering a downed dependency and give it room to recover.
• Bulkheads: isolate resource pools so one failing dependency can't consume all threads/connections.

Operational baseline (non-negotiable before you split)

• Centralized structured logging with a correlation/trace ID threaded through every call.
• Distributed tracing (OpenTelemetry) — without it, debugging across services is guesswork.
• Independent CI/CD per service, plus contract tests so a producer can't silently break a consumer.

The honest trade-off: microservices trade in-process simplicity for operational and network complexity. Only pay that price when the organizational or scaling benefit is real.