Web Architecture & Design Patterns — ออกแบบระบบให้ Scale ได้และดูแลง่าย 🏗️Web Architecture & Design Patterns — Building Systems That Scale and Stay Maintainable 🏗️

// ═══════════════════════════════
// MVC Example — Express.js
// ═══════════════════════════════

// Model — Database interaction
// models/Order.ts
class OrderModel {
  static async create(data: OrderInput): Promise<Order> {
    const result = await db.query(
      'INSERT INTO orders (user_id, total, status) VALUES ($1, $2, $3) RETURNING *',
      [data.userId, data.total, 'pending']
    );
    return result.rows[0];
  }

  static async findByUser(userId: string): Promise<Order[]> {
    return db.query('SELECT * FROM orders WHERE user_id = $1 ORDER BY created_at DESC', [userId]);
  }
}

// Controller — Business logic
// controllers/orderController.ts
class OrderController {
  static async createOrder(req: Request, res: Response) {
    try {
      const { items } = req.body;
      
      // Business logic
      const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
      const order = await OrderModel.create({ userId: req.user.id, total });
      
      // Respond
      res.status(201).json({ order });
    } catch (err) {
      res.status(500).json({ error: 'Failed to create order' });
    }
  }
}

// View — Routes (API = JSON response)
// routes/orders.ts
router.post('/orders', authenticate, OrderController.createOrder);
router.get('/orders', authenticate, OrderController.listOrders);

// ═══════════════════════════════
// Layered Architecture Example
// ═══════════════════════════════

// Repository Layer — Data access only
// repositories/orderRepository.ts
class OrderRepository {
  async create(data: CreateOrderDTO): Promise<Order> {
    return prisma.order.create({ data });
  }

  async findById(id: string): Promise<Order | null> {
    return prisma.order.findUnique({ 
      where: { id },
      include: { items: true, user: true }
    });
  }

  async findByUser(userId: string): Promise<Order[]> {
    return prisma.order.findMany({
      where: { userId },
      orderBy: { createdAt: 'desc' }
    });
  }
}

// Service Layer — Business logic
// services/orderService.ts
class OrderService {
  constructor(
    private orderRepo: OrderRepository,
    private productRepo: ProductRepository,
    private paymentService: PaymentService,
    private notificationService: NotificationService,
  ) {}

  async createOrder(userId: string, items: CartItem[]): Promise<Order> {
    // 1. Validate stock
    for (const item of items) {
      const product = await this.productRepo.findById(item.productId);
      if (!product) throw new NotFoundError(`Product ${item.productId} not found`);
      if (product.stock < item.quantity) throw new ValidationError(`Insufficient stock for ${product.name}`);
    }

    // 2. Calculate total
    const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);

    // 3. Create order
    const order = await this.orderRepo.create({
      userId,
      total,
      status: 'pending',
      items: items.map(i => ({
        productId: i.productId,
        quantity: i.quantity,
        price: i.price,
      })),
    });

    // 4. Reserve stock
    for (const item of items) {
      await this.productRepo.decrementStock(item.productId, item.quantity);
    }

    // 5. Send notification
    await this.notificationService.sendOrderConfirmation(userId, order);

    return order;
  }
}

// Controller Layer — HTTP handling
// controllers/orderController.ts
class OrderController {
  constructor(private orderService: OrderService) {}

  createOrder = async (req: Request, res: Response) => {
    try {
      const { items } = req.body;
      
      // Input validation only
      if (!items?.length) {
        return res.status(400).json({ error: 'Items required' });
      }

      // Delegate to service
      const order = await this.orderService.createOrder(req.user.id, items);
      
      res.status(201).json({ data: order });
    } catch (err) {
      if (err instanceof ValidationError) {
        return res.status(400).json({ error: err.message });
      }
      if (err instanceof NotFoundError) {
        return res.status(404).json({ error: err.message });
      }
      res.status(500).json({ error: 'Internal server error' });
    }
  };
}

# ═══════════════════════════════
# GraphQL Schema Definition
# ═══════════════════════════════

