System Design Deep Dive: Architecture Patterns Explained

Table of Contents

1. Monolithic Architecture
2. Microservices Architecture
3. Serverless Architecture
4. Event-Driven Architecture
5. Layered Architecture
6. Client-Server Architecture
7. Peer-to-Peer (P2P) Architecture
8. Microservices vs. Serverless: Key Differences
9. How to Choose the Right Pattern
10. Conclusion
11. References

1. Monolithic Architecture

What is it?

A monolithic architecture is the traditional “all-in-one” model where an application’s components (UI, business logic, data access, etc.) are tightly integrated into a single codebase and deployed as a single unit. Think of it as a single, cohesive block where every part depends on the others.

Core Principles

• Single Deployment Unit: The entire application is built, tested, and deployed as one package (e.g., a JAR file, WAR file, or executable).
• Tightly Coupled Components: Modules share memory and often a single database, with direct method calls between them.
• Unified Tech Stack: The entire application uses the same programming language, frameworks, and libraries.

Components

• Presentation Layer: Handles user interactions (e.g., web pages, mobile screens).
• Business Logic Layer: Implements core rules and workflows (e.g., order processing, user authentication).
• Data Access Layer: Manages interactions with the database (e.g., SQL queries, ORM tools like Hibernate).
• Shared Database: A single database supports all components.

How It Works

1. A user sends a request (e.g., via a web browser).
2. The request is routed to the monolithic application server.
3. The server processes the request by invoking methods across its internal layers (presentation → business logic → data access).
4. A response is generated and sent back to the user.

Pros

• Simplicity: Easy to develop, test, and deploy initially (no complex distributed systems overhead).
• Low Latency: Components communicate via in-memory method calls, avoiding network delays.
• Simplified Debugging: Logs and errors are centralized, making troubleshooting easier.

Cons

• Scaling Challenges: The entire app must scale (e.g., add more servers) even if only one component (e.g., the payment module) is under load.
• Tech Stack Lock-in: Upgrading frameworks or languages requires modifying the entire codebase.
• Deployment Risk: A small change in one module requires redeploying the entire application, increasing downtime risk.

Use Cases

• Small to medium-sized applications with simple requirements (e.g., internal tools, blogs).
• Startups with limited engineering resources (prioritizing speed to market over scalability).

2. Microservices Architecture

What is it?

Microservices architecture decomposes an application into a collection of loosely coupled, independently deployable services, each focused on a specific business capability (e.g., user authentication, product catalog, payment processing). Services communicate via well-defined APIs (e.g., REST, gRPC) and often own their data stores.

Core Principles

• Single Responsibility: Each service handles one business function (e.g., “user management” or “order fulfillment”).
• Autonomy: Teams can develop, deploy, and scale services independently without disrupting others.
• Resilience: A failure in one service (e.g., payment) doesn’t bring down the entire application.

Components

• Services: Independent codebases (e.g., Node.js for user service, Python for recommendation service).
• API Gateway: Acts as a single entry point for client requests, routing them to the appropriate service (e.g., AWS API Gateway, Kong).
• Service Discovery: Helps services locate each other dynamically (e.g., Kubernetes Service, Consul).
• Databases per Service: Each service owns its database (e.g., PostgreSQL for user data, MongoDB for product catalog).

How It Works

1. A client sends a request to the API Gateway.
2. The gateway routes the request to the relevant microservice (e.g., “payment service”).
3. The service processes the request (e.g., checks credit card validity) using its own database.
4. The service returns a response to the gateway, which forwards it to the client.

Pros

• Independent Scaling: Scale high-traffic services (e.g., product search) without scaling low-traffic ones (e.g., admin tools).
• Tech Diversity: Teams can choose the best tools for their service (e.g., Go for high-performance services, Python for data-heavy ones).
• Faster Deployments: Smaller codebases mean quicker testing and deployment cycles (e.g., deploy a payment service update without touching the product catalog).

Cons

• Complexity: Managing distributed systems requires handling network latency, data consistency, and service discovery.
• Operational Overhead: More services mean more deployments, monitoring, and debugging (e.g., tracking a transaction across 5 services).
• Data Consistency: Maintaining consistency across independent databases (e.g., ensuring an order is created only if payment succeeds) is challenging.

Use Cases

• Large-scale applications with diverse requirements (e.g., Amazon: product, inventory, payment, and shipping services).
• Organizations with multiple teams (e.g., Netflix: separate teams for recommendations, streaming, and user accounts).

3. Serverless Architecture

What is it?

Serverless architecture (or “Function-as-a-Service” / FaaS) abstracts infrastructure management entirely. Developers write stateless functions that run in response to events (e.g., an API call, a file upload), and cloud providers (AWS, Azure, Google Cloud) handle server provisioning, scaling, and maintenance.

