System Design Roadmap 02 - Availability Jobs DNS CDN Load Balancing

Availability pattern goal

Reduce user-visible downtime by eliminating single points of failure, detecting failures quickly, and routing work to healthy replicas or regions.

Fail-over

Automatically or manually switch traffic from a failed instance/region to a standby. Active-active is faster but more complex; active-passive is simpler but may waste capacity.

Replication for availability

Keep copies of data or services so failure of one node does not stop the system. Replication improves reads and resilience but introduces lag and consistency choices.

Availability in numbers

Nines translate to downtime budgets: 99.9% is about 43.8 minutes/month; 99.99% is about 4.4 minutes/month. Higher nines require stronger automation and redundancy.

Background jobs

Work done outside the user request path, such as email, media processing, billing retries, indexing, and notifications. Jobs reduce latency and smooth bursty work.

Event-driven jobs

A change or event triggers work, such as “photo uploaded” starting thumbnail generation. Good for decoupling producers from consumers.

Schedule-driven jobs

A timer triggers work, such as nightly reports, periodic cleanup, or subscription renewal. Needs idempotency and careful handling of missed/duplicate runs.

Returning background job results

Common patterns are polling job status, webhook callbacks, notifications, or updating a resource when complete. Store job state so retries are safe.

DNS role in system design

DNS maps names to IPs and can support latency routing, regional failover, and load distribution. TTL controls how quickly changes propagate.

DNS TTL tradeoff

Short TTLs enable faster failover but increase resolver traffic. Long TTLs reduce DNS load but slow migration and failure recovery.

CDN purpose

A content delivery network serves content from edge locations near users to reduce latency, origin load, and bandwidth cost.

Push CDN vs pull CDN

Push CDN uploads content to the CDN in advance. Pull CDN fetches from origin on first request and caches afterward. Push suits predictable assets; pull suits broad dynamic catalogs.

Load balancer

Distributes traffic across healthy backends. It improves availability and scaling and can terminate TLS, run health checks, and enforce routing rules.

Load balancer vs reverse proxy

A load balancer primarily distributes traffic across multiple backends. A reverse proxy fronts services and may also cache, route, authenticate, compress, or hide backend details.

Layer 4 vs Layer 7 load balancing

Layer 4 routes by connection/IP/port and is fast. Layer 7 understands HTTP/gRPC details and can route by host, path, headers, cookies, or request content.

Load balancing algorithms

Round-robin is simple; least connections favors less busy servers; weighted routing handles uneven capacity; consistent hashing helps preserve cache/session locality.

Horizontal scaling

Add more machines or instances rather than making one bigger. Requires stateless services or externalized state, load balancing, and shared data stores.