Modern Web Architecture FAQ & Answers

Edge computing runs compute at CDN edge locations worldwide, reducing latency from 100-300ms to 10-50ms for global users. Cloudflare Workers: V8 isolates, <1ms cold starts (P95 sub-10ms), 300+ data centers auto-deploy, ~1/10th memory vs Node.js processes. Vercel Edge Functions: container-based, excellent Next.js integration, requires Enterprise for multi-region. Key difference: edge executes code (not just caching), enabling dynamic personalization, API middleware, real-time data transformation at network edge. Cloudflare excels at raw performance and cost efficiency; Vercel wins on developer experience for frontend frameworks. 2025 use cases: fast APIs, auth middleware, A/B testing, personalization, geo-routing. Traditional CDN only caches static assets; edge computing runs full application logic closest to users.

Micro-frontends break monolithic frontend into smaller, independent applications for modular, scalable development. Module Federation (Webpack 5+) allows JavaScript modules to be shared and consumed across different builds at runtime, enabling seamless integration. Module Federation 2.0 (2025) adds: dynamic TS type hints, Chrome devtools, runtime plugins, preloading, making it production-ready for large-scale web apps. Key advantage: applications dynamically load code from other apps at runtime, share dependencies without rebuilding. Common pattern: App Shell (lightweight shell loads monolith + new micro-frontends). Challenges: CSS conflicts (use scoped CSS/CSS modules), dependency version management, coordination overhead. Aligns micro-frontend boundaries with business domains and team structures, not technical concerns.

Islands architecture renders HTML on server, injects placeholders around dynamic regions, ships HTML by default and adds JavaScript only where needed. Coined by Etsy's Katie Sylor-Miller 2019, expanded by Jason Miller (Preact creator). Also called partial/selective hydration: only necessary JS for specific components loads, not entire JS bundle. Astro: first mainstream framework with selective hydration built-in, ships zero JS by default, components stay static HTML unless explicit client directive, supports React/Preact/Svelte/Vue components. Fresh: Deno-based framework using islands with low/no JS. Benefits: dramatically faster page loads, progressive enhancement philosophy, reduced JS bundle size (often 90%+ reduction), better SEO (fully server-rendered), improved Core Web Vitals. Perfect for content sites, marketing pages, blogs where interactivity is limited.

CQRS (Command Query Responsibility Segregation) separates read operations (queries) from write operations (commands), using different data models optimized for each. Event Sourcing stores system state as chronological series of immutable domain events in append-only event store, preserving every change. Combined power: commands generate events, event store = source of truth, read models built by replaying events, queries served from optimized read databases. Benefits: natural horizontal scaling (async event consumption), full audit trail (every change recorded), time travel (replay events to any point), eventual consistency patterns, enables event-driven architecture. Challenges: increased complexity, eventual consistency (read data may be stale), event schema evolution, storage growth (mitigation: snapshots). Best for: financial systems, audit-critical apps, complex domains, microservices. 2025 tools: Kafka, EventStoreDB, Axon Framework.

Three primary technologies: 1) WebSockets: bi-directional, persistent connection, lowest latency via full-duplex communication over single connection. 2) Server-Sent Events (SSE): unidirectional (server to client) over HTTP, low latency for push updates, cannot natively send messages back (needs additional HTTP requests). 3) WebRTC: peer-to-peer communication, reduces backend load, improves scalability, lower latency than backend WebSocket solutions. Use cases: Figma/Notion/Google Docs (real-time co-authoring), financial services (live price updates), e-commerce (inventory updates). Architecture: stateless session management, distributed messaging (Redis Pub/Sub, Kafka), cloud-native autoscaling. Real-world: Canva implemented WebRTC for collaborative mouse pointers (improved scalability, reduced latency, lower backend load vs WebSocket approach). 2025 scaling: edge-based WebSocket termination, distributed caching, advanced autoscaling.

