Scalable web architecture

DNS resolves the name (cached at several levels), the browser opens a TCP and TLS connection, and the request may be answered by a CDN edge. Otherwise it reaches the load balancer, which picks a healthy app server. The server checks the cache, queries the database if needed, renders a response, and the browser parses HTML and fetches CSS, JS and images, many of them from the CDN.

Vertical (a bigger machine) is simplest and suits databases early on, but it has a ceiling and a single point of failure. Horizontal (more machines) needs stateless services and a load balancer, but scales further and survives a node failing. Most systems scale the app tier horizontally and the database vertically first, then with replicas and sharding.

Separate the database from the app server, put a load balancer in front of several stateless app servers, add caching (CDN for static assets, Redis for hot data), add read replicas, move slow work to queues and workers, then shard or split services as specific bottlenecks appear, measuring at each step.

It keeps no user session or files on local disk or memory between requests; sessions live in Redis or tokens, uploads in object storage. Any server can handle any request, so you can add, remove or replace servers freely and auto-scale.

Measure end-to-end with tracing and metrics: latency per tier, CPU and memory, database query times, cache hit rates, queue depths and external call latency. Find where time is spent at p95 and p99, then fix that tier rather than scaling everything.

Route a user's reads to the primary for a short time after they write, or pin reads that must be fresh (their profile, their order) to the primary. Some systems track the replication position and only read from a replica that has caught up to it.

Health checks let the load balancer stop sending traffic to unhealthy instances; graceful shutdown lets instances finish in-flight requests before stopping. Together they make deployments and scale-in events invisible to users.

Use a CDN and DNS-based or anycast routing to send users to the nearest region, deploy app tiers per region, and choose a data strategy: a primary region with replicas for reads, or multi-region databases for writes, accepting extra complexity.

Use signed and encrypted cookies or JWTs for small stateless sessions, or a shared store like Redis keyed by session ID for server-side sessions. Avoid sticky sessions as the only mechanism because they break when instances disappear.

Put jobs such as emails, image processing and reports on a queue, return quickly to the user, and let a separately scaled worker pool process them with retries, reporting progress through polling, webhooks or WebSockets.

Use connection pooling (PgBouncer or RDS Proxy), add indexes, cache hot reads, route reads to replicas, batch writes, set query timeouts and limit expensive endpoints. Sharding comes later, when a single primary cannot handle writes.

It terminates TLS close to users, caches dynamic responses with appropriate headers, absorbs DDoS attacks, compresses and optimises images, and can run edge logic such as redirects or authentication checks.

Rolling deployments replace instances gradually behind health checks; blue-green switches traffic between two environments; canaries send a small percentage first. Database migrations must be backward compatible (expand, migrate, contract).

Run active-active or warm-standby in a second region, replicate data asynchronously with a known recovery point, route users with health-checked DNS or a global load balancer, and rehearse failover regularly. Decide which features may degrade while running from one region.

Fan out calls in parallel rather than in sequence, set timeouts and budgets per hop, cache or precompute shared data, use backend-for-frontend aggregation, and trace requests to find the slowest dependency. Tail latency grows with every extra hop.

Add new columns or tables first (expand), deploy code that writes to both and reads the new one, backfill data, then remove the old structure (contract). Each step works with both old and new code, enabling zero-downtime changes.

Policies watch metrics such as CPU, request count per target, or queue depth, and add or remove instances to keep them near a target. Scale on the metric closest to user experience, add cooldowns and keep a minimum for sudden spikes.

It sits in front of app servers to terminate TLS, route requests, compress responses, serve static files, buffer slow clients and add headers, often as Nginx, Envoy or a managed load balancer.

Run in several availability zones, add timeouts, retries with backoff and circuit breakers, degrade gracefully (serve cached or partial results), and test failures with game days or chaos experiments.

Opening connections is expensive and databases limit their number. A pool reuses a fixed set of connections across requests; external poolers also protect the database when hundreds of app instances or serverless functions connect.

Upload directly to object storage (S3) with pre-signed URLs, save metadata in the database, process files asynchronously, and serve them through a CDN, so app servers never handle large file bytes.

Service level objectives set targets like 99.9% availability and p95 latency under 300 ms. Error budgets show how much unreliability is acceptable, guiding when to prioritise reliability work and capacity over new features.

When teams block each other, parts need very different scaling or technology, or deployments are too risky. Split along clear domain boundaries one piece at a time (strangler pattern), not all at once.

When a downstream component cannot keep up, it signals upstream to slow down, by bounded queues, 429 or 503 responses, or slower acknowledgements, instead of accepting unlimited work and falling over. Without backpressure, overload spreads and causes cascading failure.

Send reads that can tolerate slight staleness to replicas, keep reads after a user's own write on the primary or a caught-up replica, monitor replication lag, and remove lagging replicas from the pool automatically.

Pre-scale before the send, serve the landing page from the CDN, queue sign-ups and other writes, shed non-essential features with flags, and stagger the email send so traffic arrives over minutes rather than seconds.

A bulkhead isolates resources, such as separate thread pools, connection pools or instances, per dependency or customer class, so one failing dependency or noisy tenant cannot exhaust everything. Use it around slow or unreliable downstream calls.

Latency is delay per request (distance, round trips, slow processing); bandwidth is how much data can flow per second. CDNs and fewer round trips fix latency; compression and smaller payloads fix bandwidth limits.

Model realistic traffic (mix of endpoints, think time, peak rates) with tools like k6 or Locust, test against a production-like environment, ramp up gradually, watch every tier's metrics and fix the first bottleneck found.

Many clients or processes wake up and hit a resource at the same moment, for example after a cache expiry or a service restart. Jitter, request coalescing and gradual ramp-up prevent it.

