Design A Smart Home System - System Design

System requirements

Functional:

Users can register, pair, and manage devices (Wi-Fi, Zigbee, Z-Wave, Thread, Matter).
Users can control devices (on/off, brightness, temperature, lock/unlock) via app or voice.
System supports scheduling and automation (time-based, triggers, conditions, actions).
Users can access devices remotely through mobile/web apps.
System integrates with voice assistants (Alexa, Google, Siri).
Provide energy usage monitoring per device and household.
Support home security features (cameras, motion sensors, door locks, alarms).
Provide notifications and alerts (push, SMS, email).

Non-Functional:

Interoperability: Work with multiple device protocols and ecosystems.
Performance: Commands execute within <1 second under normal conditions.
Reliability: Core automations must work even if cloud is offline (local hub fallback).
Scalability: Support thousands of devices per home and millions of users globally.
Security & Privacy: End-to-end encryption, role-based access, GDPR compliance.
Availability: Cloud backend uptime target 99.9%.
Usability: Simple, intuitive mobile/web UI for non-technical users.

Capacity estimation

Capacity Estimation (1M Homes)

Homes: 1M
Devices: ~20 per home → 20M devices

Messaging

Telemetry: 15 devices/home → 500K msgs/sec peak
Commands/state changes: ~600/sec (small load)

Storage

Telemetry (~200B/msg): 8.6 TB/day → 780 TB for 90 days hot storage
Video (10% homes, 1 min/day): ~22 TB/month

Bandwidth

Inbound: ~100 MB/sec
Outbound: ~120 MB/sec

Infrastructure

MQTT Cluster: 10–15 broker nodes
Event Stream: Kafka cluster + 50–100 rule workers
DBs: Timescale/Influx for telemetry (~1 PB scale), Postgres for metadata, Redis for caching
Multi-region, 99.9% uptime target

API design

Authentication

POST /auth/token — OAuth2 token exchange (clients).
POST /auth/device — device enroll with cert or provisioning token.

Device management

GET /homes/{homeId}/devices
GET /homes/{homeId}/devices/{deviceId}
POST /homes/{homeId}/devices/{deviceId}/commands
GET /homes/{homeId}/devices/{deviceId}/state

Telemetry & history

GET /homes/{homeId}/devices/{deviceId}/telemetry?from=...&to=...&metric=power

Automation & scheduling

POST /homes/{homeId}/rules — create rule (body = DSL)
GET /homes/{homeId}/rules/{ruleId}
POST /homes/{homeId}/schedules — create scheduled scene

WebSocket / Realtime

ws /realtime?token=... — subscribe to home/{homeId}/events channels.

Database design

Relational DB (Postgres/MySQL) – Core Metadata

Stores structured, relational data (users, homes, devices, rules, schedules).

  "users": {
    "user_id": "uuid",
    "email": "string",
    "password_hash": "string",
    "role": "owner | admin | guest",
    "created_at": "timestamp"
  }

  "homes": {
    "home_id": "uuid",
    "user_id": "uuid (FK -> users.user_id)",
    "name": "string",
    "timezone": "string"
  }

  "devices": {
    "device_id": "uuid",
    "home_id": "uuid (FK -> homes.home_id)",
    "type": "light | thermostat | lock | camera | sensor",
    "protocol": "wifi | zigbee | zwave | thread | matter",
    "manufacturer": "string",
    "model": "string",
    "firmware": "string",
    "status": {
      "power": "on | off",
      "brightness": "int",
      "temperature": "float",
      "lock_state": "locked | unlocked"
    },
    "last_seen": "timestamp"
  }

  "automation_rules": {
    "rule_id": "uuid",
    "home_id": "uuid (FK -> homes.home_id)",
    "name": "string",
    "trigger": {
      "type": "motion | schedule | sunset | sensor",
      "device_id": "uuid",
      "property": "string",
      "operator": ">, <, =, !=, etc.",
      "value": "any"
    },
    "conditions": [
      {
        "device_id": "uuid",
        "property": "string",
        "operator": "string",
        "value": "any"
      }
    ],
    "actions": [
      {
        "device_id": "uuid",
        "command": "turn_on | turn_off | set_temp | notify",
        "params": {}
      }
    ],
    "enabled": "boolean"
  },

  "schedules": {
    "schedule_id": "uuid",
    "home_id": "uuid (FK -> homes.home_id)",
    "device_id": "uuid (FK -> devices.device_id)",
    "cron_expr": "string (e.g., '0 7 * * *')",
    "action": {
      "command": "turn_on | turn_off",
      "params": {}
    }
  }

