A dashboard aggregates three municipal APIs, and one slow dependency should not blank the entire page. Which resilience approach should the developer apply?
Select an answer to reveal the explanation.
Short Explanation
If one streetlight sensor is offline, the whole city map shouldn't go black. Timeout and degrade that panel while the other two APIs still render. One global fail-together timeout, no timeouts at all, or abort-on-first-error are how one slow neighbor blanks the dashboard.
Full Explanation
When a dashboard aggregates three municipal APIs and one slow dependency should not blank the entire page, isolate failures with per-dependency timeouts, partial responses, or circuit breakers. Show permits and fees even if inspections time out, with a clear degraded panel. Independent time budgets and bulkheads prevent one sick system from becoming a citywide blank screen for clerks during morning rush.
Making all three calls share one global timeout that fails the whole page together couples unrelated SLAs into a single brittle budget. Removing timeouts lets hung dependencies exhaust workers and queue citizen requests. Serializing the three calls and aborting the page if any single call throws maximizes latency and failure correlation—the opposite of resilient aggregation.
Exam caveat: partial responses need explicit UX so staff do not mistake an empty inspections widget for “no inspections exist.” Combine timeouts with circuit breakers when a dependency is hard-down, and emit per-dependency metrics rather than one opaque dashboard-failure counter.
Operational check: set per-call timeouts; catch failures and return partial dashboard JSON with degradation flags; optionally short-circuit open breakers; measure success rate per dependency; and verify clerks still get actionable panels when one API is dark.