Skip to the content.

Scale From Zero to Millions of Users

Why Scaling is Necessary

When a website grows, its response time can slow down due to increased users. To prevent this, we need to scale our system.

Single Server Setup

Initially, everything (app, database, cache) runs on a single server.

Single Server Setup

Database

First step in scaling: move the database to a separate server.

Separate Database Server

Which Databases to Use?

Vertical Scaling vs Horizontal Scaling

Load Balancer: Distributes incoming traffic among web servers.

Load Balancer

Considerations for Load Balancer

  1. If server1 goes down, traffic is sent to server2.
  2. Add more servers as users increase.

Database Replication

Master/slave relationship where the master handles write operations, and slaves handle read operations.

Database Replication

Advantages

  1. Better performance.
  2. Reliability.
  3. High availability.
  1. Replace offline slave databases.
  2. Promote a slave to master if the master goes offline.

Cache

Stores frequently accessed data in memory to reduce database calls.

Cache

  1. Expiration Policy: Balance between too short and too long.
  2. Consistency: Sync cache data continually.
  3. Mitigating Failures: Use multiple cache servers.
  4. Eviction Policy: Least-recently-used (LRU) is common.

Content Delivery Network (CDN)

Serves static content (CSS, JS, images, videos) from servers close to the user.

CDN

  1. Cost.
  2. Appropriate cache expiry.
  3. CDN fallback.

CDN Workflow

Stateful vs Stateless Architecture

Stateful vs Stateless

Data Centers

Users are routed to the closest data center.

Data Center

  1. Traffic redirection using geoDNS.
  2. Data synchronization.
  3. Test and deploy from different regions.

Message Queue

Supports asynchronous communication between services.

Message Queue

Logging, Metrics, Automation

Logging, Metrics, Automation

Scaling the Database

Vertical Scaling

Add more power (CPU, RAM, DISK) to an existing machine.

Horizontal Scaling (Sharding)

Separate large databases into smaller parts called shards.

Sharding

  1. Reshard data if overloaded.
  2. Manage celebrity users separately.
  3. Hard to join and query across multiple shards.

Final System Illustration

Final System

Millions of Users and Beyond

  1. Keep web tier stateless.
  2. Build redundancy at every tier.
  3. Cache data as much as possible.
  4. Support multiple data centers.
  5. Host static assets in CDN.
  6. Scale your data tier by sharding.
  7. Split tiers into individual services.
  8. Monitor your system and use automation tools.

Refs: