Develop a Weather Application — System Design Interview Practice

Interview prompt

Design a weather service that aggregates provider observations and forecasts, serves current conditions and multi-day outlooks, and delivers timely location-aware alerts with freshness metadata.

• Define provider normalization, station/grid identity, forecast versions, units, timezone, freshness, confidence, and alert lifecycle.
• Cache by geospatial cell and forecast horizon, refresh adaptively, reconcile conflicting providers, and avoid thundering-herd refreshes.
• Separate provider ingestion from serving projections, historical observations, notifications, and expensive forecast transformations.
• Explain provider outage, stale labeling, alert deduplication, location privacy, observability, and degraded cached forecasts.

Requirements and scale assumptions

• Return current conditions, hourly/daily forecasts, historical observations, air-quality fields, units, and provider/freshness metadata.
• Subscribe users to threshold/severe-weather alerts by location, deduplicate notifications, and support locale/timezone preferences.
• Ingest multiple providers, retry safely, backfill gaps, invalidate outdated forecasts, and serve cached data with an explicit stale marker.
• Serve common forecast reads with p95 under 200ms and propagate severe alerts within two minutes of provider receipt.
• Scale to 50M users and highly skewed popular locations without a single hot key or unbounded synchronous work.
• Do not lose committed state; make retries and duplicate events safe.
• Degrade safely when downstream workers, caches, or external dependencies fail.
• 50M users, 10M watched locations, and 1M provider updates per hour
• Partition by the primary tenant, user, item, or geographic key and isolate hot partitions.
• Keep serving state bounded; retain raw events or durable records for replay and auditing.

• Peak scale: 50M users; 1M provider updates/hour — Capacity assumption that drives partitioning and backpressure.
• Latency target: forecast p95 < 200ms; alerts < 2m — User-facing budget for the primary request or read path.
• Durable boundary: Committed before async — Versioned provider observations/forecasts and alert bulletins are authoritative; cached responses are derived.
• Async boundary: At-least-once workers — Keep Integrate with weather APIs, Cache weather data with TTL, Geolocation for user location off the synchronous path.

Key entities

• ObservationlocationId, provider, eventTime, temperature, conditions, quality

  Timestamped weather observation with provider provenance.

• ForecastVersionlocationId, provider, issuedAt, validFrom, validTo, modelVersion

  Versioned forecast used by weather application.

• LocationSubscriptionsubscriptionId, userId, locationId, thresholds, channels, status

  User alert policy and delivery preferences.

• ForecastQualitylocationId, metric, window, provider, value, sampleCount

  Observed-versus-forecast quality evidence.

Data flow

1. 1. Collect provider observationsCollectors fetch weather application feeds with cursors, signatures, quotas, and explicit provider failure state.
2. 2. Normalize and preserve versionsWorkers map provider-specific data into canonical observations and forecasts without discarding provenance.
3. 3. Serve location and time-window readsThe API reads freshness-aware cache or time-indexed storage and reports quality or gap state.
4. 4. Evaluate severe-weather alertsAlert workers compare new updates to subscription thresholds and send deduplicated notifications.
5. 5. Measure and reconcile qualityQuality jobs compare forecasts to later observations and flag provider gaps, bias, or stale coverage.

Deep dives and trade-offs

• Provider freshness and gapsCarry provider issue time, valid time, fetch time, cursor, and signature through the model. Expose spatial coverage and stale state instead of silently filling a missing provider feed. Use provider adapters so schema or quota failures are isolated.
• Time and spatial indexingPartition by geospatial cell and valid-time bucket for bounded forecast reads. Keep forecast revisions separate from observations so consumers can compare what was known when. Cache only with a provider watermark and expiry contract.
• Alert correctnessEvaluate thresholds with hysteresis, deduplication, and subscription version to prevent alert storms. Record the forecast or observation evidence behind each alert. Track delivery latency, suppressed duplicates, and stale-policy behavior.
• Provider redundancy versus costUse multiple providers for severe-weather or high-availability paths and a single source for lower-risk products. Failover without normalization or confidence metadata can produce contradictory forecasts.
• Precompute tiles versus query on demandPrecompute common spatial/time products and compute rare views within a bounded budget. Generating every resolution and time horizon is expensive and hard to invalidate.
• Freshness versus stabilityExpose issued and valid times and choose product-specific freshness budgets. Aggressively refreshing can amplify provider rate limits without improving forecast quality.