30 Essential Architecture Patterns for Scalable and Resilient Systems

Management and Monitoring

1.1 Ambassador Mode

Creates an external proxy service that represents consumer‑facing applications, handling routing, circuit breaking, tracing, monitoring, authorization, encryption, and logging. Suitable for multi‑language, multi‑framework environments, but adds network overhead and deployment complexity.

1.2 Anti‑Corruption Mode

Introduces a façade layer between modern applications and legacy systems, allowing new services to use fresh communication styles while preserving legacy systems until they can be retired.

1.3 External Configuration Store

Moves configuration data out of application packages into a centralized configuration service, improving manageability, security, and sharing across large sites.

1.4 Gateway Aggregation Mode

Uses a gateway to concurrently invoke multiple downstream services, aggregate results, and return a single response, improving performance and reducing client request count. Implementable with OpenResty or Nginx.

1.5 Gateway Off‑loading Mode

Places non‑business‑critical functions such as SSL termination in a gateway layer, typically using Nginx, to simplify internal services.

1.6 Gateway Routing Mode

Routes external API endpoints (e.g., /cart, /order) to appropriate backend services, enabling load balancing, versioned routing, and consistent external interfaces.

1.7 Health‑Endpoint Monitoring Mode

Exposes detailed health information (service status, dependency health, thread‑pool metrics, etc.) via a health endpoint, often implemented with Spring Boot Actuator, to support external monitoring and automated failover.

1.8 Strangler Fig Mode

Gradually replaces legacy components by routing traffic through a façade that forwards to new services, allowing seamless migration without user impact.

Performance and Scalability

2.1 Cache‑Assisted Mode

Loads data on demand into an in‑process cache, achieving near‑100% hit rates for relatively static data and eliminating cross‑process communication.

2.2 CQRS (Command‑Query Responsibility Segregation) Mode

Separates read and write models, allowing independent optimization, often combined with event sourcing and materialized views.

2.3 Event Sourcing Mode

Stores a sequence of immutable events rather than current state, enabling high write throughput, auditability, and low‑coupling processing.

2.4 Materialized View Mode

Pre‑computes and stores query‑optimized data structures to avoid costly joins, suitable for complex or multi‑source queries but less ideal for highly mutable data.

2.5 Queue‑Based Load Balancing Mode

Uses a message queue as a buffer between producers and consumers to smooth burst traffic; requires careful sizing to ensure consumer throughput exceeds peak enqueue rates.

2.6 Priority Queue Mode

Assigns priorities to messages, allowing high‑priority requests to be processed first, either via real‑time reordering or dedicated processing pools.

2.7 Rate‑Limiting Mode

Controls resource consumption using algorithms such as fixed‑window counters, token bucket, or leaky bucket, typically placed early in the request pipeline.

Data Management Modes

3.1 Sharding Mode

Partitions data horizontally into multiple shards to handle high write throughput; requires routing logic, code changes, and operational tooling for unified indexing and reporting.

3.2 Static Content Hosting Mode

Offloads static assets to cloud storage/CDN, reducing backend load and improving client latency; considerations include cache invalidation, versioned filenames, and error monitoring.

3.3 Index Table Mode

Creates dedicated index tables for frequently queried fields to avoid full‑table scans, especially useful when sharding limits cross‑shard queries.

Design and Implementation Modes

4.1 Frontend‑Specific Backend Mode

Maintains separate backend services for different frontends (e.g., PC website vs. mobile app) when data contracts diverge significantly.

4.2 Compute Resource Consolidation Mode

Aggregates multiple tasks into a single compute unit to reduce resource overhead.

4.3 Leader Election Mode

Elects a single instance to coordinate distributed tasks, commonly implemented with Zookeeper using either non‑fair (ephemeral‑non‑sequential) or fair (ephemeral‑sequential) algorithms.

4.4 Pipeline and Filter Mode

Chains independent processing filters (e.g., in Spring MVC or Netty) to build flexible, reusable pipelines.

Messaging Modes

5.1 Competing Consumer Mode

Deploys multiple stateless consumers that compete for messages from a single queue, enabling horizontal scaling.

5.2 Retry Mode

Automatically retries transient failures with configurable attempts, exception filters, and back‑off strategies, either client‑initiated or middleware‑driven.

5.3 Scheduler‑Proxy‑Supervisor Mode

Coordinates distributed operations using three roles: scheduler (task orchestration), proxy (service communication), and supervisor (monitoring and compensation).

Resilience Modes

6.1 Bulkhead Mode

Isolates resources (threads, queues, services) into separate pools so that failure in one does not cascade to others.

6.2 Circuit Breaker Mode

Detects repeated failures and opens a circuit to prevent further calls, with half‑open probing to restore service when healthy.

6.3 Transaction Compensation Mode

Implements compensating actions for multi‑step operations to achieve eventual consistency when failures occur.

Security Modes

7.1 Delegated Key Mode

Issues short‑lived tokens or keys that grant clients direct access to protected resources, reducing the need for a proxy.

7.2 Federated Identity Mode

Delegates authentication to an external identity provider (e.g., OAuth 2.0 via Spring Security) to enable single sign‑on and simplify service implementations.

In summary, the thirty patterns span design details and overarching philosophies; they are often combined, and selecting the right mix yields clearer, more maintainable architectures.