Cloud architecture patterns are reusable arrangements for recurring design problems. They do not guarantee scalability, resilience, security, or lower cost. Each introduces assumptions, work, failure modes, and constraints.

Start with measurable availability and recovery objectives, latency percentiles, throughput, consistency, residency, security boundaries, deployment independence, operability, and total cost. Choose the simplest design that satisfies them.

Compare the patterns

PatternUseful whenTrade-offs
Modular monolithOne deployment is acceptable and local calls and transactions help.Module discipline, coordinated releases, scaling granularity.
MicroservicesClear domains need independent ownership, deployment, or scaling.Network failure, consistency, observability, testing, staffing.
ServerlessManaged event execution fits workload shape and service limits.Quotas, startup latency, state, concurrency, portability, cost.
Event-drivenProducers and consumers benefit from asynchronous decoupling.Ordering, duplicates, schema change, replay, backpressure.

Modular monolith

A monolith need not be unstructured. Enforce cohesive modules, narrow interfaces, and dependency rules while retaining simple deployment and local transactions. Extract a service only when measured scaling, ownership, reliability, or release needs justify distributed-system cost.

Microservices

A service should own a coherent capability and change lifecycle. Shared databases, synchronous call chains, and coordinated releases can erase independence. Define compatible API and event contracts, ownership, and objectives. Design for partial failure with timeouts, bounded retries, idempotency, circuit breaking, and bulkheads where appropriate. Retries can amplify overload and duplicate effects. See microservices architecture patterns.

Serverless

Serverless means customers do not manage underlying servers; servers and customer responsibilities remain. Functions are generally stateless between invocations, with durable state in external services. Do not assume zero startup latency, infinite scale, exactly-once execution, or universal savings. Test runtime and payload limits, capacity, concurrency, identity, networking, observability, downstream bottlenecks, and every billing dimension.

Event-driven systems

An event records that something happened; a command requests an action. Brokers often provide at-least-once delivery, so consumers should tolerate duplicates unless the complete path proves stronger guarantees. Assign schema ownership, stable event identifiers, compatibility, idempotent consumers, bounded retry, dead-letter handling, replay safeguards, ordering scope, and correlation. In payments, never treat an unverified client event as proof that money moved.

Reliability patterns

Redundancy improves availability only when replicas do not share a failure mode and failover works. Multi-region designs add replication lag, consistency choices, complexity, and cost. Define recovery time and recovery point objectives, then test restoration and failover. Caches add invalidation and staleness; queues absorb bursts but cannot create downstream capacity; a service mesh standardizes traffic policy while adding another control and data plane.

Security and operations

Map identities, trust boundaries, data flows, administrative paths, and tenant isolation. Enforce least privilege, short-lived credentials, encryption and key management, dependency controls, logging, detection, incident response, and tested recovery. Kubernetes is an orchestration choice, not a microservices prerequisite; if selected, review Kubernetes security practices.

Select with evidence

  1. Describe workload, users, data, failure impact, and constraints.
  2. Set measurable latency, throughput, availability, recovery, consistency, security, and cost targets.
  3. Choose the simplest viable baseline.
  4. Test uncertain behavior with representative load and failure injection.
  5. Record the decision, alternatives, evidence, owner, and review trigger.

Architecture is not a maturity ladder from monolith to microservices. Connect choices to enterprise architecture and account for cutover and data movement in cloud migration challenges.

Originally published July 26, 2025; technically reviewed and substantially updated September 4, 2026.