R2.1 · The dashboard must degrade, not fail

Theme	R2 · Resilience and capacity
Domain	Infrastructure and integration
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings D-01, D-03, D-04, D-06, L-03 · condition 05 · question Q04
Open questions	Depends on 13 and 24
Deliverables	D1.2 · D2.1 · D3.1
Reinforced by	R4.1 — the same failure, one tier up

Concern

The MVP replaces the only post-login route to every business-unit portal, and specifies no way for that route to fail partially.

D-01 — replacing the entry point with no fallback. The segment assessment rates this a blocker:

After cutover, the dashboard is the only post-login route to every BU portal. Its availability therefore bounds the availability of all Canadian digital servicing, not just the new aggregated view.

D-06, D-04 and D-03 — nothing isolates a failure. The BFF is an unmitigated single point of failure that also owns session lifecycle, with "no bulkheading between BU call paths, no worker-pool isolation, no per-BU timeout budget." At the composition layer the assessment asks the question the design never answers — "does one failing MFE degrade its tile or blank the page?" And the ADS's claim that Redis will "shield slow/failing upstreams" does not hold: "On cold start, after deployment, after eviction, or on TTL expiry across a popular key set, the fan-out reaches every BU API simultaneously." Shielding is what a circuit breaker, a timeout budget and a bulkhead do, and the readiness review records zero tickets for any of them.

The load arrives whether the customer wants it or not. L-03 counts eight downstream calls per composition — one BU-mapping lookup plus seven BU Data API calls — and makes the point that matters for capacity: "Load is generated by page composition rather than by customer intent." These APIs were built for per-portal traffic, where visiting the Group Benefits portal generated load on Group Benefits alone.

The client's own strategy already states the principle

The unified customer architecture specifies its experience layer as "stable contract · forward-compatible to identity-key swaps · degrade-never-blank." The principle is Manulife's, written three months before the ADS. The MVP does not implement it. This recommendation holds the programme to its own North Star rather than importing an outside standard — which is also the easier conversation to have.

Recommendation

Make partial availability a designed property with a written contract, not an emergent one.

Every tile degrades independently. The dashboard renders with N of seven business units available, each failed tile carrying its own state and its own route into the BU portal that still works. That requires per-BU deadline budgets, bulkheads between call paths so one slow BU cannot exhaust the shared pool, and an error boundary per micro-frontend. This is condition 05.

The contract is written in words, per failure mode, before it is built. What the customer sees when a tile fails, when the BU Mapping Service fails, when the cache is cold and when the BFF itself fails. Q04 asks for exactly that, and it is a product decision rather than an engineering one — which is why it has to be settled by someone other than the team building the fan-out.

Treat the cache as a latency optimisation and never as a resilience control. A cache-hit ratio target and a stated cold-start behaviour, with the resilience obligation carried by breakers, timeouts and bulkheads that hold when the cache is empty. Named explicitly because the ADS already tried the other way, and D-03 is why it does not work.

Three commitments in this theme sit outside this page, because each has a different owner and a different decision date: the budget this contract is measured against is R2.2, the control that covers a failure of the new surface itself is R2.3, and the downstream ceiling the contract has to survive is R2.4.

What it changes

The criticality tier has to be settled first. A-05 disputes Gold against Critical Digital Properties — roughly an order of magnitude on RTO and RPO — and every recovery number is measured against the answer. This is open question 13, and it belongs to Manulife, not to us.

It adds a roadmap work stream that is currently owned by nobody. Resilience, DR and the fallback route were in the operational half of the programme cancelled in the CAUCE-to-CAUEX replan without an inheritor. WS 3 has to sequence and price it as explicit scope.

It makes the degradation contract a test artifact. A contract stated per failure mode is executable as a negative test; one stated as an intention is not. That is what connects this page to the missing load environment, and why the readiness review's gate plan is where it gets verified.

What we are not recommending

Raising availability by hardening each dependency. The arithmetic does not permit it: even at 99.99% per dependency the design misses its own target by 13×. Degradation is the only lever with enough range, and R2.2 is where that arithmetic is published.

Descoping business units to shorten the fan-out. It reduces the exposure and defeats the purpose; a dashboard that aggregates three of seven relationships is the product-selection page with better styling.

Solving this with the cache. Named separately because the ADS already tried it, and D-03 is the reason it does not work.

Specifying the per-BU timeout values. SOW Schedule "A" §3.0 puts implementation-level solution design out of scope. We recommend that deadline budgets exist, are per-BU, and are derived from the published budget. We do not set them.

Dependencies and open questions

• Open question 13 — the criticality tier. Every RTO and RPO commitment in the degradation design is measured against it.
• Open question 24 — per-BU volumetry. A degradation contract sized against unknown load is a shape without a number; R2.4 argues what to do while it stays open.
• Environment readiness. The readiness review records SIT, UAT and PROD Redis unprovisioned with no DR-region instance anywhere, and names environments as the programme's number-one schedule risk — open question 25. A degradation contract that cannot be tested is a claim.