type User {
  id: ID!
  name: String!
  email: String!
  avatar: String
  posts(limit: Int = 10, offset: Int = 0): [Post!]!
  followers: Int!
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
  comments: [Comment!]!
  likes: Int!
  createdAt: DateTime!
}

type Query {
  user(id: ID!): User
  users(limit: Int, offset: Int): [User!]!
  post(id: ID!): Post
  posts(status: PostStatus, limit: Int): [Post!]!
}

type Mutation {
  createPost(input: CreatePostInput!): Post!
  updatePost(id: ID!, input: UpdatePostInput!): Post!
  deletePost(id: ID!): Boolean!
}

# ═══════════════════════════════
# Client Queries
# ═══════════════════════════════

# Dashboard — 1 request แทน 4 requests
query Dashboard {
  me: user(id: "123") {
    name
    avatar
    followers
  }
  recentPosts: posts(limit: 5) {
    title
    likes
    createdAt
  }
}

# Mutation
mutation CreatePost {
  createPost(input: {
    title: "GraphQL is Awesome"
    content: "Here's why..."
  }) {
    id
    title
    createdAt
  }
}

// ═══════════════════════════════
// user.proto — Protocol Buffer Definition
// ═══════════════════════════════

syntax = "proto3";
package user;

service UserService {
  // Unary — request/response เดียว
  rpc GetUser (GetUserRequest) returns (User);
  rpc CreateUser (CreateUserRequest) returns (User);
  
  // Server streaming — server ส่ง stream กลับ
  rpc ListUsers (ListUsersRequest) returns (stream User);
  
  // Bidirectional streaming — ทั้ง 2 ฝั่ง stream
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message User {
  string id = 1;
  string name = 2;
  string email = 3;
  UserRole role = 4;
  int64 created_at = 5;
}

enum UserRole {
  MEMBER = 0;
  EDITOR = 1;
  ADMIN = 2;
}

message GetUserRequest {
  string id = 1;
}

message CreateUserRequest {
  string name = 1;
  string email = 2;
  string password = 3;
}

// ═══════════════════════════════
// Producer — Order Service
// ═══════════════════════════════
import amqp from 'amqplib';

class OrderService {
  private channel: amqp.Channel;

  async connect() {
    const conn = await amqp.connect('amqp://localhost');
    this.channel = await conn.createChannel();
    
    // Declare exchange (topic-based routing)
    await this.channel.assertExchange('events', 'topic', { durable: true });
  }

  async createOrder(userId: string, items: CartItem[]) {
    // 1. Business logic
    const order = await this.orderRepo.create({ userId, items });
    
    // 2. Publish event (async, non-blocking)
    const event = {
      type: 'order.created',
      data: {
        orderId: order.id,
        userId,
        items,
        total: order.total,
        timestamp: new Date().toISOString(),
      },
    };

    this.channel.publish(
      'events',
      'order.created',
      Buffer.from(JSON.stringify(event)),
      { persistent: true }  // Survives broker restart
    );

    return order;  // Return immediately!
  }
}

// ═══════════════════════════════
// Consumer — Email Service
// ═══════════════════════════════
class EmailConsumer {
  async start() {
    const conn = await amqp.connect('amqp://localhost');
    const channel = await conn.createChannel();

    await channel.assertExchange('events', 'topic', { durable: true });

    // Create queue for this consumer
    const q = await channel.assertQueue('email-service', { durable: true });
    
    // Bind to events we care about
    await channel.bindQueue(q.queue, 'events', 'order.created');
    await channel.bindQueue(q.queue, 'events', 'user.registered');

    // Process messages
    channel.prefetch(10);  // Process 10 at a time
    channel.consume(q.queue, async (msg) => {
      if (!msg) return;

      try {
        const event = JSON.parse(msg.content.toString());

        switch (event.type) {
          case 'order.created':
            await sendOrderConfirmation(event.data);
            break;
          case 'user.registered':
            await sendWelcomeEmail(event.data);
            break;
        }

        channel.ack(msg);  // ✅ Message processed
      } catch (err) {
        channel.nack(msg, false, true);  // ❌ Retry (requeue)
      }
    });
  }
}

🐕 Why Should You Care About Architecture?

Architecture is the heart of software development, and it is the part most people skip. It is not about writing code that works — it is about designing a structure that lets the system scale, stay maintainable, and keep growing over the long term.

The difference between good code and good architecture is the difference between a beautifully decorated house and a well-drawn floor plan. A pretty house on a bad plan can collapse; a house on a good plan can be redecorated later even if it looks plain today.

---

🏢 Monolith vs Microservices

Choosing between a monolith and microservices is one of the most frequently asked questions of this era. Many people treat microservices as a "silver bullet" that solves everything, but in reality each approach has its own trade-offs, and the choice depends on the context of the project and the team.

Most companies start with a monolith, because it is easy to understand, fast to develop, and simple to deploy — then split into microservices as the team and the system grow.

Monolith — Everything in One Piece

A monolith is an architecture that keeps every feature of the app in a single codebase, deployed as one unit, running in one process, sharing one database. It suits startups and small teams that need to ship features fast.

Comparison Table

	Monolith	Microservices
Complexity	⭐ Simple	⭐⭐⭐ Complex
Development	⚡ Fast start	🐢 Slower setup
Deployment	All or nothing	Independent
Scaling	Scale everything	Scale per service
Tech stack	One stack	Mix & match
Data consistency	✅ Easy (1 DB)	⚠️ Eventual
Debugging	✅ Stack trace	⚠️ Distributed
Team size	1-15 devs	10-100+ devs
Fault isolation	❌ One bug = entire app down	✅ Service fails others survive
Communication	Function calls (fast)	Network (HTTP, gRPC, queues)
DevOps needs	⭐ Basic	⭐⭐⭐ K8s, etc.
Cost	💰 Lower	💰💰💰 Higher

💡 Start with Monolith → Extract to Microservices when you actually NEED to

"Don't start with microservices unless you have a very good reason." — Martin Fowler

Microservices split an application into many small services that run separately. Each service has one job, owns its own database, and talks to the others over the network (HTTP, gRPC, message queues).

The upside is that each service scales independently, can use a different tech stack, is owned by a separate team, and one service falling over does not take the others with it. The downside is deployment complexity, harder debugging, and network latency.

Modular Monolith — Best of Both Worlds

The modular monolith is a good compromise between the simplicity of a monolith and the modularity of microservices: the code is split into modules with clear boundaries, but it still deploys as a single unit.

Each module exposes its own API interface, never reaches into another module's database directly, and can be extracted into a microservice easily later. This is exactly what Martin Fowler means by "start with a monolith, then split."

---

📐 Design Patterns — MVC, MVVM, Clean Architecture

Design patterns are ways of organizing code so that it has a clear structure, a clean separation of responsibilities, and stays maintainable. Each pattern suits a different use case and carries a different level of complexity.

Choose a design pattern by looking at the size of the project, the complexity of the business logic, and the size of the team. Do not drag Clean Architecture into a small CRUD project — all you will get is complexity for nothing.

MVC (Model-View-Controller)

MVC is the foundational pattern that splits an application into three parts: the Model (data and business logic), the View (presentation), and the Controller (handling user input and orchestrating the work).

It suits web applications that render pages on the server — Rails, Django, Laravel, or Express.js with a template engine such as EJS. For an API it collapses to just Controller and Model, because there is no View (you return JSON).

// ═══════════════════════════════
// MVC Example — Express.js
// ═══════════════════════════════

// Model — Database interaction
// models/Order.ts
class OrderModel {
  static async create(data: OrderInput): Promise<Order> {
    const result = await db.query(
      'INSERT INTO orders (user_id, total, status) VALUES ($1, $2, $3) RETURNING *',
      [data.userId, data.total, 'pending']
    );
    return result.rows[0];
  }

  static async findByUser(userId: string): Promise<Order[]> {
    return db.query('SELECT * FROM orders WHERE user_id = $1 ORDER BY created_at DESC', [userId]);
  }
}

// Controller — Business logic
// controllers/orderController.ts
class OrderController {
  static async createOrder(req: Request, res: Response) {
    try {
      const { items } = req.body;

      // Business logic
      const total = items.reduce((sum, item) => sum + item.price * item.qty, 0);
      const order = await OrderModel.create({ userId: req.user.id, total });

      // Respond
      res.status(201).json({ order });
    } catch (err) {
      res.status(500).json({ error: 'Failed to create order' });
    }
  }
}

// View — Routes (API = JSON response)
// routes/orders.ts
router.post('/orders', authenticate, OrderController.createOrder);
router.get('/orders', authenticate, OrderController.listOrders);

Layered Architecture — Controller → Service → Repository

Layered architecture, or N-tier architecture, divides the application into layers with clear responsibilities. Each layer calls only the layer directly beneath it — never skipping a layer, never calling back upward.

This pattern suits business applications with complicated business logic, because the separation of concerns is explicit: it is easy to test, easy to change, and easy for a team to divide the work. If your logic is not complicated, it is overkill.

// ═══════════════════════════════
// Layered Architecture Example
// ═══════════════════════════════

// Repository Layer — Data access only
// repositories/orderRepository.ts
class OrderRepository {
  async create(data: CreateOrderDTO): Promise<Order> {
    return prisma.order.create({ data });
  }

  async findById(id: string): Promise<Order | null> {
    return prisma.order.findUnique({
      where: { id },
      include: { items: true, user: true }
    });
  }

  async findByUser(userId: string): Promise<Order[]> {
    return prisma.order.findMany({
      where: { userId },
      orderBy: { createdAt: 'desc' }
    });
  }
}

// Service Layer — Business logic
// services/orderService.ts
class OrderService {
  constructor(
    private orderRepo: OrderRepository,
    private productRepo: ProductRepository,
    private paymentService: PaymentService,
    private notificationService: NotificationService,
  ) {}

  async createOrder(userId: string, items: CartItem[]): Promise<Order> {
    // 1. Validate stock
    for (const item of items) {
      const product = await this.productRepo.findById(item.productId);
      if (!product) throw new NotFoundError(`Product ${item.productId} not found`);
      if (product.stock < item.quantity) throw new ValidationError(`Insufficient stock for ${product.name}`);
    }

    // 2. Calculate total
    const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);

    // 3. Create order
    const order = await this.orderRepo.create({
      userId,
      total,
      status: 'pending',
      items: items.map(i => ({
        productId: i.productId,
        quantity: i.quantity,
        price: i.price,
      })),
    });

    // 4. Reserve stock
    for (const item of items) {
      await this.productRepo.decrementStock(item.productId, item.quantity);
    }

    // 5. Send notification
    await this.notificationService.sendOrderConfirmation(userId, order);

    return order;
  }
}

