🔍 DNS Resolution

The lookup chain

When you visit example.com, the resolution goes through several layers of cache before hitting the network:

1. Browser cache       — "Did I look this up recently?"
2. OS cache            — "Has any app on this machine looked it up?"
3. Router cache        — "Has anyone on this network looked it up?"
4. ISP's DNS resolver  — "Has any ISP customer looked it up?"
5. Recursive query     — Walk the DNS tree: root → .com → example.com

Record types

# Query DNS directly (bypasses all caches)
$ dig example.com +short
93.184.216.34

# See the full resolution chain
$ dig example.com +trace

# Quick lookup
$ nslookup example.com
Server:  127.0.0.53
Address: 93.184.216.34

# /etc/hosts — local overrides, checked before DNS
127.0.0.1    myapp.local
10.0.1.5     staging.myapp.com

🔌 TCP & Sockets

# Your app does (simplified):
import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(('0.0.0.0', 5000))  # Claim port 5000
sock.listen()                  # Start accepting connections

while True:
    client, addr = sock.accept()  # Wait for a connection
    data = client.recv(1024)       # Read the HTTP request
    client.send(b'HTTP/1.1 200 OK\r\n\r\nHello')
    client.close()

OSError: [Errno 98] Address already in use

Client                    Server
   |                         |
   |-------- SYN ----------->|  "I want to connect"
   |<------ SYN-ACK ---------|  "OK, I acknowledge"
   |-------- ACK ----------->|  "Great, let's go"
   |                         |
   |====== DATA FLOWS =======|
   |                         |
   |-------- FIN ----------->|  "I'm done"
   |<------ FIN-ACK ---------|  "OK, me too"

🛡️ Reverse Proxies

What does it do?

A real Apache config

This is a simplified version of what a production Apache config looks like:

<VirtualHost *:443>
    ServerName myapp.example.com

    # TLS termination
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/myapp/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/myapp/privkey.pem

    # API requests → Flask app on port 9912
    ProxyPass /api http://127.0.0.1:9912/api
    ProxyPassReverse /api http://127.0.0.1:9912/api

    # Static files → filesystem (never hits Python)
    Alias /static /home/app_mysite/frontend/static
    <Directory /home/app_mysite/frontend/static>
        Require all granted
    </Directory>

    # Everything else → Flask
    ProxyPass / http://127.0.0.1:9912/
    ProxyPassReverse / http://127.0.0.1:9912/
</VirtualHost>

Forwarded headers

Your app sits behind the proxy, so it sees 127.0.0.1 as the client IP — not the real user. The proxy adds headers to pass along the original information:

X-Forwarded-For: 203.0.113.50      # Real client IP
X-Forwarded-Proto: https            # Original protocol
X-Forwarded-Host: myapp.example.com # Original hostname

Flask's ProxyFix middleware reads these headers so request.remote_addr and request.url reflect reality:

from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_for=1, x_proto=1, x_host=1)

# 1. Is the app process running?
$ sudo systemctl status myapp
● myapp.service - My Web App
   Active: inactive (dead)     ← Not running!

# 2. Check the app logs for crash reason
$ sudo journalctl -u myapp -n 50

# 3. Is it listening on the right port?
$ ss -tlnp | grep 9912
LISTEN  0  128  127.0.0.1:9912  *:*  users:(("gunicorn",pid=1234))

