HTTP/2, HTTP/3, TLS, and CDN Architecture

Why this chapter matters

HTTP/2, HTTP/3, TLS, and CDN Architecture matters because frontend architecture is experienced at runtime. A decision that looks small in code can change load time, security posture, accessibility, ownership, incident response, or the cost of the next product bet. The architect's job is to make those effects visible early enough that teams can choose deliberately.

The business outcome is straightforward: Users experience predictable loading and data freshness even across variable networks, regions, devices, and backends. The engineering risk is equally concrete: The UI creates waterfalls, cache incoherency, duplicated payloads, and brittle coupling to backend shape.

The converted source books reinforce the same pattern from different angles. The performance books emphasize critical-path cost, main-thread pressure, request shape, measurement, and field reality. The security books emphasize trust boundaries, unsafe input, session assumptions, dependency risk, and defense in depth. Inclusive Components shows that durable UI quality comes from semantics, focus behavior, state modeling, and repeated component contracts rather than one-off page checks. The Degree-Plan material adds the missing operating layer: ADRs, design documents, scorecards, case studies, and review templates that keep decisions teachable.

Core mental model

Transport, TLS, CDN, and browser loading behavior must be treated as one delivery path, not separate operational concerns.

Think about this chapter as a contract with four layers:

• User contract: what the user can expect even on imperfect devices, networks, input modes, and failure paths.
• Runtime contract: what the browser, network, cache, security policy, and rendering pipeline are allowed to do.
• Team contract: who owns the surface, who can change it, how exceptions are approved, and when debt expires.
• Verification contract: which signals prove the architecture is holding after real releases reach real users.

The mistake is to treat the topic as a local implementation detail. In mature frontend systems, local choices compose into a platform. A component prop can become a design-system API. A fetch call can become a cache-invalidation problem. A third-party script can become a performance, privacy, and incident-response dependency. A loading state can become the difference between user confidence and abandonment.

Source-derived architecture notes

• Treat latency as a chain: DNS, connection setup, TLS negotiation, server processing, edge cache behavior, response transfer, and browser scheduling all contribute to the user's wait.
• HTTP/2 and HTTP/3 reduce some connection-level costs, but they do not erase poor resource priority, oversized JavaScript, cache misses, or slow origins.
• CDN architecture should define cache keys, surrogate invalidation, stale behavior, compression, image/font delivery, redirect handling, and origin shielding before launch.
• TLS automation, certificate rotation, HSTS policy, and secure headers belong in the delivery architecture because a failed edge policy is a user-facing outage.

Architecture decision framework

Decision	Conservative option	Flexible option	Tradeoff signal
Data ownership	BFF-owned contracts	Direct service calls	Choose BFF when orchestration, auth, or payload shaping repeats.
Freshness	Explicit TTL/invalidation	Always refetch	Choose freshness rules by user harm from stale data.
Delivery	CDN/edge caching	Origin-only delivery	Use edge caching for stable, high-read assets and responses.

Use the conservative option when the surface is high traffic, compliance-sensitive, shared across teams, difficult to roll back, or central to revenue and trust. Use the flexible option when the surface is experimental, isolated, low-risk, and has a clear deletion or migration path. The important part is not choosing the strictest rule everywhere; it is matching strictness to blast radius.

Implementation patterns

Baseline pattern for small teams

Measure DNS, connection setup, TLS, TTFB, cache headers, compression, and critical resource priority for the top routes.

For a small team, the right architecture is usually a short written standard, a narrow set of defaults, and one repeatable review point. Avoid building a large platform before the repeated pain is proven. Do create enough structure that future engineers can understand why the current shape exists.

A practical baseline includes:

• a one-page decision record for the surface
• the expected user journey and failure states
• the runtime constraints that must not be violated
• the owner of exceptions and follow-up work
• one automated check and one production signal

Scale pattern for multi-team organizations

Standardize edge caching, HTTP/2 or HTTP/3 support, origin shielding, stale-while-revalidate, and certificate automation.

