Backend Architectures Cheat Sheet

Updated 2026-04-29

🧠Study flashcards on this topic90 cards · spaced repetition→

Backend architecture defines how server-side systems are structured, organized, and scaled to handle business logic, data processing, and service orchestration. From traditional monoliths to distributed microservices and cell-based architectures, each architectural pattern represents trade-offs between simplicity, scalability, team independence, and operational complexity. Choosing the right architecture depends on team size, deployment frequency, performance requirements, and how much complexity your organization can effectively manage — there's no universal "best" architecture, only the one that fits your current constraints and enables your team to deliver value efficiently.

What This Cheat Sheet Covers

This topic spans 11 focused tables and 91 indexed concepts, 90 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Primary Architecture StylesTable 2: Domain-Driven Design (DDD) PatternsTable 3: Distributed System PatternsTable 4: Communication PatternsTable 5: Resilience & Reliability PatternsTable 6: Data Management PatternsTable 7: Caching StrategiesTable 8: Scalability PatternsTable 9: Deployment PatternsTable 10: Message Broker PatternsTable 11: Security & Authentication Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Primary Architecture Styles

These are the big-picture shapes a backend can take — the first and most consequential decision, made before any code is written. The spectrum runs from the simplicity of a monolith through the team autonomy of microservices to the extreme-scale and resilience plays like cell-based and space-based architectures. A useful default sits early in this list: a modular monolith gives you most of the organizational benefits of microservices without the distributed-systems tax, which is why it's the recommended starting point for most projects.

Style	Example	Description
Monolithic Architecture	`application.war` `└── all components in single deployable`	• Single unified codebase deployed as one unit • simplest to develop and deploy initially but becomes difficult to scale and modify as the application grows.
Microservices Architecture	`user-service`, `order-service`, `payment-service` `(each independently deployed)`	• Application split into independently deployable services organized around business capabilities • enables team autonomy and technology diversity but adds operational complexity.
Modular Monolith	`app.jar` `├── users/` `├── orders/` `└── payments/`	• Monolith with strong internal boundaries between modules • provides organizational benefits of microservices without distributed system complexity — recommended starting point for most projects.
Serverless Architecture	`AWS Lambda`, `Azure Functions` `triggered by events`	• Event-driven functions managed by cloud provider • eliminates server management and scales automatically but introduces cold starts and vendor lock-in.
Event-Driven Architecture (EDA)	`Kafka/RabbitMQ` `services react to events`	• Services communicate through asynchronous event streams rather than direct calls • enables loose coupling and real-time processing but requires careful event schema management.
Layered Architecture (N-Tier)	`Presentation → Business → Data` `(3-tier or more)`	• Application divided into horizontal layers with each layer depending only on layers below • provides separation of concerns but can lead to bloated middle tiers.
Service-Oriented Architecture (SOA)	`Enterprise Service Bus (ESB)` `connecting reusable services`	• Enterprise-scale approach with services communicating through a central bus • coarser-grained services than microservices, often using SOAP and focused on enterprise-wide reuse.
Cell-Based Architecture	`cell-router → cell-1 (users A-M)` `cell-router → cell-2 (users N-Z)`	• Workload partitioned into isolated, self-contained cells each serving a subset of traffic • failures stay within one cell, limiting blast radius to a small percentage of users.
Space-Based Architecture	`In-memory data grid` `with processing units`	• Removes database as bottleneck by using distributed in-memory storage (tuple spaces) • achieves extreme scalability for high-traffic applications but complex to implement.
Peer-to-Peer Architecture	`BitTorrent`, `blockchain nodes` `(each peer is client and server)`	• Decentralized network where nodes share resources directly • provides resilience and no single point of failure but challenging to coordinate and secure.

Table 2: Domain-Driven Design (DDD) Patterns

Domain-Driven Design is about keeping your business logic at the center and protecting it from frameworks, databases, and UIs. The architectural patterns here — Hexagonal, Clean, Onion, Vertical Slice — are different ways of drawing that boundary so dependencies always point inward toward the domain. The tactical patterns (bounded context, aggregate, domain event, anti-corruption layer) give you the vocabulary for modeling the domain itself and translating safely between it and the messy world outside.

Pattern	Example	Description
Hexagonal Architecture (Ports & Adapters)	`core/` `├── ports/` `└── adapters/`	• Business logic isolated in core domain with ports (interfaces) and adapters (implementations) handling external interactions • enables a technology-agnostic core that is easy to test.

The rest of this section is part of the full cheat sheet

Table 3: Distributed System Patterns