Time-Series DB (TimescaleDB/InfluxDB) – Telemetry

Stores sensor readings & device telemetry.

  "telemetry": {
    "ts": "timestamp",
    "device_id": "uuid (FK -> devices.device_id)",
    "metric": "temperature | humidity | power | motion",
    "value": "float",
    "unit": "°C | % | W | kWh"
  },
  "media_files": {
    "media_id": "uuid",
    "device_id": "uuid (FK -> devices.device_id)",
    "type": "snapshot | clip",
    "url": "string (S3/GCS path)",
    "created_at": "timestamp"
  }

High-level design

Edge node layer

This is where physical devices exist inside the home.

Wi-Fi Devices - devices that connect directly to the cloud or local hub via Wi-Fi.
Smart Home Hub (Zigbee / Z-Wave / Thread) - A bridge to connect low-power devices (Zigbee, Z-Wave, Thread) to the cloud.
Zigbee / Z-Wave Devices - Smart bulbs, sensors, locks, etc., that talk to the hub.

Cloud Layer

This is the backend system that manages communication, automation, storage, and integration.

API Gateway & Auth - Entry point for mobile apps, third-party integrations, and authentication (OAuth, REST, WebSocket).
Command Service - Processes device control commands (e.g., turn on lights).
Message Broker / MQTT Cluster - Routes messages between devices and services.
Kafka - Streams events in real time for processing.
Scheduler Service - Triggers time-based tasks (e.g., "turn on lights at 7 PM").
Automation Engine - Executes user-defined automations (IFTTT-style rules).
Device cfg - Keeps track of registered devices, states, and metadata.
Relational DB (Configs) - Stores user accounts, device configs, and rules.
Time-Series DB - Stores sensor readings and telemetry data over time.
Object Storage (cold archive) - Long-term storage for large datasets or historical logs.
Notification Service - Push notifications, alerts, or emails.

Clients

How users and assistants interact with the system.

User Mobile / Web App - Directly communicates with the API Gateway for device control, monitoring, and configuration.
Voice Assistant Clouds (Alexa, Google) - Use OAuth skill integrations to control devices through the system.

Request flows

1. Device Control (User turns on a light)

User action:
- User taps “Turn On” in mobile app.
App → Cloud:
- REST/GraphQL API request:

POST /devices/{id}/command
{ "command": "turn_on" }

Cloud → MQTT Broker:
- System publishes message to device’s topic.

topic: devices/{id}/commands
payload: { "command": "turn_on" }

Device executes command and updates state.
Device → Cloud:
- Sends acknowledgment/state update via MQTT telemetry.
Cloud → App:
- Pushes new state → app updates UI instantly.

2. Telemetry (Device sends sensor data)

Device → MQTT Broker:

topic: devices/{id}/telemetry
payload: { "temperature": 23.5, "unit": "C" }

MQTT → Stream Processor (Kafka/Rules Engine).
Processor → TimescaleDB: Insert telemetry.
Processor → Automation Engine:
- If rule triggered → send command back via MQTT.
App (subscribed) gets real-time updates via WebSocket/Push.

3. Automation Rule (Motion sensor turns on light)

Motion Sensor detects movement.
Device → MQTT Broker with event:

{ "motion": true }

Rules Engine evaluates automation:
- IF motion == true AND time between 7 PM–6 AM → Turn on light.
Engine → MQTT Broker sends light command:

{ "command": "turn_on" }

Light updates state and sends confirmation.

4. Remote Access (User outside home)

User logs into mobile app (remote).
Auth Service (OAuth2/JWT) verifies credentials.
App → Cloud API request.
Cloud → MQTT Broker → device command.
Same flow as local control, but over cloud infrastructure.

5. Security Event (Door unlocked)

Door lock → MQTT Broker:

{ "status": "unlocked" }

Stream Processor writes event to DB + triggers alert.
Notification Service sends:
- Push notification, SMS, or email.
App → User sees “Front Door Unlocked at 8:32 PM.”

Detailed component design

1. Local Smart Hub / Border Router