They separate deploying code from releasing features, allowing gradual rollouts, quick rollback without redeploying, and turning off expensive features during incidents.

Right-size instances from real utilisation, use auto-scaling with sensible minimums, move steady load to reserved or savings plans and batch work to spot capacity, cache aggressively, and track cost per request or per user as a metric alongside latency.

1. ABeing statelessCorrect answer
2. BUsing sticky sessions
3. CRunning on bare metal
4. DStoring sessions in local memory

Why: If no request depends on state held by one machine, servers can be added or removed freely.

1. AIn-memory sessions
2. BBeing statelessCorrect answer
3. CSticky sessions only
4. DLocal file uploads

Why: Any server can handle any request.

1. ANumber of users
2. BWhere time is spent per tierCorrect answer
3. CThe number of servers
4. DLines of code

Why: Fix the real bottleneck.

1. AIn the browser
2. BIn the database
3. CIn queue workers outside the requestCorrect answer
4. DInside the HTTP request

Why: Users get fast responses.

1. AWrite throughput
2. BRead throughputCorrect answer
3. CStorage encryption
4. DDNS resolution

Why: Replicas copy the primary's data so reads can be spread out; all writes still go to the primary.

1. ABetter caching
2. BIn-flight requests finish before stoppingCorrect answer
3. CFaster startup
4. DMore memory

Why: Deploys stay invisible to users.

1. ACanaryCorrect answer
2. BBig bang
3. CRecreate
4. DManual copy

Why: Watch metrics before expanding.

1. AA connection poolerCorrect answer
2. BMore app servers
3. CLarger payloads
4. DDisabling indexes

Why: Reuses a fixed set of connections.

1. ASharding
2. BZero-downtime schema changesCorrect answer
3. CFaster queries
4. DSmaller backups

Why: Each step supports old and new code.

1. ADisk size
2. BNumber of tables
3. CLog volume
4. DRequests per target or latencyCorrect answer

Why: Close to user experience.

1. AThrough app server memory
2. BInto the database
3. CInto Redis
4. DDirectly to object storageCorrect answer

Why: Pre-signed URLs keep bytes off app servers.

1. AWithout timeouts
2. BOnly from the browser
3. CIn parallel with a time budgetCorrect answer
4. DStrictly one after another

Why: Parallel calls bound total latency by the slowest one.

1. ADelete its queue
2. BRestart the load balancer
3. CSignal upstream to send less workCorrect answer
4. DAccept unlimited work

Why: Bounded work prevents overload from cascading.

1. AThe database
2. BThe CDNCorrect answer
3. CThe load balancer
4. DThe message queue

Why: A CDN caches static files at edge locations near users.

1. AStranglerCorrect answer
2. BSingleton
3. CObserver
4. DDecorator

Why: Replace pieces one at a time.

1. ATest coverage
2. BAcceptable unreliability under the SLOCorrect answer
3. CMoney for servers
4. DNumber of bugs

Why: Guides reliability work.

1. AReplace queues
2. BStore sessions only
3. CAbsorb DDoS and terminate TLS near usersCorrect answer
4. DRun your database

Why: More than static caching.

1. ABabel
2. Bk6 or LocustCorrect answer
3. CPrettier
4. DGit

Why: Model realistic traffic.

1. ABigger caches
2. BShorter TTLs
3. CMore logging
4. DJitter and request coalescingCorrect answer

Why: Spread or merge requests.

1. ASlow queries
2. BDNS typos
3. CA single data-centre failureCorrect answer
4. DBad code

Why: Redundancy across zones.

1. AThey need HTTPS
2. BThey are illegal
3. CSessions break when an instance disappearsCorrect answer
4. DThey are too fast

Why: Store sessions centrally.

1. ABuild code
2. BTerminate TLS and route requestsCorrect answer
3. CRun SQL
4. DStore files

Why: Nginx, Envoy or a load balancer.

1. AA backup snapshot
2. BThe primary or a caught-up replicaCorrect answer
3. CAny replica regardless of lag
4. DThe CDN

Why: Lagging replicas would show the user stale data.

1. AMerging all thread pools
2. BIsolating resource pools per dependencyCorrect answer
3. CEncrypting traffic
4. DCompressing responses

Why: One failing dependency cannot drain every resource.

1. ATurn off auto-scaling
2. BShrink the database
3. CPre-scale and stagger the sendCorrect answer
4. DDisable the CDN

Why: Warm capacity and spread arrivals absorb the spike.

1. AThe CDN cache size
2. BHow much data loss is acceptableCorrect answer
3. CHow fast pages load
4. DHow many servers run

Why: RPO is the window of writes you can afford to lose.

1. ATests from code
2. BDeploying from releasingCorrect answer
3. CFrontend from backend
4. DReads from writes

Why: Enable gradual rollout.

1. AMore round trips
2. BLonger timeouts
3. CBigger servers only
4. DCompression and smaller payloadsCorrect answer

Why: Less data to transfer.

1. AWhen reads are slow only
2. BNever
3. CWhen one primary cannot handle writesCorrect answer
4. DOn day one

Why: Try replicas and caching first.

1. AUsing two colours in the UI
2. BTesting in production only
3. CSwitching traffic between two environmentsCorrect answer
4. DDeploying twice a day

Why: Instant rollback by switching back.

1. ALinting
2. BChaos experiments or game daysCorrect answer
3. CCode formatting
4. DSnapshot tests

Why: Inject failures safely.

1. ALogin sessions
2. BPayment authorisation
3. CInterruptible batch jobsCorrect answer
4. DThe primary database

Why: Spot instances can be reclaimed at short notice.