1. Identify bottlenecks (DB? App? Network?)
2. Add caching (Redis) for frequently read data
3. Use CDN for static assets
4. Scale horizontally with load balancer
5. Split read/write to primary + replicas
6. Partition data (sharding) for massive scale
7. Use async queues for heavy processing
8. Move to microservices if monolith becomes bottleneck

upstream backend {
    least_conn;            # strategy
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
    keepalive 32;
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
    }
}

# Cache aside pattern (Node.js)
async function getUser(id) {
  // 1. Check cache
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);  // HIT

  // 2. Cache miss — fetch from DB
  const user = await db.users.findById(id);

  // 3. Store in cache with TTL
  await redis.setex(`user:${id}`, 3600, JSON.stringify(user));

  return user;  // MISS
}

# Cache invalidation — on update
async function updateUser(id, data) {
  await db.users.update(id, data);
  await redis.del(`user:${id}`);  // invalidate cache
}

// Without queue (bad)
app.post('/register', async (req, res) => {
  await db.createUser(req.body);       // fast
  await sendWelcomeEmail(req.body);    // slow! blocks response
  await generateAvatar(req.body);      // slow!
  res.json({ success: true });         // user waits seconds!
});

// With queue (good)
app.post('/register', async (req, res) => {
  const user = await db.createUser(req.body);  // fast
  await queue.publish('user.registered', user); // instant
  res.json({ success: true });  // responds immediately!
  // queue consumers handle: email, avatar, analytics async
});

// Resource naming (nouns, not verbs)
GET    /users          → list users
GET    /users/:id      → get user
POST   /users          → create user
PUT    /users/:id      → replace user
PATCH  /users/:id      → partial update
DELETE /users/:id      → delete user

// HTTP status codes
200 OK             201 Created         204 No Content
400 Bad Request    401 Unauthorized    403 Forbidden
404 Not Found      409 Conflict        422 Unprocessable
429 Too Many Reqs  500 Server Error    503 Unavailable

// Pagination
GET /posts?page=2&limit=20
GET /posts?cursor=abc123&limit=20  (cursor-based, better for large)

// Versioning
GET /api/v1/users    (URL versioning — most common)
GET /api/users  Accept: application/vnd.api.v2+json  (header)

// Rate limiting response headers
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 999
X-RateLimit-Reset: 1640000000

CAP = Consistency + Availability + Partition Tolerance

You can only guarantee 2 of 3:

CP (Consistent + Partition tolerant):
  - Returns error if can't guarantee consistency
  - Example: HBase, MongoDB (in certain configs)
  - Use: Banking, inventory (can't show wrong balance)

AP (Available + Partition tolerant):
  - Returns possibly stale data during network partition
  - Example: CouchDB, Cassandra, DynamoDB
  - Use: Social feeds, product catalogue (slightly stale is ok)

CA (Consistent + Available):
  - No partition tolerance — only works on single node
  - Example: Traditional SQL on single machine
  - Not useful for distributed systems

PACELC extension (for normal operation):
  If Partition: tradeoff C vs A
  Else: tradeoff L (Latency) vs C (Consistency)

# Monolith (everything in one)
App → UserService → ProductService → OrderService → DB

# Microservices (separate deployments)
API Gateway
  ├─ User Service  (owns user-db)
  ├─ Product Service (owns product-db)
  ├─ Order Service (owns order-db)
  ├─ Notification Service
  └─ Payment Service

Communication:
  Sync:  REST / gRPC (request-response)
  Async: Kafka / RabbitMQ (event-driven)