// Controller Layer — HTTP handling
// controllers/orderController.ts
class OrderController {
  constructor(private orderService: OrderService) {}

  createOrder = async (req: Request, res: Response) => {
    try {
      const { items } = req.body;

      // Input validation only
      if (!items?.length) {
        return res.status(400).json({ error: 'Items required' });
      }

      // Delegate to service
      const order = await this.orderService.createOrder(req.user.id, items);

      res.status(201).json({ data: order });
    } catch (err) {
      if (err instanceof ValidationError) {
        return res.status(400).json({ error: err.message });
      }
      if (err instanceof NotFoundError) {
        return res.status(404).json({ error: err.message });
      }
      res.status(500).json({ error: 'Internal server error' });
    }
  };
}

Clean Architecture / Hexagonal Architecture

Clean Architecture (or Hexagonal Architecture) is a pattern built around separating business logic from external dependencies such as the database, the web framework, and external APIs, using the principle of "Dependency Inversion".

The core idea is the "Dependency Rule": dependencies may point inward only, and inner layers know nothing at all about outer layers. That makes business logic independent of the framework and the database, and easy to test — at the cost of more code and more complexity.

It suits large projects with complicated business rules, projects that need high testability, or projects that change technology stack often. For ordinary CRUD it is overkill.

---

