Multi-Tenant SaaS Architecture: One Platform, Thousands of Customers

Tesla: 4 Million Cars Streaming Data Every Second

Multi-Tenant SaaS Architecture is designed to support thousands of customers on one platform, but the same scalability principles become critical when systems must handle massive streams of data from connected devices. Every Tesla on the road streams sensor data, GPS position, battery temperature, motor RPM, Autopilot decisions, back to Tesla's servers. That's 4 million vehicles, each sending readings every second. Combined with industrial IoT (smart factories with 100,000 sensors per facility), we're looking at billions of events per second. Traditional web architecture (load balancer, REST API, PostgreSQL) would collapse under this write throughput. SaaS architecture must therefore be designed for one platform serving thousands of customers while handling enormous data volumes reliably.

IoT Ingestion Pipeline

IoT Telemetry Architecture:

  [4M Devices]  [100K Factory Sensors]  [Smart Grid Meters]
       |                |                      |
       v                v                      v
  [MQTT Broker Cluster]  (HiveMQ / EMQX / Mosquitto)
  - Persistent connections (not HTTP per request)
  - 2-byte header (vs HTTP's ~800 bytes)
  - QoS levels: 0=fire-and-forget, 1=at-least-once, 2=exactly-once
  - 1M concurrent connections per broker node
       |
       v
  [Kafka Cluster]  (ingestion buffer)
  - Decouples ingestion from processing
  - Survives downstream outages (data buffered on disk)
  - Partitioned by device_region for locality
  - Retention: 7 days (replay if processing fails)
       |
       +----------+----------+
       |          |          |
       v          v          v
  [Stream      [Batch     [Alerting
  Processing]  Archive]    Engine]
  (Flink)      (S3/HDFS)   (Flink CEP)
       |          |          |
       v          v          v
  [TimescaleDB] [Data     [PagerDuty/
   hot data]    Lake]      SMS Alert]

Protocol Comparison

IoT Protocol Selection:

Protocol   Header Size   Transport   Power Use   Best For
--------   -----------   ---------   ---------   ------------------
MQTT       2 bytes       TCP         Low         Most IoT devices
CoAP       4 bytes       UDP         Very Low    Battery sensors
HTTP/2     ~20 bytes     TCP         High        Gateway devices
AMQP       8+ bytes      TCP         Medium      Industrial systems

Why not HTTP REST?
- Each HTTP request: ~800 bytes of headers for a 100-byte payload
- MQTT: 2-byte header for the same 100-byte payload
- At 1M devices x 1 msg/sec:
  HTTP: 800 MB/s wasted on headers
  MQTT: 2 MB/s on headers
  Savings: 99.75% less overhead

Time-Series Storage and Downsampling

Downsampling Strategy (TimescaleDB):

-- Raw data: keep 7 days (1-second resolution)
-- Hourly rollups: keep 90 days
-- Daily rollups: keep forever

-- Continuous aggregate (auto-computed by TimescaleDB)
CREATE MATERIALIZED VIEW sensor_hourly
WITH (timescaledb.continuous) AS
SELECT
    device_id,
    time_bucket('1 hour', timestamp) AS hour,
    AVG(temperature) AS avg_temp,
    MAX(temperature) AS max_temp,
    MIN(temperature) AS min_temp,
    COUNT(*) AS reading_count
FROM sensor_readings
GROUP BY device_id, hour;

-- Retention policy: auto-drop raw data older than 7 days
SELECT add_retention_policy('sensor_readings', INTERVAL '7 days');

-- Storage savings:
-- Raw:    1B readings/day x 100 bytes = 100 GB/day
-- Hourly: 1B / 3600 x 100 bytes = 27 MB/day
-- 99.97% storage reduction after 7 days

Interview Tip

IoT platform design centers on three key decisions: (1) Protocol - use MQTT (not HTTP) because 2-byte headers vs 800 bytes matters at millions of devices, (2) Buffering - Kafka between ingestion and processing so downstream failures don't lose data, (3) Storage - time-series DB with automatic downsampling (keep raw data 7 days, rollups forever). The key insight: IoT is a write-heavy system (99% writes, 1% reads) - the opposite of web applications.