Emergency management wants observation ingest, model runs, and public alerts as layered services. Which architecture pattern matches?
Select an answer to reveal the explanation.
Short Explanation
Watch the sky, run the model, then ring the bell — three layers, not one email of mystery numbers. That sensor-to-forecast-to-alert flow is the pattern emergency managers need.
Full Explanation
Weather-company-style architectures separate observation ingest, analytical/model processing, and dissemination of alerts or products. Emergency management mirrors that chain for civic hazards: ingest observations, run models, then alert the public. Explicit layers keep ingest failures from silently corrupting public warnings and clarify ownership of each stage.
A social-graph pattern focused only on friend-of-friend job referrals fails by concept: wrong problem class. A single CSV email blast with no models and no layered services fails by concept: that is not sensor-to-model-to-alert architecture. A media recommender that only ranks council videos fails by concept: entertainment ranking is not hazard dissemination.
Exam caveat: Use a sensor-to-model-to-dissemination pattern for EM alerts—not social-graph hiring, CSV blasts, or video recommenders.
Operational check: Assign owners for ingest, model runs, and public alerting; test that a bad ingest cannot publish unreviewed alerts; rehearse the chain before storm season. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.