🌐 API Styles — REST vs GraphQL vs gRPC

Choosing an API style is a consequential decision: it shapes frontend development, mobile apps, and service-to-service communication. Each style has its own strengths and use cases — and you do not have to pick only one.

Plenty of companies run several styles at once: REST for the public API, GraphQL for the mobile app, gRPC for internal services. Understanding the trade-offs of each is what lets you choose correctly.

REST — Resource-based

REST (Representational State Transfer) is an architectural style that uses HTTP methods (GET, POST, PUT, DELETE) against URLs to manage resources. It is a standard that is easy to understand, has enormous tooling support, and caches well over HTTP.

But REST has its problems: over-fetching (you get more data than you asked for), under-fetching (you have to call several endpoints), and the N+1 problem that comes from fetching related data separately.

GraphQL — Query-based

GraphQL solves REST's problem by letting the client state exactly what data it wants, through a single endpoint — one POST /graphql. The client writes a query naming the fields it needs, and the server returns only those.

The upside is that over- and under-fetching disappear, the number of API calls drops, the schema is strongly typed, and introspection powers the development tools. The downside is that caching is hard, complexity is higher, and you have to learn the GraphQL query language.

# ═══════════════════════════════
# GraphQL Schema Definition
# ═══════════════════════════════

type User {
  id: ID!
  name: String!
  email: String!
  avatar: String
  posts(limit: Int = 10, offset: Int = 0): [Post!]!
  followers: Int!
}

