Edge Cache & API Proxy

Executive Overview

Multiple customer-facing web applications depended on a shared backend API platform. A significant proportion of read traffic requested information that could be safely reused, so the backend repeatedly processed equivalent requests while also supporting data-processing and development workloads.

The architectural challenge was not simply to add a cache. It was to introduce an intermediary layer that could reduce unnecessary origin processing without changing the application contract, while still allowing teams to control freshness, bypass caching when required, understand where responses came from and fall back safely to the existing backend.

My contribution focused on the solution and integration architecture: clarifying the problem boundary, defining the edge-layer responsibilities, shaping cache and freshness behaviour, establishing operational controls and observability, and guiding validation of the design against the existing consumer applications.

The resulting target design introduced a serverless edge proxy between consuming applications and the backend. Suitable read responses could be reused close to consumers, while cache misses and non-cacheable requests continued to the existing origin. Configuration separated endpoint policy from code so caching could be introduced selectively rather than as an all-or-nothing change.

Why the problem mattered

The backend was serving two different needs:

• customer-facing API traffic; and
• processing and operational workloads behind the same platform.

Repeated read requests therefore consumed capacity that could otherwise support backend processing and engineering activity. Scaling the backend alone would increase capacity, but would not address the underlying inefficiency of repeatedly computing the same safe-to-reuse responses.

The architecture needed to improve efficiency while avoiding a disruptive redesign of the existing applications and backend.

Architectural responsibility

The work required decisions across several concerns:

• where the caching responsibility should sit;
• how consumers could continue using the same response contracts;
• which requests were safe to reuse;
• how equivalent requests should map to the same cache identity;
• how freshness could vary by endpoint;
• how the origin remained authoritative;
• how operators could bypass, purge or disable caching;
• how the processing path could be observed;
• how the solution could be introduced and validated incrementally.

This case study focuses on those architectural concerns rather than source-code implementation.

Architecture at a glance

flowchart LR
    U[Customer-facing applications]
    E[Edge API layer]
    C[(Edge cache)]
    P[Policy configuration]
    O[Backend API platform]

    U -->|API request| E
    E -->|read policy| P
    E -->|lookup reusable response| C
    C -->|cache hit| E
    E -->|cache miss or bypass| O
    O -->|authoritative response| E
    E -->|store when suitable| C
    E -->|compatible response| U

The edge layer owns delivery concerns such as caching policy and request routing. The backend remains responsible for the underlying business data and processing.

Case study navigation

The supporting pages follow the architectural reasoning from problem to outcome:

• Context & Drivers — business problem, stakeholders, scope and constraints.
• Current-State Architecture — baseline responsibilities and why change was required.
• Options Considered — viable approaches, strengths, limitations and selection rationale.
• Target Architecture — component responsibilities and architectural boundaries.
• Request & Information Flow — how requests and reusable information move through the target design.
• Architecture Decisions — important choices and accepted trade-offs.
• Resilience, Security & Operations — cross-cutting quality and operational concerns.
• Transition Approach — how the capability can be introduced without a big-bang migration.
• Validation & Outcomes — how confidence was established and what the architecture enabled.

Outcome

The design created a controlled way to reduce repeated origin processing while preserving the existing backend as the authoritative source.

More importantly, it separated delivery concerns from business-data processing. Caching policy, request normalisation, operational bypass and diagnostics could evolve at the edge without requiring equivalent changes across every consuming application or forcing the backend to own concerns that did not belong to its core responsibility.

The architectural lesson was that performance work is often less about adding capacity and more about placing responsibilities at the correct boundary.