← Back

Patterns That Shape Software

Architectural, System, and Design Patterns solve problems at different layers of software development. This article breaks them down with simple explanations and a visual comparison.

Published on 31 jan 2026

1. What are Architectural Patterns?

Architectural patterns define the overall structure of a software system by organizing components and their interactions to achieve scalability, maintainability, and separation of concerns.

They answer:

1. How is the application structured?
2. How do layers/services communicate?
3. How do we separate responsibilities?

   Blueprint of the application

1.2 Common Architectural Patterns

1.2.1 Layered Architecture

Organizes the system into layers:

Presentation
Business Logic
Data Access
Database

1. Easy to understand
2. Widely used in enterprise apps

1.2.2 MVC (Model–View–Controller)

Separates:

Model → Data & business logic
View → UI
Controller → Handles input

1. Clean separation
2. Popular in web frameworks

1.2.3 Microservices Architecture

System is split into independent services:

- Each service has its own DB
- Communicate via APIs or events

1. Highly scalable
2. Fault isolation

1.2.4 Event-Driven Architecture

Components communicate using events:

- Producers emit events
- Consumers react

1. Loose coupling
2. High scalability

1.2.5 Clean / Hexagonal Architecture

Focuses on:

- Business logic at the center
- External systems as plugins

1. Highly testable
2. Framework-independent

2. What are System Patterns?

System patterns are high-level runtime patterns that describe how a system behaves in production—especially around scalability, reliability, availability, and fault tolerance.

1. If architectural patterns define how the system is structured,
2. system patterns define how the system survives under real-world load and failures.

2.1 What problems do System Patterns solve?

They answer questions like:

1. How do we scale when traffic increases?
2. What happens if a service fails?
3. How do we avoid cascading failures?
4. How do we keep the system fast and stable?

2.2 Common System Patterns

2.2.1 Load Balancer Pattern

Distributes incoming requests across multiple servers.

Why?

1. Prevents server overload
2. Improves availability

2.2.2 Cache-Aside Pattern

Application checks cache first → DB only if needed.

Why?

1. Faster responses
2. Reduced database load

2.2.3 Circuit Breaker Pattern

Stops calls to a failing service temporarily.

Why?

1. Prevents cascading failures
2. Allows recovery time

2.2.4 Retry & Timeout Pattern

Retries failed requests with limits and timeouts.

Why?

1. Handles transient network issues
2. Prevents indefinite waits

2.2.5 CQRS (Command Query Responsibility Segregation)

Separates read and write models.

Why?

1. Optimizes performance
2. Handles high read/write loads

2.2.6 Saga Pattern

Manages distributed transactions across services.

Why?

1. Ensures consistency in microservices
2. Avoids 2-phase commit issues

2.2.7 Rate Limiting Pattern

Limits how many requests a client can make.

Why?

1. Prevents abuse
2. Protects APIs from DDoS

3. What are Design Patterns?

Design patterns are reusable, proven solutions to common problems in code design. They guide how classes and objects are structured and interact, without being tied to a specific language.

Design patterns = best practices for writing flexible, maintainable code

3.1 What problems do Design Patterns solve?

They help you:

1. Avoid reinventing the wheel
2. Reduce tight coupling
3. Improve readability & maintainability
4. Make code easier to extend and test

3.2 Key Characteristics

1. Code-level (LLD)
2. Language-independent concepts
3. Describe solutions, not implementations
4. can be combined together

3.3 Categories of Design Patterns (GoF – 23)

3.3.1 Creational Patterns

Focus: Object creation

1. Singleton – One instance only
2. Factory Method – Subclass decides object creation
3. Abstract Factory – Factory of factories
4. Builder – Step-by-step object construction
5. Prototype – Clone existing objects

3.3.2 Structural Patterns

1. Focus: Class & object composition
2. Adapter – Make incompatible interfaces work
3. Decorator – Add behavior dynamically
4. Facade – Simplified interface to complex system
5. Proxy – Control access to object
6. Composite – Tree-like structure
7. Bridge – Separate abstraction from implementation
8. Flyweight – Memory optimization

3.3.2 ehavioral Patterns

1. Focus: Communication & responsibility
2. Observer – Event-based notifications
3. Strategy – Switch algorithms at runtime
4. Command – Encapsulate a request
5. State – Change behavior based on state
6. Template Method – Define algorithm skeleton
7. Iterator – Sequential access
8. Mediator – Centralized communication
9. Chain of Responsibility
10. Memento
11. Visitor
12. Interpreter

4. Where Design Patterns Fit

1. Architectural Patterns → HLD (structure)
2. System Patterns → Runtime behavior
3. Design Patterns → Code (LLD)

Recommended Articles

Building a serverless data ingestion pipeline with aws (S3, Lambda, SQS, DynamoDB)

TypeScript — Complete Developer Guide

From Console to Code: Building an Automated SQS-to-DynamoDB Pipeline with AWS SAM