Context & Drivers

Business context

Several customer-facing applications relied on a shared backend platform for read-heavy API access. The same backend also supported processing and operational workloads.

The recurring issue was not that every request was expensive in isolation. It was that many requests asked for equivalent information repeatedly, causing the backend to spend capacity recomputing responses that could often be reused safely.

Stakeholder concerns

The architecture needed to balance several perspectives.

Digital product teams

Needed existing applications to continue receiving compatible responses without major frontend redesign.

Backend engineering

Needed to reduce avoidable read traffic so the platform retained capacity for processing, development and operational work.

Operations

Needed clear controls to disable, bypass or invalidate caching when behaviour needed to change quickly.

Architecture and engineering leadership

Needed an approach that improved scalability without simply shifting complexity elsewhere or creating a fragile dependency.

Scope

In scope:

• introducing an intermediary edge layer;
• reducing repeat origin processing for suitable read requests;
• defining cache identity and freshness rules;
• preserving existing response contracts;
• defining observability and operational controls;
• supporting gradual adoption.

Out of scope:

• replacing the underlying backend platform;
• redesigning business-domain logic;
• changing source-of-truth ownership;
• caching every endpoint indiscriminately;
• treating the edge layer as a new system of record.

Architecture drivers

The most important drivers were:

• compatibility — existing consumers should not need substantial change;
• efficiency — repeated safe-to-reuse requests should avoid unnecessary origin work;
• controlled freshness — different endpoints may tolerate different reuse windows;
• resilience — failure of the caching layer must not make the backend inaccessible by design;
• operability — teams need to understand and control the request path;
• incremental adoption — caching should be introduced selectively rather than as a big-bang migration;
• low operational overhead — the intermediary should not require a large new platform team.

Key constraint

The backend remained authoritative.

That constraint shaped the entire design: the edge layer could optimise delivery, but it could not become the owner of the business data or silently invent a separate truth model.