Modern Architecture Design Patterns for Scalable Applications

Many modern applications must be built at enterprise or internet scale, requiring scalability, availability, security, reliability, and resilience. This article discusses several design patterns that help achieve these goals in cloud‑native environments, describing each pattern, how to use it, and when it is appropriate.

1. Circuit Breaker

Distributed systems need to handle failures. When a service depends on remote services that may become unresponsive, endless retries are useless; a circuit breaker stops calls after detecting repeated failures and returns a fallback response. Popular implementations include Netflix Hystrix and sidecar proxies such as Envoy. Important to log and alert when the circuit opens, and consider a half‑open state for degraded service.

When to use: Remote service dependencies that may fail; high‑dependency services like master data.

When not to use: Purely local dependencies where the overhead is unnecessary.

2. Command and Query Responsibility Segregation (CQRS)

CQRS separates read (query) and write (command) operations into different models, often using separate data stores. This improves performance for workloads with heavy reads and writes, and allows independent scaling and optimization of each side. Cloud providers offer read replicas (e.g., Cloud SQL, Azure SQL DB, Amazon RDS) and NoSQL options like MongoDB or Elasticsearch for fast reads.

When to use: Applications with high read/write volume, need for read‑side performance tuning, or tolerance for eventual consistency.

When not to use: Simple CRUD applications without intensive read/write demands.

3. Event Sourcing

Event sourcing stores a sequence of domain events as a log; the current state is derived by replaying events. Useful for systems requiring strong audit trails or historical reconstruction, such as reservation or e‑commerce platforms. Cloud messaging services (Google Pub/Sub, Azure Service Bus, AWS SQS) combined with strongly consistent stores enable this pattern.

When to use: When CRUD is insufficient, for booking systems, shopping carts, payment flows, or when audit/history is required.

When not to use: When simple CRUD meets all requirements.

4. Sidecar

The sidecar pattern deploys auxiliary components (e.g., Envoy Proxy) in separate processes or containers alongside the main service, abstracting networking, observability, and security concerns. It can provide mutual TLS and integrate with service meshes.

When to use: Multiple heterogeneous microservices needing unified communication, security, or observability; legacy applications needing modern connectivity.

When not to use: Small numbers of services where the added complexity isn’t justified.

5. Backend‑for‑Frontend (BFF)

BFF creates dedicated backend services tailored to specific front‑end clients (mobile, desktop, etc.), allowing optimized responses, reduced payloads, and aggregation of multiple services. It can be implemented within an API gateway without maintaining separate services.

When to use: Different client types require distinct data shaping or performance optimizations; need to reduce communication overhead for mobile clients.

When not to use: When a single UI suffices for all users or when client experiences are identical.

6. Strangler

The Strangler pattern helps modernize legacy applications by gradually routing traffic through a new façade while the old system is incrementally replaced. It decouples migration activities and can be realized via API gateways.

When to use: Complex, high‑dependency legacy migrations (e.g., ERP replacement) where a phased approach is needed.

When not to use: Simple migrations where a direct cut‑over is easier.

Original article link: https://medium.com/better-programming/modern-day-architecture-design-patterns-for-software-professionals-9056ee1ed977