Technology selection depends on communication pattern, latency requirements, and infrastructure constraints. WebSockets provide bi-directional full-duplex communication over persistent TCP connection, ideal for chat applications, multiplayer gaming, collaborative editing (Google Docs, Figma), live dashboards, trading platforms requiring server-initiated updates. Technical characteristics: establishes connection via HTTP upgrade handshake, maintains persistent connection with keep-alive pings (typical: 30-60s intervals), achieves 1-5ms message latency on good networks, supports binary (ArrayBuffer) and text (UTF-8) frames. Production considerations: requires sticky sessions for load balancing (connection affinity to specific server), horizontal scaling via Redis Pub/Sub or message brokers (RabbitMQ, Kafka) for multi-server deployments, connection limits per server typically 10k-50k concurrent (C10k problem), stateful nature complicates auto-scaling. Server-Sent Events (SSE) provide unidirectional server-to-client push over HTTP, perfect for live feeds (Twitter/X timeline updates), notification streams, stock tickers, progress indicators, server log streaming. Technical characteristics: uses standard HTTP with text/event-stream content type, automatic reconnection with exponential backoff built into browser EventSource API, supports event IDs for resuming from last received event (eliminates message loss on reconnect), simpler than WebSockets (plain HTTP, works through proxies/firewalls). Limitations: server-to-client only (client uses separate HTTP requests for upstream), browser connection limits (6 per domain in most browsers), text-only format (JSON encoding required for structured data), HTTP overhead per message (~200 bytes headers). Production advantages: stateless (easy horizontal scaling), standard HTTP load balancing works without modifications, built-in retry logic reduces client code complexity. WebRTC enables peer-to-peer data channels and media streams, optimal for video conferencing (Zoom, Google Meet), file sharing, collaborative whiteboards, real-time multiplayer gaming. Technical characteristics: establishes direct peer-to-peer connection after signaling (via WebSocket or other), uses UDP (SRTP for media, SCTP for data channels) achieving <50ms latency for P2P, supports unreliable (UDP-like) and reliable (TCP-like) data channel modes, built-in NAT traversal via STUN/TURN servers. Production benefits: offloads data transfer from backend (massive cost savings for high-bandwidth applications), lowest possible latency for P2P communication (no server intermediary), reduces backend infrastructure requirements. Complexity costs: requires STUN servers for NAT hole punching, TURN relay servers for 5-10% of connections behind restrictive firewalls/NAT (fallback relay adds latency and bandwidth costs), signaling server coordination needed for peer discovery and SDP exchange, browser compatibility varies (Safari WebRTC support historically lagged). Real-world case study: Canva switched from WebSocket-based collaborative cursors to WebRTC data channels, achieving 40% latency reduction (WebSocket: 80-120ms, WebRTC: 40-60ms P2P), 70% backend load reduction (cursor positions bypass server), improved scalability from 50 to 500 concurrent collaborators per document. Trade-offs observed: 8% of users required TURN relay fallback (added 10-15ms latency vs direct P2P), increased client-side complexity for connection management. Decision framework: (1) Choose WebSockets when bi-directional communication required, moderate connection counts (1k-50k), server must see all messages (chat moderation, game state validation), existing infrastructure supports sticky sessions. (2) Choose SSE when only server-to-client push needed, want simple HTTP-based solution, need automatic reconnection with resume capability, prioritize development speed over bidirectionality. (3) Choose WebRTC when P2P communication possible (users connect directly), high bandwidth or ultra-low latency critical (video, real-time collaboration), want to minimize server costs for data transfer. Hybrid approaches common in 2025: Slack uses WebSockets for messages + WebRTC for voice/video calls, Discord uses WebSockets for text channels + WebRTC for voice channels, collaborative tools use WebSockets for document updates + WebRTC for cursor positions. Performance benchmarks (2025 measurements): WebSocket round-trip 2-8ms (local network), 30-100ms (cross-continent), SSE server-to-client 5-15ms (includes HTTP overhead), WebRTC P2P 1-5ms (local network), 20-80ms (cross-continent direct), 50-150ms (via TURN relay). Browser support: WebSockets 98%+ (all modern browsers), SSE 95%+ (Safari 14+, Chrome 80+, Firefox 75+), WebRTC 97%+ (Safari 15+ improved, Chrome/Firefox excellent). Infrastructure costs comparison: WebSocket server handles 10k connections at $50-100/month (sticky load balancer + Redis required), SSE server handles 10k connections at $30-60/month (simpler stateless scaling), WebRTC requires TURN server at $20-40/month for relay (only 5-10% of connections use TURN). Emerging 2025 patterns: WebTransport (QUIC-based, combines benefits of WebSocket/WebRTC, Chrome 97+, limited Safari support), HTTP/3 Server Push (replacing SSE in some cases), edge-deployed WebSocket servers (Cloudflare Durable Objects, Fly.io) reducing global latency.