Bridges Zigbee/Z-Wave/Thread → translates to MQTT or CoAP.
Runs a local automation engine for critical rules (locks, alarms) when cloud unavailable.
Maintains encrypted persistent connection to cloud MQTT cluster (TLS + client cert).
Exposes local web UI for device pairing and diagnostics.

2. MQTT Cluster (Message Broker)

Broker choices: EMQX / HiveMQ / VerneMQ.
Handles device telemetry and commands.
Topics organized by tenant / home / device: home/{homeId}/device/{deviceId}/telemetry and home/{homeId}/device/{deviceId}/cmd.
QoS: sensors publish QoS 0–1; commands use QoS 1 or 2 where needed.
Session persistence for offline devices.

3. API Gateway & Auth

Authentication: OAuth2 for clients, mutual TLS or token-based auth for hubs/devices.
Rate limiting, request validation, WebSocket for real-time UI updates.
Issue short-lived JWTs for apps.

4. Device Management & Directory

Postgres store with device metadata, capabilities, firmware versions, ownership, location (room).
Device states persisted in an in-memory cache (Redis) for quick state queries; persisted snapshots in DB.

5. Time-Series DB

InfluxDB / TimescaleDB for telemetry (energy meters, temp, humidity).
Retention policies: hot (30–90 days), cold (S3 archive).

6. Rules & Automation Engine

Declarative rules stored in DB; executed by a fleet of stateless workers that read events from Kafka.
Support for complex triggers (multi-sensor, temporal, stateful).
Provide local fallback version pushed to Hub.

7. Scheduler Service

Cron / calendar-based tasks (e.g., “every day at 7:00 run scene”).
Use a distributed scheduler (e.g., Quartz clustered or Kubernetes CronJobs + lease) or use Kafka with delayed messages.

8. Notification Service

Push notifications via APNS/FCM, SMS/email via providers.
Templating and user preferences (do not disturb windows).

10. Monitoring & Observability

Metrics (Prometheus), traces (OpenTelemetry), logs (ELK), health checks, alerting.

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

1. Device-to-Cloud Connectivity

Scenario: Device loses Wi-Fi/Zigbee/Z-Wave/Thread connectivity.
Impact: Commands fail, no telemetry updates.
Mitigation:
- Local hub fallback (run core automations locally).
- Offline queuing (buffer commands until reconnection).
- Redundant radio modules (dual Wi-Fi + Thread).

2. MQTT Broker Failure

Scenario: Central message broker (MQTT/EMQX/HiveMQ) crashes or overloads.
Impact: Devices cannot publish/subscribe → system outage.
Mitigation:
- Clustered brokers with load balancer.
- Horizontal scaling (auto-scale with traffic).
- Backpressure handling (drop non-critical telemetry, prioritize commands).

3. Cloud API Gateway Bottleneck

Scenario: High load on REST/GraphQL API gateway.
Impact: Slow app/device responses, request timeouts.
Mitigation:
- Rate limiting + caching (Redis).
- Multi-region API gateways.
- CDN for static content and lightweight telemetry dashboards.

4. Database Bottleneck

Scenario: High write/read load on telemetry DB.
Impact: Slow queries, dropped sensor data.
Mitigation:
- Use time-series DB (Timescale/Influx) with partitioning.
- Data retention policies (e.g., keep 90 days hot, archive older).
- Separate metadata DB (Postgres) from telemetry DB.

5. Automation Engine Lag

Scenario: Rules engine delayed under heavy event load.
Impact: Automations (e.g., motion → light on) trigger late.
Mitigation:
- Stream processing (Kafka, Flink).
- Prioritize latency-sensitive rules locally (on hub).
- Event-driven microservices (scale independently).

6. Notification Service Failure

Scenario: Push/SMS/email service down.
Impact: Security alerts don’t reach user.
Mitigation:
- Multi-channel notifications (push + SMS + email fallback).
- Queue retries (Kafka, RabbitMQ).

7. Single Point of Failure (SPOF)

Scenario: Hub hardware failure, cloud region outage.
Impact: Devices unreachable.
Mitigation:
- Dual-region deployments (active-active).
- Local-first design: basic automations run even if cloud is offline.
- Redundant hubs in large installations.

8. Security Breach

Scenario: Compromised device sends malicious traffic.
Impact: DDoS, unauthorized access.
Mitigation:
- TLS + mutual authentication (mTLS).
- Per-device keys & certificate rotation.
- Intrusion detection (anomaly detection on traffic).

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?