Core Principles

• No Server Management: Developers focus solely on code; cloud providers manage servers, scaling, and patching.
• Event-Driven: Functions trigger automatically in response to events (e.g., a new image uploaded to S3 → resize function runs).
• Pay-per-Use: You only pay for the compute time your functions consume (e.g., $0.00001667 per GB-second on AWS Lambda).

Components

• Serverless Functions: Short-lived, stateless code snippets (e.g., AWS Lambda, Azure Functions, Google Cloud Functions).
• Event Sources: Triggers that invoke functions (e.g., API Gateway, S3, IoT sensors, message queues).
• Stateless Storage: Since functions are ephemeral, data is stored externally (e.g., DynamoDB, Firebase, Redis).

How It Works

1. An event occurs (e.g., a user submits a form via API Gateway).
2. The cloud provider detects the event and invokes the associated function.
3. The function runs (e.g., validates the form data, saves to a database).
4. The function exits, and resources are released.

Pros

• Cost Efficiency: No idle server costs—pay only for execution time.
• Infinite Scalability: Functions scale automatically (e.g., 1000 concurrent API calls → 1000 function instances spin up).
• Reduced Maintenance: No need to manage servers, operating systems, or scaling policies.

Cons

• Cold Starts: If a function hasn’t run recently, there may be a delay (10ms–1s) while the cloud provider provisions resources.
• Vendor Lock-in: Functions are tied to specific cloud providers (e.g., AWS Lambda uses AWS-specific triggers like S3).
• Stateless Limitations: Functions can’t store state between invocations, requiring external storage (adds latency).

Use Cases

• Event-driven workloads (e.g., resizing images uploaded to S3, processing logs in real time).
• Low-traffic or variable-traffic applications (e.g., a chatbot that’s busy during business hours but idle at night).

4. Event-Driven Architecture

What is it?

Event-Driven Architecture (EDA) centers on the production, detection, consumption, and reaction to events—messages that represent a change in state (e.g., “order placed,” “payment failed”). Components communicate asynchronously via events, enabling loose coupling and real-time responsiveness.

Core Principles

• Event Production/Consumption: Components are either “producers” (emit events) or “consumers” (react to events).
• Loose Coupling: Producers don’t know or care which consumers use their events (e.g., a “payment received” event could trigger order fulfillment and email notifications).

Components

• Event: A immutable record of a state change (e.g., {type: "ORDER_CREATED", data: {orderId: 123, items: [...]}}).
• Event Bus/Stream: A central channel for events (e.g., Apache Kafka for high-throughput streams, RabbitMQ for message queues).
• Producers: Services that emit events (e.g., a payment service emits “payment_completed”).
• Consumers: Services that react to events (e.g., a shipping service consumes “payment_completed” to schedule delivery).

How It Works

1. A producer detects a state change (e.g., a user places an order) and emits an event to the event bus.
2. The event bus broadcasts the event to all subscribed consumers.
3. Consumers process the event independently (e.g., update inventory, send a confirmation email).

Pros

• Scalability: Consumers can scale independently (e.g., add more inventory consumers during sales).
• Resilience: If a consumer fails, events remain in the bus until processed (no data loss).
• Flexibility: Add new consumers without modifying producers (e.g., add a “fraud detection” consumer to “payment_completed” events).

Cons

• Complex Event Flow: Tracking a transaction across multiple events (e.g., order → payment → shipping) is hard to debug.
• Consistency Challenges: Ensuring all consumers process events in the correct order (e.g., “order_created” before “payment_completed”).

Use Cases

• Real-time systems (e.g., stock trading platforms: “price_updated” events trigger buy/sell algorithms).
• Workflow automation (e.g., e-commerce order processing: order → payment → inventory → shipping).

5. Layered Architecture

What is it?

Layered architecture (or “n-tier architecture”) organizes an application into horizontal layers, each with a specific responsibility. Requests flow sequentially through layers, and each layer only interacts with adjacent layers (e.g., presentation → business logic → data access).

Core Principles

• Separation of Concerns: Each layer handles one type of task (e.g., presentation layers handle UI, business logic handles rules).
• Layer Isolation: Layers depend only on the layer below (e.g., business logic can’t directly access the database; it must go through the data access layer).

Components

• Presentation Layer: User interface and API endpoints (e.g., React frontend, REST controllers).
• Business Logic Layer: Core application rules (e.g., “users must be 18+ to register,” “discounts apply to orders over $100”).
• Data Access Layer: Interactions with databases (e.g., SQL queries, ORM tools like Entity Framework).
• (Optional) Cross-Cutting Layers: Logging, authentication, or error handling (span all layers).