WebSockets provide bi-directional full-duplex communication over persistent TCP connection for real-time, interactive applications. Technical characteristics: establishes connection via HTTP upgrade handshake, maintains persistent connection with keep-alive pings (30-60s intervals), achieves 1-5ms message latency on good networks, supports binary (ArrayBuffer) and text (UTF-8) frames. Ideal use cases: chat applications (Slack, Discord text channels), multiplayer gaming (game state synchronization), collaborative editing (Google Docs, Figma real-time updates), live dashboards (monitoring, analytics), trading platforms (price updates, order execution). Production considerations: requires sticky sessions for load balancing (connection affinity to specific server), horizontal scaling via Redis Pub/Sub or message brokers (RabbitMQ, Kafka), connection limits per server 10k-50k concurrent (C10k problem), stateful nature complicates auto-scaling. Performance: round-trip 2-8ms local network, 30-100ms cross-continent. Browser support: 98%+ all modern browsers. Infrastructure cost: $50-100/month for 10k connections (sticky load balancer + Redis required). Choose WebSockets when bi-directional communication required, server must see all messages (moderation, validation), existing infrastructure supports sticky sessions.

Server-Sent Events (SSE) provide unidirectional server-to-client push over HTTP for real-time updates without full WebSocket complexity. Technical characteristics: uses standard HTTP with text/event-stream content type, automatic reconnection with exponential backoff built into browser EventSource API, supports event IDs for resuming from last received event (eliminates message loss on reconnect), simpler than WebSockets (plain HTTP, works through proxies/firewalls). Ideal use cases: live feeds (Twitter/X timeline updates, news streams), notification streams (alerts, system status), stock tickers (price updates), progress indicators (file uploads, batch jobs), server log streaming (real-time monitoring). Limitations: server-to-client only (client uses separate HTTP requests for upstream), browser connection limits (6 per domain), text-only format (JSON encoding required for structured data), HTTP overhead per message (~200 bytes headers). Production advantages: stateless (easy horizontal scaling), standard HTTP load balancing works without modifications, built-in retry logic reduces client code complexity. Performance: 5-15ms server-to-client (includes HTTP overhead). Browser support: 95%+ (Safari 14+, Chrome 80+, Firefox 75+). Infrastructure cost: $30-60/month for 10k connections (simpler stateless scaling). Choose SSE when only server-to-client push needed, want simple HTTP-based solution, need automatic reconnection with resume capability, prioritize development speed over bidirectionality.

WebRTC enables peer-to-peer data channels and media streams for ultra-low-latency, high-bandwidth applications bypassing server intermediaries. Technical characteristics: establishes direct P2P connection after signaling (via WebSocket or other), uses UDP (SRTP for media, SCTP for data channels) achieving <50ms latency for P2P, supports unreliable (UDP-like) and reliable (TCP-like) data channel modes, built-in NAT traversal via STUN/TURN servers. Ideal use cases: video conferencing (Zoom, Google Meet), file sharing (P2P transfer), collaborative whiteboards (real-time drawing), real-time multiplayer gaming (action sync). Production benefits: offloads data transfer from backend (massive cost savings for high-bandwidth), lowest possible latency for P2P communication (no server intermediary), reduces backend infrastructure requirements. Real-world: Canva switched collaborative cursors to WebRTC achieving 40% latency reduction (80-120ms → 40-60ms P2P), 70% backend load reduction, improved scalability from 50 to 500 concurrent collaborators per document. Complexity costs: requires STUN servers for NAT hole punching, TURN relay servers for 5-10% of connections behind restrictive firewalls (adds latency), signaling server coordination for peer discovery. Performance: P2P 1-5ms local network, 20-80ms cross-continent direct, 50-150ms via TURN relay. Browser support: 97%+ (Safari 15+ improved). Infrastructure cost: TURN server $20-40/month (only 5-10% use relay). Choose WebRTC when P2P communication possible, high bandwidth or ultra-low latency critical, want to minimize server costs for data transfer.

