What Candidates Reported
Two independent candidate reports describe weather-application system-design rounds at Amazon. One L5 report names a weather app built on geolocated balloon infrastructure; a separate SDE II offer report describes a roughly thirty-five-minute weather-app design discussion with follow-up probing. The reports do not publish a complete internal rubric, so this exercise uses the shared prompt signal while supplying transparent practice assumptions.
Problem and Scope
Design a service that ingests geolocated weather observations and serves current conditions, regional heatmap tiles, and historical daily extrema. Clarify measurement types, freshness, map resolution, query geometry, retention, and whether late corrections must become visible to users before selecting infrastructure.
Critical Design Decisions
A strong design separates durable raw ingestion from derived views. It defines stable reading identifiers, event-time handling, validation, and backpressure before describing stream processing. Storage and indexes should support time-series writes and bounded geospatial reads. Heatmap tiles and daily aggregates need explicit freshness, correction, cache invalidation, replay, and versioning behavior.
Failure Scenarios to Practise
Test the design with offline sensors replaying old data, duplicate uploads, poisoned readings, stream-processor downtime, hot geographic regions, clock skew, zone failure, and a faulty aggregation deployment. The answer should state what users see, what data remains durable, and how operators detect and repair each condition.
How the Answer Is Evaluated
MockMe scores scope and data semantics (15%), ingestion and correctness (25%), data model and query paths (20%), derived views and reliability (25%), and communication and trade-offs (15%). High scores require mechanisms for late data, deduplication, geospatial fan-out, replay, freshness, and degraded operation, supported by a coherent end-to-end design.