type Post {
  id: ID!
  title: String!
  content: String!
  author: User!
  comments: [Comment!]!
  likes: Int!
  createdAt: DateTime!
}

type Query {
  user(id: ID!): User
  users(limit: Int, offset: Int): [User!]!
  post(id: ID!): Post
  posts(status: PostStatus, limit: Int): [Post!]!
}

type Mutation {
  createPost(input: CreatePostInput!): Post!
  updatePost(id: ID!, input: UpdatePostInput!): Post!
  deletePost(id: ID!): Boolean!
}

# ═══════════════════════════════
# Client Queries
# ═══════════════════════════════

# Dashboard — 1 request instead of 4
query Dashboard {
  me: user(id: "123") {
    name
    avatar
    followers
  }
  recentPosts: posts(limit: 5) {
    title
    likes
    createdAt
  }
}

# Mutation
mutation CreatePost {
  createPost(input: {
    title: "GraphQL is Awesome"
    content: "Here's why..."
  }) {
    id
    title
    createdAt
  }
}

gRPC — Binary Protocol (Service-to-Service)

gRPC is a high-performance RPC framework that uses Protocol Buffers (protobuf) as its serialization format instead of JSON, which makes it far faster, strongly typed from the proto definition, and capable of streaming for real-time communication.

It is an excellent fit for service-to-service communication inside microservices, thanks to its performance, type safety and code generation. It is a poor fit for the browser, where it needs a grpc-web proxy, and its learning curve is steeper than REST's.

// ═══════════════════════════════
// user.proto — Protocol Buffer Definition
// ═══════════════════════════════

syntax = "proto3";
package user;

