Microservices and Distributed Systems

Microservices architecture splits a system into independently deployable services, each owning a specific business capability. This approach trades the simplicity of a monolith for flexibility in scaling, deployment, and technology choice -- but only when the organizational and technical complexity is justified.

When to Use Microservices vs Monolith

There is no universal answer. The decision depends on team size, domain complexity, and operational maturity.

Factor	Monolith Favored	Microservices Favored
Team size	Small team (fewer than 10 developers)	Multiple autonomous teams that need independent release cycles
Domain complexity	Simple or poorly understood domain	Well-understood domain with clear bounded contexts
Deployment cadence	Infrequent releases are acceptable	Different parts of the system need to ship at different speeds
Scaling needs	Uniform load across the application	Specific components need independent scaling
Operational maturity	Limited infrastructure automation	Mature CI/CD, monitoring, and container orchestration
Data isolation	Shared database is manageable	Services need independent data stores and schemas

Start monolithic unless you have a clear reason not to. A well-structured modular monolith can be decomposed later. A premature microservices architecture adds distributed systems complexity without proportional benefit.

Service Decomposition Strategies

Deciding where to draw service boundaries is the hardest part. Get it wrong and you end up with a distributed monolith -- all the costs of distribution with none of the benefits.

By Business Capability

Align services to what the organization does rather than how the software is structured. Each service maps to a business function: order management, inventory, billing, notifications. Services change when the business capability they represent changes.

By Subdomain (Domain-Driven Design)

Use bounded contexts from domain-driven design to identify natural boundaries. Each bounded context has its own ubiquitous language and internal model. A "Customer" in the billing context may carry different attributes than a "Customer" in the shipping context -- and that is fine.

Strangler Fig Migration

When migrating from a monolith, extract services incrementally rather than doing a big-bang rewrite. Route traffic through a facade that delegates to the monolith by default but redirects specific capabilities to new services as they are built. Over time, the monolith shrinks until it can be retired entirely. An anti-corruption layer translates between old and new models during the transition.

Decomposition Heuristics

High coupling between candidates -- keep them together, they are likely one service
Different rates of change -- separate them, they will benefit from independent deployment
Different scaling profiles -- separate them, they need different resource allocation
Shared data -- if two candidates always read and write the same tables, splitting them creates unnecessary network chatter

Communication Patterns

Services must communicate, and the choice between synchronous and asynchronous interaction shapes the entire system's behavior.

Style	Mechanism	Strengths	Weaknesses
Synchronous request-reply	REST, gRPC, GraphQL	Simple mental model, immediate response	Temporal coupling, cascading failures
Asynchronous messaging	Message queues (point-to-point)	Decouples sender from receiver, buffering under load	Added infrastructure, eventual consistency
Event-driven	Event bus, pub/sub	Loose coupling, multiple consumers possible	Harder to debug, event ordering challenges

Rule of thumb: Use synchronous calls for queries that need an immediate answer. Use asynchronous messaging for commands and events where the sender does not need to wait for the result.

See Communication Patterns Reference for detailed coverage of API gateways, service discovery, gRPC, service mesh, and sidecar patterns.

Data Management in Distributed Systems

Each service should own its data. Shared databases create hidden coupling that defeats the purpose of service independence. This creates new challenges around consistency and cross-service transactions.

Key Principles

Database per service -- each service has its own data store, accessed only through its API
No direct database sharing -- if another service needs data, it requests it through the owning service's interface
Eventual consistency is the norm -- strong consistency across services requires distributed transactions, which are fragile and slow
Choose the right data store -- different services may use different database technologies based on their access patterns

Core Data Patterns

Pattern	Purpose
CQRS	Separate read and write models to optimize each independently
Event Sourcing	Store state as a sequence of immutable events instead of overwriting current state
Saga	Coordinate multi-service transactions using a sequence of local transactions with compensating actions
Outbox	Guarantee reliable event publishing by writing events to a local table within the same database transaction
Eventual Consistency	Accept that data across services will converge over time rather than being immediately consistent

See Data Patterns Reference for implementation details with multi-language examples.

Resilience Patterns

In a distributed system, failures are inevitable. Network partitions, slow dependencies, and overloaded services are normal operating conditions, not exceptional events. Resilience patterns prevent localized failures from cascading through the entire system.

Pattern Summary

Pattern	Purpose
Circuit Breaker	Stop calling a failing dependency; fail fast and give it time to recover
Bulkhead	Isolate resource pools so one slow dependency cannot exhaust resources needed by others
Retry with Backoff	Automatically retry transient failures with increasing delays and randomized jitter
Timeout	Set upper bounds on how long to wait for a response; never block indefinitely
Fallback	Provide degraded but functional behavior when a dependency is unavailable
Health Checks	Expose liveness and readiness endpoints so orchestrators can route traffic and restart unhealthy instances

See Resilience Patterns Reference for implementation details with multi-language examples.

Reference Files

Reference	Contents
Data Patterns	CQRS, event sourcing, saga orchestration vs choreography, outbox pattern, eventual consistency with multi-language examples
Resilience Patterns	Circuit breaker, bulkhead, retry with backoff, timeout, fallback, health checks with multi-language examples
Communication Patterns	REST, gRPC, GraphQL federation, message queues, API gateway, service discovery, sidecar and service mesh with multi-language examples

Integration with Other Skills

Situation	Recommended Skill
Domain modeling and bounded context design	Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for clean architecture guidance
Testing microservices (contract tests, integration tests)	Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for testing strategies
API design for service interfaces	Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for API design principles
Performance tuning individual services	Install `knowledge-virtuoso` from `krzysztofsurdy/code-virtuoso` for performance optimization