A city’s overnight pipelines occasionally stall silently, ship broken schemas, or spike in volume without alerts. What should architecture include among non-functionals?
Select an answer to reveal the explanation.
Short Explanation
If the night truck never arrives and nobody’s pager buzzes, leadership still drives with yesterday’s map. Architect for freshness, schema-break, and volume alarms—not just server CPU smileys.
Full Explanation
Non-functional architecture for municipal data platforms must treat pipeline observability as a first-class design concern, not an afterthought bolted onto application hosting. Overnight feeds that stall silently, ship broken schemas, or spike in volume without alerts cause wrong civic decisions—missed eligibility updates, stale dashboards, and late operational alerts—before anyone notices. Architecture therefore includes observability for freshness SLOs, unexpected schema breaks, and volume anomalies, with ownership, thresholds, and response playbooks tied to those signals. Limiting observability to CPU charts on app servers fails by concept because infrastructure load does not reveal data-product health such as late arrivals or structural drift. Manual spot-checks once a year fail because nightly municipal pipelines need continuous monitors, not annual audits, to catch freshness breaches. Disabling logs to reduce storage fails by accepting silent data failures that erode trust in official metrics and incident forensics. Exam caveat: observability signals need thresholds and named responders, not dashboards alone; architecture funds monitors and runbooks together, and alert noise must be managed so pages remain actionable. Operational check: define freshness, schema-drift, and volume-anomaly alerts for critical city pipelines; assign on-call owners; test that a delayed feed pages someone; document playbooks; and review monthly false-positive and miss rates with data product stewards.