How It Works

1. A user interacts with the presentation layer (e.g., submits a form).
2. The presentation layer passes the request to the business logic layer for validation and processing.
3. The business logic layer uses the data access layer to read/write data.
4. Results flow back up the layers to the user.

Pros

• Maintainability: Changes to one layer (e.g., updating the UI) don’t affect others (e.g., business logic).
• Testability: Layers can be tested in isolation (e.g., mock the data access layer to test business logic).

Cons

• Rigidity: Adding new features may require changes across layers (e.g., a new UI field needs updates in presentation, business logic, and data access).
• Performance Overhead: Requests must traverse all layers, even for simple tasks.

Use Cases

• Enterprise applications with strict separation of concerns (e.g., CRM systems, banking portals).

6. Client-Server Architecture

What is it?

Client-server architecture is a two-tier model where clients (user-facing devices/apps) request resources or services from servers (centralized machines). Servers manage data and logic, while clients handle presentation.

Core Principles

• Centralized Data: Servers store and manage shared data (e.g., a database server holds all user accounts).
• Separation of Roles: Clients request services; servers fulfill them.

Components

• Client: A device or application that sends requests (e.g., a web browser, mobile app, desktop software).
• Server: A powerful machine that processes requests and manages resources (e.g., a web server, database server, file server).

How It Works

1. A client sends a request to the server (e.g., “fetch user profile for ID 456”).
2. The server processes the request (e.g., queries the database).
3. The server returns a response to the client (e.g., user profile data).

Pros

• Centralized Control: Servers enforce security, backups, and data consistency (e.g., only the server can modify user data).
• Scalability: Servers can scale vertically (bigger hardware) or horizontally (more servers) to handle client load.

Cons

• Single Point of Failure: If the server crashes, all clients lose access to the service.
• Network Dependency: Clients rely on network connectivity to communicate with the server.

Use Cases

• Traditional web applications (e.g., Gmail: browser/client → Google’s servers).
• File-sharing systems (e.g., Dropbox: client app → Dropbox servers).

7. Peer-to-Peer (P2P) Architecture

What is it?

Peer-to-Peer (P2P) architecture eliminates central servers entirely. Instead, nodes (computers/ devices) act as both clients and servers, sharing resources (e.g., files, bandwidth, computing power) directly with each other.

Core Principles

• Decentralization: No single node controls the network; all nodes have equal status.
• Resource Sharing: Nodes contribute resources (e.g., storage, CPU) to the network.

Components

• Node: A device in the network (e.g., a laptop, smartphone).
• Distributed Hash Table (DHT): A protocol to locate resources across nodes (e.g., BitTorrent uses DHT to find peers with a specific file).

How It Works

1. A node joins the network and advertises the resources it can share (e.g., a portion of a file).
2. To find a resource (e.g., a movie), a node queries the DHT to locate peers with that resource.
3. The node downloads the resource directly from other peers (e.g., downloading chunks of a file from 5 different nodes).

Pros

• Fault Tolerance: No single point of failure—if one node leaves, others continue operating.
• Scalability: Adding more nodes increases network capacity (more resources to share).

Cons

• Security Risks: Direct node communication makes it harder to enforce security (e.g., malware spread via P2P networks).
• Inconsistent Performance: Resource quality depends on peer availability (e.g., slow download if peers have low bandwidth).

Use Cases

• File sharing (e.g., BitTorrent, LimeWire).
• Decentralized networks (e.g., blockchain, where nodes validate transactions collectively).

8. Microservices vs. Serverless: Key Differences

9. How to Choose the Right Pattern

Selecting an architecture pattern depends on:

• Team Size: Small teams may prefer monolithic or serverless (less operational overhead).
• Scalability Needs: High-traffic apps may need microservices or serverless (independent scaling).
• Development Speed: Startups may prioritize monolithic (fast initial development) over microservices (complexity).
• Cost: Serverless reduces infrastructure costs for variable workloads; monolithic may be cheaper for steady traffic.

10. Conclusion

Architecture patterns are not one-size-fits-all—they are tools to solve specific problems. A monolithic app may be ideal for a startup, while a global e-commerce platform demands microservices. By understanding the tradeoffs of each pattern, you can design systems that scale, remain maintainable, and meet your project’s unique needs.

11. References

• Fowler, M. (2014). Microservices Guide. martinfowler.com/articles/microservices.html
• AWS Architecture Center. (n.d.). Serverless Architecture. aws.amazon.com/serverless/architectures/
• Richman, N. (2020). System Design Interview: An Insider’s Guide. ByteByteGo.
• Kafka Documentation. (n.d.). Event-Driven Architecture. kafka.apache.org/documentation/streams/