beginner · review

Review: The Eleven-Call Dashboard

The mobile dashboard takes 4–6 seconds to load on LTE while the same data renders instantly in the office. Mobile engineers maintain a waterfall of API calls with hand-rolled caching and partial-failure handling for one screen.

Evidence

dashboard screen load (app trace, LTE ~120ms RTT):
  1. GET /me                      -> need user_id for everything else
  2. GET /accounts?user=..        -> need account ids
  3. GET /balances/{acct1}        sequential: each needs the previous response
  4. GET /balances/{acct2}
  5. GET /transactions?acct=1&limit=3
  6. GET /transactions?acct=2&limit=3
  7. GET /cards?user=..
  8. GET /notifications/unread-count
  9. GET /offers?segment=..       -> needs segment from /me
 10. GET /kyc-status
 11. GET /app-config
=> 11 requests, ~7 sequential hops deep; payloads total 340KB for a screen that shows ~30 values

Investigate

Inspect Request waterfall

Seven of the eleven calls are **sequential** — each needs the previous response — so at 120ms RTT the network alone costs ~850ms before any server time or rendering; the screen's floor is set by round trips, not bandwidth.

Inspect API granularity vs consumer task

Each endpoint mirrors one internal service (accounts, cards, offers, KYC...), so the consumer task “render the dashboard” exists nowhere in the API — the client is doing the composition job with the worst tool: a phone on LTE.

Inspect Payload fit

Endpoints return their full web-oriented representations; the screen uses roughly 30 fields out of 340KB — over-fetching stacked on top of the chattiness.

Inspect Failure handling

Eleven calls mean eleven partial-failure states; the app shows a half-rendered dashboard when call 6 times out, and each mobile team invents its own retry/spinner logic.