Cloud Console Home Page (Backend-for-Frontend)

0) Problem Restatement

Design the home page of a cloud provider's console, the first page a user sees after login (asked at Microsoft). It shows widgets: recently used resources, a resource count by type, service health in the user's regions, a billing summary, alerts, and recommendations. The data comes from many backend services. The interviewer cared about authentication, fast loading, and behaving well when some services are slow or down.

1) Requirements

• Secure login (SSO, MFA), and only show data the user may see.
• The page is useful in under ~1–2 seconds, even if some widgets load later.
• Handle slow or failing dependencies gracefully (show the rest, and a friendly error per widget).
• Personalization: pinned resources, recent items, chosen subscription or project.
• Must work during partial cloud outages (people open the console exactly then).

2) Architecture

flowchart LR
    B["Browser - SPA shell from CDN"] --> GW["API Gateway - auth, token validation"]
    GW --> BFF["Home BFF - aggregates widgets"]
    BFF -->|"parallel, with timeouts"| RS["Resource inventory"]
    BFF --> HL["Service health"]
    BFF --> BILL["Billing summary"]
    BFF --> AL["Alerts"]
    BFF --> REC["Recommendations"]
    BFF --> PREF[("User prefs - recent, pinned")]
    BFF --> CACHE[("Per-user widget cache")]
    IDP["Identity provider - SSO/MFA"] --> B

• Static app shell (HTML, JS, CSS) from a CDN renders instantly with skeleton placeholders.
• Auth: login via the identity provider (OAuth/OIDC). The browser holds a short-lived access token (or a secure HTTP-only session cookie). The gateway validates it on each call.
• BFF (backend-for-frontend): one endpoint GET /home (or one per widget) tailored to this page. It fans out to backend services in parallel and returns a combined response.

3) The Aggregation Pattern

• Parallel calls with per-dependency timeouts (e.g., 300 ms for health, 800 ms for billing).
• Partial responses: each widget returns { status: ok | error | timeout, data }. The page shows what's ready, and a small "couldn't load billing, retry" for failures. One slow service never blocks the page.
• Progressive loading: either stream widget results as they finish (HTTP streaming or server-sent events), or let the client call per-widget endpoints in parallel. Critical widgets come first.
• Authorization per widget: the BFF passes the user's identity to each service, which applies its own permission checks (e.g., billing only for billing readers). The BFF never widens access.
• Circuit breakers per dependency: if recommendations are failing, skip them quickly for a while.

4) Caching

• Per-user widget cache (a short TTL of 30–120 s): resource counts and billing summaries don't change second to second. Serve from cache and refresh in the background (stale-while-revalidate).
• Shared cache for non-personal data (public service health per region).
• Client cache: keep the last home page data in local storage, so repeat visits paint instantly, then update.
• Recent items and pins: stored per user in a fast KV store, and updated asynchronously when the user opens resources elsewhere in the console.

5) Reliability During Outages

• The console's own dependencies are spread across regions. The home page must not depend on the region that's down.
• Status/health widget reads from a separate, highly available status system.
• Degrade gracefully: if inventory is down, show pinned and recent items from cache, with a banner.

6) Frontend Performance

• Code-split per widget, lazy-load heavy charts, and set a budget (e.g., under 200 KB JS for first paint).
• Measure real-user metrics (time to first meaningful widget), and alert on regressions.

7) Wrap-Up

Serve an instant app shell from a CDN, authenticate with SSO/OIDC tokens validated at the gateway, and use a backend-for-frontend that fetches every widget's data in parallel with per-dependency timeouts, circuit breakers and partial responses. Cache per-user widgets briefly with background refresh, paint repeat visits from the client cache, enforce authorization in each backing service, and keep the page usable during outages by degrading widget by widget.