Options Considered

Decision context

The architecture needed to reduce repeated backend processing without creating a disruptive replacement programme.

Several approaches could address parts of the problem.

Option 1 — Increase backend capacity

Approach

Scale the existing backend so it can absorb more traffic alongside processing workloads.

Strengths

• minimal change to consumers;
• low architectural disruption;
• straightforward operational model.

Limitations

• treats the symptom rather than the repeated-work pattern;
• ongoing cost grows with traffic;
• equivalent requests still consume origin processing;
• backend remains responsible for a delivery concern.

Assessment

Useful as a capacity measure, but weak as the primary architectural response.

---

Option 2 — Add caching independently to each consuming application

Approach

Let individual web applications cache or reuse responses themselves.

Strengths

• potentially simple for isolated use cases;
• no new shared runtime layer;
• teams can optimise locally.

Limitations

• duplicates policy across consumers;
• inconsistent freshness and invalidation behaviour;
• every consumer must understand backend-specific caching concerns;
• difficult to govern centrally;
• future consumers repeat the same work.

Assessment

Moves complexity outward rather than solving the concern once at the shared boundary.

---

Option 3 — Introduce a shared edge delivery layer

Approach

Place an intermediary between consumers and the authoritative backend to own delivery optimisation, request normalisation and bounded response reuse.

Strengths

• solves repeated processing once for multiple consumers;
• preserves existing backend ownership;
• allows consistent freshness and invalidation policy;
• can be introduced incrementally;
• creates a natural place for delivery observability and controls;
• keeps consumer applications unaware of cache implementation.

Limitations

• introduces another runtime dependency;
• requires careful cache identity and freshness design;
• needs operational controls and observability;
• incorrect caching policy could create stale or inconsistent responses.

Assessment

Best fit against the main drivers because it removes repeated work at a shared boundary while preserving current contracts and source-of-truth ownership.

Preferred direction

The shared edge delivery layer was selected as the target approach.

The choice was based on architectural fit rather than product preference:

Need to preserve contracts
        +
Need to reduce repeated origin work
        +
Need for central policy and control
        +
Need for incremental adoption
        ↓
Shared delivery boundary
        ↓
Edge proxy + bounded caching

Technology selection followed this architectural choice rather than defining it.