At scale, architecture is mostly a coordination system. The rule should live where teams already work: package boundaries, lint rules, CI gates, dashboards, Storybook or documentation examples, design review checklists, and incident templates. If a rule is important but only exists in a meeting, it will decay.

The strongest scale pattern is to separate policy from product code. Shared packages provide safe defaults. Product teams compose those defaults. Exceptions are explicit, time-bounded, and visible on scorecards. Review focuses on deviations and risk rather than re-litigating the same baseline.

Migration-safe pattern for legacy systems

Add measurement at the edge and client, collapse redundant fetches, then migrate high-traffic flows behind stable contracts.

Legacy migration should start with observation, not taste. First, inventory the existing behavior and the surfaces users depend on. Then choose a migration slice that has user value, measurable risk reduction, and a rollback path. Avoid migrations that only rearrange folders while preserving the same coupling and runtime cost.

For each slice, write down:

• what behavior must remain identical
• what architectural constraint is being introduced
• what old path will be deleted
• how success will be measured
• what signal tells the team to pause or roll back

Anti-patterns and failure modes

• Symptom: Duplicate requests and waterfalls appear in traces. Root cause: components fetch independently without route data design. Prevention control: model route data dependencies before implementation.
• Symptom: Users see stale or contradictory data. Root cause: cache semantics are implicit. Prevention control: document TTL, invalidation, and mutation effects.
• Symptom: Regional latency surprises the team. Root cause: only origin metrics were monitored. Prevention control: measure edge, client, and API latency by geography.

The deeper failure mode is unmanaged optionality. Teams keep every escape hatch open because it feels faster today, then discover that no one can reason about the system tomorrow. Architecture should reduce optionality where repeated work needs consistency and preserve optionality where product discovery is still active.

Verification checklist

• The user outcome and protected business risk are written in plain language.
• Runtime constraints are documented before implementation starts.
• Ownership is explicit for the surface, exceptions, and retirement work.
• Quality gates cover at least one pre-release signal and one production signal.
• Rollback or degradation behavior is defined for high-risk changes.
• Accessibility, security, reliability, and performance impacts are considered together, not in separate late reviews.

Metrics and scorecards

Track leading indicators because they move before users complain:

• request waterfall depth
• cache hit ratio by layer
• p95 API and edge latency
• stale or inconsistent read reports

Track lagging indicators because they prove business impact:

• navigation failure rate
• incidents caused by contract mismatch

Do not overbuild the dashboard. A useful scorecard makes ownership and trend direction obvious. It should answer three questions quickly: are we improving, where are we regressing, and who owns the next action?

At-scale adaptation

As traffic, teams, and compliance burden grow, this topic stops being a best-practice checklist and becomes an operating model. The architecture must handle:

• multiple teams changing shared surfaces concurrently
• different product risk levels under one frontend platform
• regional, device, network, and accessibility variation
• third-party dependencies with business owners outside engineering
• release trains, feature flags, experiments, and partial rollouts
• auditability when a decision is challenged months later

The response is not heavier ceremony by default. The response is clearer contracts, stronger defaults, better instrumentation, and smaller review surfaces. Architects should spend their time making the desired path easy and the risky path visible.

Exercises

1. Pick one production surface related to this chapter and write a short ADR: context, decision, alternatives, tradeoffs, owner, and review date.
2. Build a scorecard with the four leading indicators above. Mark each as available, missing, or unreliable.
3. Identify one legacy escape hatch. Propose a migration slice that removes it without blocking current roadmap work.
4. Run a scenario drill: a release regresses the primary metric for this chapter by 20%. Define detection, rollback, communication, and follow-up changes.

Source Lens

This chapter is synthesized from the converted frontend library and the Degree-Plan operating templates, especially:

• High Performance Browser Networking
• High Performance Browser Networking Special Edition NGINX
• Mastering NGINX for Site Reliability
• Web Performance Fundamentals