Practice/Apple/Design Data Model for Building Management System

Design Data Model for Building Management System

System DesignMust

Problem Statement

Design a system that tracks who is where inside office buildings in real time. Badge readers at entrances, restroom sensors, and parking gates stream events. The system should answer questions like: "How many people are in Building A right now?", "How many people are in the restrooms?", and "How many employees parked today?"

This problem tests your ability to model event-driven state, maintain accurate counters under high throughput, and serve real-time dashboards. The key challenge is turning a raw event stream into up-to-date materialized views without losing accuracy — even when events arrive out of order or sensors fail.

Key Requirements

Functional

Real-time occupancy -- show current headcount for each building, floor, restroom, and common area
Individual lookup -- look up where a specific employee is currently located (with access controls)
Parking metrics -- track daily parking usage: how many employees parked today, peak occupancy
Alerts -- notify facilities when occupancy thresholds are crossed (e.g., restroom cleaning needed)

Non-Functional

Scalability -- support hundreds of buildings with thousands of sensors each
Latency -- occupancy dashboards refresh within 2-3 seconds of a real event
Accuracy -- counters must be eventually correct; brief inaccuracy during bursts is acceptable
Reliability -- no event loss; the system must recover from sensor failures and produce correct state

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Event-Driven State Modeling

Raw sensor events (badge-in, badge-out, parking-enter, parking-exit) need to be transformed into materialized views (current occupancy counts, per-person location).

Hints to consider:

Separate the raw event stream from the materialized state — events are the source of truth, counters are derived
Use atomic increment/decrement operations on counters for each entry/exit event
Maintain per-person state (current zone) alongside aggregate counters for individual lookups
Discuss how to handle the initial state problem: on system startup, how do you know the current occupancy?

2. Handling Unreliable Sensors and Missing Events

Sensors can fail, duplicate events, or miss exits (e.g., someone tailgates through a door). Over time, counters drift from reality.

Hints to consider:

Assign sequence numbers or timestamps to events for ordering and deduplication
Use heartbeat/presence timeouts: if an employee's last event was "entered restroom" 30 minutes ago, assume they left
Periodically reconcile counters using ground truth (e.g., turnstile counts at building entrances)
Discuss how to handle out-of-order events: a late "exit" event should still decrement the counter correctly

3. Hot Counter Contention

Building entrances during morning rush or restrooms during breaks create extreme write contention on a single counter.

Hints to consider:

Use sharded counters: split a single counter into N sub-counters, distribute writes across them, sum on read
Atomic increment operations in Redis (INCR/DECR) are fast but still have per-key throughput limits
Batch rapid events (aggregate multiple badge-ins per second before updating the counter)
For read-heavy dashboards, cache the aggregated value with a short TTL (1-2 seconds)

Practice/Apple/Design Data Model for Building Management System

Design Data Model for Building Management System

System DesignMust

Problem Statement

Key Requirements

Functional

Real-time occupancy -- show current headcount for each building, floor, restroom, and common area
Individual lookup -- look up where a specific employee is currently located (with access controls)
Parking metrics -- track daily parking usage: how many employees parked today, peak occupancy
Alerts -- notify facilities when occupancy thresholds are crossed (e.g., restroom cleaning needed)

Non-Functional

Scalability -- support hundreds of buildings with thousands of sensors each
Latency -- occupancy dashboards refresh within 2-3 seconds of a real event
Accuracy -- counters must be eventually correct; brief inaccuracy during bursts is acceptable
Reliability -- no event loss; the system must recover from sensor failures and produce correct state

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Event-Driven State Modeling

Raw sensor events (badge-in, badge-out, parking-enter, parking-exit) need to be transformed into materialized views (current occupancy counts, per-person location).

Hints to consider:

Separate the raw event stream from the materialized state — events are the source of truth, counters are derived
Use atomic increment/decrement operations on counters for each entry/exit event
Maintain per-person state (current zone) alongside aggregate counters for individual lookups
Discuss how to handle the initial state problem: on system startup, how do you know the current occupancy?

2. Handling Unreliable Sensors and Missing Events

Sensors can fail, duplicate events, or miss exits (e.g., someone tailgates through a door). Over time, counters drift from reality.

Hints to consider:

Assign sequence numbers or timestamps to events for ordering and deduplication
Use heartbeat/presence timeouts: if an employee's last event was "entered restroom" 30 minutes ago, assume they left
Periodically reconcile counters using ground truth (e.g., turnstile counts at building entrances)
Discuss how to handle out-of-order events: a late "exit" event should still decrement the counter correctly

3. Hot Counter Contention

Building entrances during morning rush or restrooms during breaks create extreme write contention on a single counter.

Hints to consider:

Use sharded counters: split a single counter into N sub-counters, distribute writes across them, sum on read
Atomic increment operations in Redis (INCR/DECR) are fast but still have per-key throughput limits
Batch rapid events (aggregate multiple badge-ins per second before updating the counter)
For read-heavy dashboards, cache the aggregated value with a short TTL (1-2 seconds)