Current-State Architecture

Baseline

Before the change, customer-facing applications called a shared backend API platform directly.

flowchart LR
    A[Digital Applications]
    O[Shared Backend API Platform]
    D[(Business Data / Processing)]

    A -->|Repeated API reads| O
    O --> D
    D --> O
    O -->|Response| A

The model was straightforward and functionally valid, but it created an architectural concentration of responsibility.

The same backend platform was responsible for:

• serving repeated customer-facing reads;
• executing business-data processing;
• supporting operational workloads;
• providing capacity for ongoing engineering activity.

Architectural concern

Many consumer requests were for information that could be reused safely for a bounded period.

Because there was no shared delivery/cache boundary, equivalent requests still reached the backend and were processed repeatedly.

The problem was therefore not simply "the backend is slow" or "more capacity is required."

The structural issue was:

Every read request was treated as though it required fresh origin processing, even when the requested information was reusable.

Constraint created by the baseline

The existing applications and backend already represented working production contracts.

A replacement architecture would introduce unnecessary change and risk.

The preferred direction therefore needed to:

• preserve consumer-facing API behaviour;
• keep the backend authoritative;
• reduce repeated origin work;
• introduce the optimisation without requiring a full platform replacement.

Why the baseline view matters

This current-state view establishes the reason for the target architecture.

The target design is not an isolated technology choice. It is a response to a specific responsibility and traffic pattern in the baseline architecture.