Cloud Architecture Patterns Every Engineer Should Know

Whether you're preparing for a system design interview or building production systems, these architecture patterns form the foundation of modern cloud applications.

1. Microservices Architecture

What: Break a monolithic application into small, independently deployable services, each owning its own data and business logic. When to use: Large teams, complex domains, independent scaling requirements. Trade-offs:

• Pro: Independent deployment, technology diversity, fault isolation
• Con: Network complexity, distributed transactions, operational overhead

Real-world: Netflix, Amazon, Uber — each runs thousands of microservices.

2. Event-Driven Architecture

What: Services communicate through events (messages) rather than direct API calls. Producers emit events; consumers react to them. Key technologies: Apache Kafka, AWS EventBridge, RabbitMQ When to use: Real-time data processing, loose coupling between services, audit trails. Example: An order service emits an "OrderPlaced" event. The inventory service, payment service, and notification service each independently consume and react to it.

3. CQRS (Command Query Responsibility Segregation)

What: Separate the read model (queries) from the write model (commands). Each can be optimized independently. When to use: Read-heavy applications, complex domain models, systems requiring different data views. Example: An e-commerce platform writes orders to a normalized relational database but reads product listings from a denormalized search index (Elasticsearch).

4. Serverless Architecture

What: Run code without managing servers. Cloud provider handles scaling, patching, and availability. Key technologies: AWS Lambda, Google Cloud Functions, Azure Functions When to use: Variable workloads, event-driven processing, cost optimization for bursty traffic. Trade-offs:

• Pro: Zero server management, pay-per-execution, auto-scaling
• Con: Cold starts, vendor lock-in, 15-minute execution limits (AWS Lambda)

5. Strangler Fig Pattern

What: Gradually replace a legacy monolith by routing traffic to new microservices one endpoint at a time, until the old system is fully replaced. When to use: Migrating from monolith to microservices without a risky "big bang" rewrite. How: Put an API gateway in front of the monolith. Route new features to new services. Gradually move existing features until the monolith is empty.

6. Circuit Breaker Pattern

What: Prevent cascading failures by detecting when a downstream service is failing and short-circuiting requests to it temporarily. States: Closed (normal) → Open (failing, reject requests) → Half-Open (test with limited requests) Key technologies: Resilience4j (Java), Polly (.NET), Hystrix (deprecated but influential)

7. Saga Pattern

What: Manage distributed transactions across microservices using a sequence of local transactions, each with a compensating action for rollback. Types:

• Choreography: Each service listens for events and decides what to do next
• Orchestration: A central coordinator tells each service what to do

When to use: Any workflow spanning multiple services that needs consistency (e.g., booking a flight + hotel + car rental).

Choosing the Right Pattern

There's no one-size-fits-all architecture. The best engineers don't just know these patterns — they know when NOT to use them. A simple CRUD application doesn't need microservices. A low-traffic internal tool doesn't need event-driven architecture.

Start simple. Evolve when complexity demands it.

---

Prem Ranjan is a Senior Staff Engineer and founder of Job Observ, built on cloud-native architecture patterns including event-driven job processing and intelligent API design.