Design a Large-Scale Real-Time Temperature Collection System

Quick Overview

Design large-scale temperature collection with secure sensors, idempotent burst-tolerant ingestion, event and arrival time, current-state projections, time-series retention, downsampling, late corrections, realtime queries, and recovery.

Design a Large-Scale Real-Time Temperature Collection System

Company: Walmart Labs

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

## Prompt Design a system that ingests frequent temperature readings from a very large fleet of sensors and serves a website for both near-real-time values and historical trends. Cover device identity, ingestion, time-series storage, aggregation, querying, and operations under delayed, duplicated, or out-of-order readings. ### Constraints & Assumptions - Each reading has sensor ID, device sequence, observed timestamp, temperature, and ingestion timestamp. - The raw stream is retained for a bounded period; downsampled aggregates are retained longer. - The website shows current values and historical windows at several resolutions. - A sensor can be offline and upload buffered readings later. ### Clarifying Questions to Ask - How many sensors, what reporting frequency, and what freshness target drive capacity? - Which clock is trusted when device time drifts? - Do users query individual sensors, geographic groups, alerts, or all three? ```hint Separate event time from arrival time Keep both observed and ingested timestamps; watermarks let aggregates accept bounded lateness without pretending every device clock is correct. ``` ```hint Serve current state from a projection The latest valid reading per sensor is a different access pattern from scanning raw history. ``` ### What a Strong Answer Covers - Secure device registration, authentication, batching, and an idempotent ingestion contract. - Partitioning and buffering that absorb fleet-wide bursts and isolate hot tenants. - Raw time-series schema, current-value projection, downsampling, and retention. - Out-of-order handling, clock quality, deduplication, and correction semantics. - Query APIs, cache/realtime delivery, monitoring, backpressure, and disaster recovery. ### Follow-up Questions 1. How would you detect a sensor whose values are plausible but whose clock is drifting? 2. How would you recompute aggregates after a calibration correction? 3. What changes when users subscribe to threshold alerts within seconds?

Overview: Design large-scale temperature collection with secure sensors, idempotent burst-tolerant ingestion, event and arrival time, current-state projections, time-series retention, downsampling, late corrections, realtime queries, and recovery.

|Home/System Design/Walmart Labs
Walmart Labs logo
Walmart Labs
Aug 15, 2026
mediumSoftware EngineerTechnical ScreenSystem Design
2
0

Prompt

Design a system that ingests frequent temperature readings from a very large fleet of sensors and serves a website for both near-real-time values and historical trends. Cover device identity, ingestion, time-series storage, aggregation, querying, and operations under delayed, duplicated, or out-of-order readings.

Constraints & Assumptions

  • Each reading has sensor ID, device sequence, observed timestamp, temperature, and ingestion timestamp.
  • The raw stream is retained for a bounded period; downsampled aggregates are retained longer.
  • The website shows current values and historical windows at several resolutions.
  • A sensor can be offline and upload buffered readings later.

Clarifying Questions to Ask Guidance

  • How many sensors, what reporting frequency, and what freshness target drive capacity?
  • Which clock is trusted when device time drifts?
  • Do users query individual sensors, geographic groups, alerts, or all three?

What a Strong Answer Covers Guidance

  • Secure device registration, authentication, batching, and an idempotent ingestion contract.
  • Partitioning and buffering that absorb fleet-wide bursts and isolate hot tenants.
  • Raw time-series schema, current-value projection, downsampling, and retention.
  • Out-of-order handling, clock quality, deduplication, and correction semantics.
  • Query APIs, cache/realtime delivery, monitoring, backpressure, and disaster recovery.

Follow-up Questions Guidance

  1. How would you detect a sensor whose values are plausible but whose clock is drifting?
  2. How would you recompute aggregates after a calibration correction?
  3. What changes when users subscribe to threshold alerts within seconds?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...