# 4. Does the proxy config point to the right port?
$ grep ProxyPass /etc/apache2/sites-enabled/*.conf

User's Browser
    ↓ HTTPS
Cloudflare Edge (nearest PoP)
    ↓ HTTPS (or HTTP, depending on SSL mode)
Your Server: Apache
    ↓ HTTP (localhost)
Gunicorn / Flask

⚙️ WSGI & Gunicorn

The WSGI interface

At its core, WSGI is just a function with a specific signature:

def application(environ, start_response):
    """
    environ: dict with HTTP_HOST, REQUEST_METHOD, PATH_INFO, etc.
    start_response: callback to set status and headers
    """
    status = '200 OK'
    headers = [('Content-Type', 'text/html')]
    start_response(status, headers)
    return [b'<h1>Hello, World!</h1>']

Flask wraps this — when you write @app.route decorators, Flask builds the application callable for you. But under the hood, every request goes through this interface.

Why Gunicorn?

Gunicorn is a production WSGI server. It pre-forks multiple worker processes, each capable of handling requests independently:

# Development (single process, auto-reload)
$ flask run --port 5000

# Production (4 worker processes, managed)
$ gunicorn --workers 4 --bind 127.0.0.1:9912 main:app

# Sync: 4 workers = 4 concurrent requests max
$ gunicorn --workers 4 main:app

# Async: 4 workers × 1000 connections each
$ gunicorn --workers 4 --worker-class gevent \
    --worker-connections 1000 main:app

🔄 Flask Request Lifecycle

The lifecycle

Request arrives
    ↓
1. URL routing — match the path to a view function
    ↓
2. @before_request hooks — run before every request
    ↓
3. View function — your code runs
    ↓
4. @after_request hooks — modify the response
    ↓
5. Response sent back

Request context

Inside a request, Flask provides thread-local objects that are available anywhere in your code:

from flask import request, g, session

@app.before_request
def load_user():
    # g is a per-request namespace — dies after the response
    g.user = get_user_from_token(request.headers.get('Authorization'))

@app.route('/profile')
def profile():
    # request — the incoming HTTP request
    page = request.args.get('page', 1)

    # session — encrypted cookie data that persists across requests
    session['last_page'] = '/profile'

    # g.user — set in before_request
    return render_template('profile.html', user=g.user)

Error handlers

Flask lets you register custom error pages:

@app.errorhandler(404)
def not_found(e):
    return render_template('404.html'), 404

@app.errorhandler(500)
def server_error(e):
    # Log the error, notify your team
    app.logger.error(f'Server error: {e}')
    return render_template('500.html'), 500

@app.after_request
def add_security_headers(response):
    response.headers['X-Frame-Options'] = 'SAMEORIGIN'
    return response  # Must return the response!

@app.teardown_request
def close_db(exception):
    db = g.pop('db', None)
    if db is not None:
        db.close()

🏭 Processes & Workers

The fork() model

Gunicorn uses the pre-fork model. A master process starts, then creates (forks) worker processes. Each worker is a complete copy of your application:

Master process (PID 1000)
  ├── Worker 1 (PID 1001) — handling request from User A
  ├── Worker 2 (PID 1002) — handling request from User B
  ├── Worker 3 (PID 1003) — idle, waiting
  └── Worker 4 (PID 1004) — handling request from User C

The master doesn't handle requests — it manages workers. If a worker crashes, the master spawns a replacement. If a worker takes too long, the master kills it.

How many workers?

Processes vs threads

Python has the GIL (Global Interpreter Lock) — only one thread can execute Python code at a time per process. This means threads don't help with CPU-bound work, but they do help with I/O-bound work (waiting on network/database).

# Without pooling: 50ms overhead per request
conn = psycopg2.connect(...)  # Expensive!
cursor = conn.cursor()
cursor.execute('SELECT ...')
conn.close()

# With pooling: connections are reused
from sqlalchemy import create_engine
engine = create_engine('postgresql://...', pool_size=5)
# Connections are borrowed from pool and returned automatically

🔄 Concurrent Jobs & Live Streaming

Reference architecture

This pattern lets many users run jobs in parallel without blocking request handlers:

Reconnect behavior

When the connection drops, the browser reconnects and sends Last-Event-ID so the server can replay missed events.

Backend lifecycle (pseudocode)

Keep request handling short. Push real work onto a worker pool or queue:

# POST /api/jobs
user = require_auth()
payload = validate(request.body)
job_id = create_job(user_id=user.id, status="queued")
emit(job_id, kind="queued", percent=0)
queue.push(job_id)
return 202 { job_id, status: "queued" }

# Worker loop (N workers running in parallel)
while true:
    job_id = queue.pop()
    mark_running(job_id)
    for step in build_execution_plan(job_id):
        run(step)
        emit(job_id, kind="progress", percent=step.percent)
    mark_done(job_id)
    emit(job_id, kind="done", percent=100)

SSE stream endpoint (pseudocode)

Server-Sent Events is ideal for one-way progress streams (server → browser). Every event gets an ID so reconnect can resume from Last-Event-ID.

# GET /api/jobs/:id/stream
user = require_auth()
job = load_job(job_id)
if not job or job.user_id != user.id:
    return 404

cursor = request.headers["Last-Event-ID"] or -1
stream "retry: 1500"

while job_not_finished(job_id) OR unseen_events_exist(job_id, cursor):
    events = load_events_after(job_id, cursor)
    for event in events:
        stream id/event/data(event)
        cursor = event.seq
    sleep(250ms)

Frontend stream handling (pseudocode)

job = POST /api/jobs(payload)
stream = EventSource("/api/jobs/{job.id}/stream")

on progress(event):
    render_progress(event.percent, event.message)

on done(event):
    render_done(job.id)
    stream.close()

on error(event):
    keep_progress_ui_visible()
    # SSE retries automatically

Concurrency controls for many users

1) Client starts job: POST /api/jobs -> 202 + job_id
2) Worker runs job and appends events: {seq, kind, message, pct}
3) Client opens SSE: GET /api/jobs/:id/stream
4) On disconnect, SSE reconnects with Last-Event-ID
5) If SSE fails repeatedly, client polls:
   GET /api/jobs/:id/events?after=last_seq

open_sse(job_id)
on_event(evt): render(evt); cursor = evt.seq
on_sse_error():
    if reconnecting_too_long:
        every 1s:
            events = GET /api/jobs/:id/events?after=cursor
            render(events)
            cursor = max_seq(events)
        keep_retrying_sse_in_background()

⚖️ Service Boundaries: Split or Merge?

Common service-boundary patterns

// One client, multiple services underneath
Platform.init({
  auth: { appId: 'full-stack-courses' },
  feedback: { projectName: 'fullstack' }
});

POST /api/submit-feedback
1) Validate user identity
2) Call dependent services
3) Return unified response

⚡ Caching

The caching layers

Browser cache         ← closest to user, fastest
    ↓
CDN cache             ← edge servers around the world
    ↓
Reverse proxy cache   ← at your server's front door
    ↓
Application cache     ← Redis, in-memory dicts
    ↓
Database cache        ← query cache, buffer pool

Browser cache (Cache-Control)

The server tells the browser how long to cache a response using the Cache-Control header:

# "Cache this for 1 hour"
Cache-Control: max-age=3600

# "Cache, but check with server before reusing"
Cache-Control: no-cache

# "Never cache this"
Cache-Control: no-store

# "Cache for 1 year — this URL is versioned"
Cache-Control: public, max-age=31536000, immutable

Application cache (Redis)

For expensive computations or frequently-accessed data, store results in an in-memory cache:

import redis
cache = redis.Redis()

def get_user_profile(user_id):
    # Check cache first
    cached = cache.get(f'profile:{user_id}')
    if cached:
        return json.loads(cached)

    # Expensive database query
    profile = db.query('SELECT * FROM users WHERE id = ?', user_id)

    # Store in cache for 5 minutes
    cache.setex(f'profile:{user_id}', 300, json.dumps(profile))
    return profile

Cache invalidation

The hard part of caching isn't adding it — it's knowing when to throw away stale data. Common strategies:

# Check the CF-Cache-Status header to see what happened:
$ curl -sI https://yoursite.com/style.css | grep cf-cache-status
cf-cache-status: HIT          ← served from Cloudflare edge

$ curl -sI https://yoursite.com/api/data | grep cf-cache-status
cf-cache-status: DYNAMIC      ← passed through to origin (not cached)

📐 System Design Reference

requests_per_day = qps * 86_400
peak_qps = avg_qps * 2  # or *3 for normal bursty traffic

storage_total = users * data_per_user * retention_days
capacity_with_headroom = required_capacity * 1.3  # 30% safety margin