Decision framework by use case: (1) Choose WebSockets for bi-directional communication, moderate connections (1k-50k), server must see all messages (chat moderation, game state validation). (2) Choose SSE for server-to-client push only, simple HTTP-based solution, automatic reconnection with resume capability. (3) Choose WebRTC for P2P communication, high bandwidth or ultra-low latency critical (video, collaboration), minimize server costs. Performance benchmarks (2025): WebSocket round-trip 2-8ms local / 30-100ms cross-continent, SSE server-to-client 5-15ms, WebRTC P2P 1-5ms local / 20-80ms cross-continent direct / 50-150ms via TURN relay. Infrastructure costs: WebSocket $50-100/month for 10k connections (sticky load balancer + Redis), SSE $30-60/month (stateless scaling), WebRTC $20-40/month TURN server (5-10% connections use relay). Browser support: WebSockets 98%+, SSE 95%+, WebRTC 97%+. Hybrid approaches common: Slack uses WebSockets for messages + WebRTC for voice/video, Discord uses WebSockets for text + WebRTC for voice, collaborative tools use WebSockets for documents + WebRTC for cursors. Emerging 2025: WebTransport (QUIC-based, combines benefits, Chrome 97+, limited Safari), HTTP/3 Server Push (replacing SSE), edge-deployed WebSocket servers (Cloudflare Durable Objects, Fly.io) reducing global latency.

Use WebSockets when bi-directional full-duplex communication required over persistent TCP connection. Ideal for: chat applications, multiplayer gaming, collaborative editing (Google Docs, Figma), live dashboards, trading platforms needing server-initiated updates. Technical: establishes via HTTP upgrade handshake, maintains connection with keep-alive pings (30-60s intervals), achieves 1-5ms latency on good networks, supports binary (ArrayBuffer) and text (UTF-8) frames. Production: requires sticky sessions for load balancing, horizontal scaling via Redis Pub/Sub or message brokers (Kafka, RabbitMQ), connection limits 10k-50k concurrent per server. Performance: round-trip 2-8ms local, 30-100ms cross-continent. Browser support: 98%+ modern browsers.

Use SSE when only server-to-client push needed over HTTP, ideal for unidirectional updates. Perfect for: live feeds (Twitter/X timeline), notification streams, stock tickers, progress indicators, server log streaming. Technical: uses text/event-stream content type, automatic reconnection with exponential backoff built into EventSource API, supports event IDs for resuming from last received (eliminates message loss on reconnect). Limitations: server→client only (client uses separate HTTP for upstream), 6 connections per domain in most browsers, text-only format (JSON encoding required). Production advantages: stateless (easy horizontal scaling), standard HTTP load balancing works, built-in retry logic. Performance: 5-15ms server-to-client latency. Browser support: 95%+ (Safari 14+, Chrome 80+, Firefox 75+).

Use WebRTC when peer-to-peer data channels or media streams needed, offloading data transfer from backend. Optimal for: video conferencing (Zoom, Google Meet), file sharing, collaborative whiteboards, real-time multiplayer gaming. Technical: establishes direct P2P connection after signaling (via WebSocket/other), uses UDP (SRTP for media, SCTP for data), achieves <50ms latency for P2P, supports unreliable (UDP-like) and reliable (TCP-like) modes, built-in NAT traversal via STUN/TURN. Production benefits: offloads data from backend (massive cost savings), lowest latency (no server intermediary), reduces infrastructure needs. Complexity: requires STUN for NAT hole punching, TURN relay servers for 5-10% behind restrictive firewalls. Real-world: Canva achieved 40% latency reduction (WebSocket 80-120ms → WebRTC 40-60ms P2P), 70% backend load reduction. Performance: 1-5ms local, 20-80ms cross-continent P2P.