service UserService {
  // Unary — a single request/response
  rpc GetUser (GetUserRequest) returns (User);
  rpc CreateUser (CreateUserRequest) returns (User);

  // Server streaming — the server streams back
  rpc ListUsers (ListUsersRequest) returns (stream User);

  // Bidirectional streaming — both sides stream
  rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message User {
  string id = 1;
  string name = 2;
  string email = 3;
  UserRole role = 4;
  int64 created_at = 5;
}

enum UserRole {
  MEMBER = 0;
  EDITOR = 1;
  ADMIN = 2;
}

message GetUserRequest {
  string id = 1;
}

message CreateUserRequest {
  string name = 1;
  string email = 2;
  string password = 3;
}

REST vs GraphQL vs gRPC — How Do You Choose?

	REST	GraphQL	gRPC
Format	JSON (text)	JSON (text)	Protobuf (binary)
Transport	HTTP/1.1	HTTP/1.1	HTTP/2
Performance	⭐⭐	⭐⭐	⭐⭐⭐
Type Safety	❌ Manual	✅ Schema	✅ Proto
Browser Support	✅ Native	✅ Library	⚠️ grpc-web
Over/Under fetch	❌ Common	✅ Exact	✅ Exact
Caching	✅ HTTP cache	⚠️ Complex	❌ Hard
Learning Curve	⭐ Easy	⭐⭐ Medium	⭐⭐⭐ Hard
Best For	Public APIs, CRUD, simple	Mobile/SPA, complex UI	Microservice internal

💡 Common patterns:
├── Public API → REST (simple, cacheable, everyone knows it)
├── Frontend (SPA/Mobile) → GraphQL (flexible queries)
├── Service-to-service → gRPC (fast, typed, streaming)
└── Mix! REST for public + gRPC for internal is common

---

📨 Event-Driven Architecture & Message Queues

Event-driven architecture designs the system to work asynchronously through events and message queues instead of synchronous API calls. That makes the system more resilient, lets it scale better, and stops one struggling service from taking the whole system down.

The main benefits are loose coupling between services, fault tolerance — because the message queue buffers messages — and scalability, because each service can process messages at its own pace.

Synchronous vs Asynchronous

Take placing an order as the example. In the synchronous version, the user clicks buy and then has to wait while the system creates the order, charges the payment, updates inventory, sends the email, sends the SMS, updates analytics and generates the invoice — all of it — before a response comes back.

In the asynchronous version, once the order is created and the payment charged, the system publishes an "order.created" event to a message queue and responds immediately. The rest — email, SMS, analytics — happens in the background, handled by the consumers subscribed to that event.

Message Queue Architecture

A message queue is a broker that holds messages temporarily: the producer (the service sending the message) puts a message into the queue, and the consumer (the service receiving it) pulls the message out and processes it.

The advantage is that if a consumer dies, the message is still sitting in the queue rather than lost — and you can run several consumers competing for the same work (competing consumers), which scales well. Popular message queues include RabbitMQ, Apache Kafka, Redis Pub/Sub and AWS SQS.

Event-Driven Example with RabbitMQ

// ═══════════════════════════════
// Producer — Order Service
// ═══════════════════════════════
import amqp from 'amqplib';

class OrderService {
  private channel: amqp.Channel;

  async connect() {
    const conn = await amqp.connect('amqp://localhost');
    this.channel = await conn.createChannel();

    // Declare exchange (topic-based routing)
    await this.channel.assertExchange('events', 'topic', { durable: true });
  }

  async createOrder(userId: string, items: CartItem[]) {
    // 1. Business logic
    const order = await this.orderRepo.create({ userId, items });

    // 2. Publish event (async, non-blocking)
    const event = {
      type: 'order.created',
      data: {
        orderId: order.id,
        userId,
        items,
        total: order.total,
        timestamp: new Date().toISOString(),
      },
    };

    this.channel.publish(
      'events',
      'order.created',
      Buffer.from(JSON.stringify(event)),
      { persistent: true }  // Survives broker restart
    );

    return order;  // Return immediately!
  }
}

// ═══════════════════════════════
// Consumer — Email Service
// ═══════════════════════════════
class EmailConsumer {
  async start() {
    const conn = await amqp.connect('amqp://localhost');
    const channel = await conn.createChannel();

    await channel.assertExchange('events', 'topic', { durable: true });

    // Create queue for this consumer
    const q = await channel.assertQueue('email-service', { durable: true });

    // Bind to events we care about
    await channel.bindQueue(q.queue, 'events', 'order.created');
    await channel.bindQueue(q.queue, 'events', 'user.registered');

    // Process messages
    channel.prefetch(10);  // Process 10 at a time
    channel.consume(q.queue, async (msg) => {
      if (!msg) return;

      try {
        const event = JSON.parse(msg.content.toString());

        switch (event.type) {
          case 'order.created':
            await sendOrderConfirmation(event.data);
            break;
          case 'user.registered':
            await sendWelcomeEmail(event.data);
            break;
        }

        channel.ack(msg);  // ✅ Message processed
      } catch (err) {
        channel.nack(msg, false, true);  // ❌ Retry (requeue)
      }
    });
  }
}

Apache Kafka — High-Throughput Event Streaming

Apache Kafka differs from an ordinary message queue because it is an "event log" more than a "message queue" — meaning events are retained for a period (7 days, say) and a consumer can replay them.

Kafka suits use cases that need high throughput (100K+ messages/second), event sourcing, log aggregation, or real-time analytics. RabbitMQ suits task queues, RPC, or notification systems that never need to replay.

RabbitMQ vs Kafka — Quick Comparison

	RabbitMQ	Apache Kafka
Model	Message Queue	Event Log
Messages	Deleted after consumption	Retained (7d+) replay possible
Throughput	~10K msg/sec	~100K+ msg/sec
Ordering	Per-queue	Per-partition
Routing	✅ Flexible (exchange types)	Topic-based
Protocol	AMQP	Custom binary
Complexity	⭐⭐ Medium	⭐⭐⭐ Complex
Use Cases	Task queues, notifications, RPC	Event sourcing, analytics, logs, streaming

💡 Small/medium apps → RabbitMQ (simpler)
High-throughput, event sourcing → Kafka
Cloud-native → AWS SQS/SNS (simplest managed option)

---

🏗️ Communication Patterns in Distributed Systems

Once a system is split into multiple services, a new set of challenges arrives: how services talk to each other, how you manage failures, how you handle transactions that cross service boundaries, and how you observe system behavior.

These communication patterns are the proven solutions to exactly those problems. Each one has its own purpose and its own use cases, and choosing between them means weighing what you actually need against how much complexity you are willing to accept.

API Gateway is a single entry point that handles routing, authentication, rate limiting, and logging. It cuts complexity on the client side and centralizes cross-cutting concerns.

Service Mesh is an infrastructure layer that handles service-to-service communication through a sidecar proxy, giving you mTLS, load balancing, and observability without touching application code.

Saga Pattern solves distributed transactions by breaking them into steps, with a compensating action for each step in case that step fails.

CQRS separates the write model (normalized for consistency) from the read model (denormalized for performance). It suits read-heavy systems.

Circuit Breaker prevents cascading failures by stopping calls to a service that has failed, then retrying gradually as the system recovers.

---

🌍 Real-World Architecture Examples

Looking at real-world architectures makes it far clearer how these patterns actually get used, and what scale each one fits. Here we will look at two: a medium-sized e-commerce platform, and a SaaS startup.

E-commerce Platform (Medium Scale)

SaaS Application (Simpler — Modular Monolith)

E-commerce Architecture shows a layered approach: a CDN for static assets, a load balancer for distribution, multiple web app instances for scalability, an API gateway for API management, and microservices split along domain lines.

SaaS Architecture shows the approach for a startup that picks a modular monolith to stay simple, while keeping the modularity it will need to split into microservices later, plus managed services to cut operational overhead.

---

📋 Architecture Decision Cheat Sheet

There is no universal "correct answer" when choosing an architecture, because everything is a trade-off measured against the context of the project, the team, the timeline, the budget, and the requirements. These guidelines will at least make the decision easier.

---

🔑 Key Takeaways

Having walked through architecture patterns, API styles, design patterns, and communication patterns, let us gather the lessons that matter — the ones that help you choose correctly and keep you from over-engineering.

1. Start Monolith, Split Later → don't begin with microservices unless you have to — a modular monolith is good enough for 90% of startups
2. MVC → Layered → Clean → match the complexity to the project — MVC ships just fine!
3. REST for public, GraphQL for SPA, gRPC for internal → you don't have to pick only one; they work together
4. Event-driven = resilient → use message queues for work that doesn't need an immediate response
5. RabbitMQ vs Kafka → RabbitMQ for task queues, Kafka for event streaming
6. Saga ≠ distributed transaction → every step carries its own compensating action
7. CQRS → separate the write model from the read model when you are read-heavy
8. Circuit Breaker → prevents cascading failures in distributed systems
9. API Gateway → a single entry point for auth, rate limiting, and routing
10. Architecture is trade-offs → there is no "best" architecture — only "right for this situation"