Once you split a system into many services, a new class of problems appears, and these patterns are the field-tested answers. An API gateway gives clients a single front door; CQRS and event sourcing rethink how state is stored and read; the saga and transactional outbox patterns solve the thorny problem of keeping data consistent across services without a global transaction. The remaining rows — service discovery, BFF, service mesh, sidecar, strangler fig — handle how services find, talk to, and replace one another.

Pattern	Example	Description
API Gateway Pattern	`gateway.api.com` `routes to user-svc, order-svc`	• Single entry point for all clients that routes requests to appropriate microservices • handles cross-cutting concerns like auth, rate limiting, and request aggregation.

The rest of this section is part of the full cheat sheet

Table 4: Communication Patterns

How services and clients actually exchange data — and the trade-offs are real. The synchronous styles (REST, gRPC, GraphQL, tRPC) differ in verbosity, performance, and type safety; the asynchronous and push styles (messaging, pub/sub, WebSocket, SSE, webhooks) buy you loose coupling and real-time delivery at the cost of eventual consistency. Knowing when to wait for a response versus fire an event is one of the defining skills of backend design.

Pattern	Example	Description
REST (Representational State Transfer)	`GET /api/users/123` `POST /api/orders`	• HTTP-based communication using standard methods (GET, POST, PUT, DELETE) • stateless, widely supported, and human-readable but chattier than binary alternatives.

The rest of this section is part of the full cheat sheet

Table 1: Primary Architecture Styles

Style	Example	Description
Monolithic Architecture	`application.war` `└── all components in single deployable`	• Single unified codebase deployed as one unit • simplest to develop and deploy initially but becomes difficult to scale and modify as the application grows.
Microservices Architecture	`user-service`, `order-service`, `payment-service` `(each independently deployed)`	• Application split into independently deployable services organized around business capabilities • enables team autonomy and technology diversity but adds operational complexity.
Modular Monolith	`app.jar` `├── users/` `├── orders/` `└── payments/`	• Monolith with strong internal boundaries between modules • provides organizational benefits of microservices without distributed system complexity — recommended starting point for most projects.
Serverless Architecture	`AWS Lambda`, `Azure Functions` `triggered by events`	• Event-driven functions managed by cloud provider • eliminates server management and scales automatically but introduces cold starts and vendor lock-in.
Event-Driven Architecture (EDA)	`Kafka/RabbitMQ` `services react to events`	• Services communicate through asynchronous event streams rather than direct calls • enables loose coupling and real-time processing but requires careful event schema management.
Layered Architecture (N-Tier)	`Presentation → Business → Data` `(3-tier or more)`	• Application divided into horizontal layers with each layer depending only on layers below • provides separation of concerns but can lead to bloated middle tiers.
Service-Oriented Architecture (SOA)	`Enterprise Service Bus (ESB)` `connecting reusable services`	• Enterprise-scale approach with services communicating through a central bus • coarser-grained services than microservices, often using SOAP and focused on enterprise-wide reuse.
Cell-Based Architecture	`cell-router → cell-1 (users A-M)` `cell-router → cell-2 (users N-Z)`	• Workload partitioned into isolated, self-contained cells each serving a subset of traffic • failures stay within one cell, limiting blast radius to a small percentage of users.
Space-Based Architecture	`In-memory data grid` `with processing units`	• Removes database as bottleneck by using distributed in-memory storage (tuple spaces) • achieves extreme scalability for high-traffic applications but complex to implement.
Peer-to-Peer Architecture	`BitTorrent`, `blockchain nodes` `(each peer is client and server)`	• Decentralized network where nodes share resources directly • provides resilience and no single point of failure but challenging to coordinate and secure.

Table 2: Domain-Driven Design (DDD) Patterns

Pattern	Example	Description
Hexagonal Architecture (Ports & Adapters)	`core/` `├── ports/` `└── adapters/`	• Business logic isolated in core domain with ports (interfaces) and adapters (implementations) handling external interactions • enables a technology-agnostic core that is easy to test.

Table 3: Distributed System Patterns

Pattern	Example	Description
API Gateway Pattern	`gateway.api.com` `routes to user-svc, order-svc`	• Single entry point for all clients that routes requests to appropriate microservices • handles cross-cutting concerns like auth, rate limiting, and request aggregation.

Table 4: Communication Patterns

Pattern	Example	Description
REST (Representational State Transfer)	`GET /api/users/123` `POST /api/orders`	• HTTP-based communication using standard methods (GET, POST, PUT, DELETE) • stateless, widely supported, and human-readable but chattier than binary alternatives.