Architecture Case Study
Target Architecture
Target architecture, component responsibilities and system boundaries.
Architectural intent
The target design introduces an edge delivery layer between consuming applications and the existing backend.
Its responsibility is deliberately narrow:
- receive API requests;
- determine whether a request is eligible for reuse;
- create a stable request identity;
- serve a suitable cached response where available;
- forward requests to the origin when required;
- store eligible origin responses for later reuse;
- expose enough diagnostics and controls to operate the layer safely.
The backend remains responsible for business data, business rules and source-of-truth processing.
High-level view
flowchart LR
A[Digital Applications]
E[Edge API Proxy]
C[(Distributed Cache)]
K[Policy Store]
O[Authoritative Backend]
A -->|API request| E
E --> K
E --> C
C -->|Reusable response| E
E -->|Miss / bypass / pass-through| O
O -->|Authoritative response| E
E -->|Eligible response| C
E --> A
Component responsibilities
| Component | Architectural responsibility |
|---|---|
| Digital applications | Consume existing API contracts without needing awareness of cache implementation. |
| Edge API proxy | Own delivery policy, routing, cache lookup and response-handling decisions. |
| Distributed cache | Hold reusable responses close to consumers for a bounded period. |
| Policy store | Externalise endpoint-specific rules so behaviour can change without embedding every rule in code. |
| Authoritative backend | Continue owning business processing and authoritative data. |
Boundary decisions
Delivery concern stays at the edge
Caching, normalisation and request-routing behaviour are delivery concerns. Keeping them outside the backend avoids pushing edge-specific behaviour into the business-data platform.
Business logic stays at the origin
The edge layer does not decide business truth. If a fresh result is required, the request continues to the authoritative backend.
Policy is separated from execution
Endpoint rules are configuration-driven where practical. This enables selective enablement and avoids treating every endpoint as though it has identical freshness or cacheability characteristics.
Architecture characteristics
The design intentionally favours:
- stateless request handling at the edge;
- clear separation between cache policy and source data ownership;
- graceful fall-through to origin;
- incremental rollout;
- observable request decisions;
- reversible controls.
The result is a relatively small architectural insertion with a clear responsibility boundary rather than a replacement platform.