Source: Cloud design patterns, architectures, and implementations (diagrams from that guide).
A monolith is one program, one database. Microservices are many small programs that talk over the network and often each have their own database. These patterns are the usual answers to: “how do they talk, fail, and stay consistent?”
| Pattern | One line |
|---|---|
| Anti-corruption layer | Translator so old code need not learn the new API |
| Hostname / path / header routing | How the front door picks a service |
| Circuit breaker | Stop calling a sick neighbor |
| Event sourcing | Save what happened, not only the latest row |
| Hexagonal | Business rules in the middle; DB and HTTP are plugs |
| Publish-subscribe | Shout an event; whoever cares listens |
| Retry with backoff | Wait longer each time you retry |
| Saga choreography / orchestration | Multi-step “transaction” without a shared DB lock |
| Scatter-gather | Ask many, then combine answers |
| Strangler fig | Replace the monolith piece by piece |
| Transactional outbox | Write DB + “please publish this event” in one commit |
Anti-corruption layer (ACL)
You moved User out of the monolith. Cart still speaks the old User shape. ACL is a translator in the middle. Cart does not change.
AWS: ACL class in the monolith → API Gateway → Lambda (new service).
Delete the ACL when every caller has moved. Pair with retry and circuit breaker. Guide · sample
API routing
Same idea: one front door, different ways to choose the kitchen.
Hostname
Each service owns a name: orders.api.example.com, billing.api.example.com. Teams do not share a gateway config. Clients must remember many hosts (or you give them an SDK).
Path
One host: api.example.com/orders, api.example.com/billing. Easier for humans. One bad config can hit everyone. On AWS: API Gateway proxy /billing/*, CloudFront origin by path, or NGINX.
HTTP header
Path still names the resource. A header picks version, A/B, or action (x-service-a-action: get-thing). You need control of the client. Often combined with hostname or path.
Circuit breaker
If Payment is down, do not keep waiting. After too many failures, the breaker opens: fail fast. After a wait, half-open: one test call. Success → closed again.
AWS: Step Functions, app libraries, or API Gateway + Lambda with stored state (e.g. DynamoDB). Guide
Event sourcing
Do not only store “balance = 40”. Store events: deposited 50, withdrew 10. Rebuild state by replaying. Good audit trail; reads often use a projection (a table built from events).
AWS: EventBridge, Kinesis, DynamoDB Streams, EventStore-style tables. Guide
Hexagonal architecture (ports and adapters)
The hexagon is business rules. Ports are sockets. Adapters are plugs: HTTP in, DynamoDB out. Swap DynamoDB for Postgres by changing the adapter, not the rules. Easy unit tests with fake adapters.
AWS: Lambda handler = adapter; domain classes have no boto3.
Publish-subscribe
Producer publishes “OrderPlaced”. It does not know who listens. Inventory and email subscribe. Add a new listener without changing the producer.
AWS: SNS + SQS, EventBridge. Guide
Retry with backoff
Network blips happen. Retry, but wait longer each time (1s, 2s, 4s…) plus jitter so everyone does not retry together. Do not retry forever. Do not retry non-idempotent POSTs without care.
AWS: SDK retry modes, Step Functions retries, SQS redrive. Guide
Saga (no 2-phase commit across databases)
Order + inventory + payment are three databases. You cannot lock them as one SQL transaction. A saga is a chain of local steps. If payment fails, run compensations (release stock, cancel order).
Choreography
No boss. Order publishes an event; Inventory reacts; Payment reacts. Simple with few services; hard to see the whole story later.
Orchestration
A conductor (often Step Functions) calls T1, T2, T3. On T3 fail, it runs C2 then C1. One place to read the flow; the conductor is a dependency.
Overview · choreography · orchestration
Scatter-gather
Scatter: send the same question to many workers. Gather: merge results (fastest quote, all answers, or first N).
AWS: Step Functions parallel, SQS + aggregator Lambda, Map state. Guide
Strangler fig
Do not rewrite the whole tree. Put a proxy in front. Route one URL to a new service; the rest still hits the monolith. Grow the new until the old is gone.
AWS: API Gateway, ALB, CloudFront - path or host to Lambda/ECS vs the old app. Use with ACL. Guide
Transactional outbox
You saved the order in SQL and you must publish OrderPlaced. Two systems: if the publish fails after commit, listeners never hear. Outbox: same DB transaction writes the row and an outbox row. A relay reads the outbox and publishes (SNS/EventBridge). At-least-once: consumers must be idempotent.
AWS: DynamoDB Streams / RDS + poller Lambda, or CDC.
How they fit
Strangler + ACL → leave the monolith without a big-bang rewrite
Hexagonal → keep rules testable while you swap AWS pieces
Pub/sub + outbox → notify others without dual-write bugs
Saga → multi-service business flow
Circuit + retry → survive the other team’s outage
Routing → one URL or many, on purpose