Contact
Work Experience About Contact
LinkedIn GitHub
All work Case study 02 · Hooshmand Sazan · Smart home

IoT Telemetry

The backend for a smart home platform running in around 100 homes: thermostats, lighting and sensors reporting over MQTT, every device authenticated by its own mTLS certificate, bridged into Kafka as one event stream.

Role
Senior Java Software Engineer
When
2016 to 2019
Team
Around 10 backend engineers, I owned service design
Scale
Around 100 homes, thousands of devices
01

Context

I joined Hooshmand Sazan Company as a Junior Java Developer in 2014, wiring Bluetooth Low Energy sensors and event-driven logic into smart home features. From 2016, as a senior engineer, I owned service design for a backend team of around 10 engineers and built the backend for a smart home platform.

It ran in roughly 100 homes. Thermostats, lighting and sensors reported over MQTT: tens of thousands of readings a day from thousands of devices.

02

Problem

Every device in someone’s home is a way into the system, so a cloned or stolen device must never be able to join the fleet. Downstream services needed the readings without each of them talking to the device broker. And when something failed, a device or a service, the team had to find where across the whole pipeline, not one log file at a time.

03

Constraints

  • Hardware in people’s homes, outside any data centre: each device has to prove who it is.
  • Many devices at once. Tens of thousands of readings a day from thousands of devices, and the ingest path had to be sized before rollout, not after.
  • One team, one data stream. Around 10 backend engineers building on the same device data, with me owning the service design.
Thermostats own mTLS certificate Lighting own mTLS certificate Sensors own mTLS certificate PKI one certificate per device MQTT broker mutual TLS no valid cert, no entry Load tests thousands of devices BACKEND Bridge MQTT → Kafka Kafka topics: one event stream Services Java · Spring Boot Elasticsearch all logs logs
Simplified view of the telemetry pipeline. Swipe sideways to see the whole diagram
04

What I did

  • One certificate per device. Every thermostat, light and sensor authenticated to the MQTT broker with its own mTLS certificate, so a cloned or stolen device could not join the fleet.
  • A bridge from MQTT to Kafka. Device readings landed on Kafka topics, so downstream services consumed one event stream instead of talking to the device broker directly.
  • All logs in one place. Service logs went into a single Elasticsearch cluster, so a failing device or service could be traced across the whole pipeline.
  • Load tests before rollout. Gatling and JMeter scenarios modelled thousands of devices reporting at once, to size the ingest path before it met real homes.
05

Result

~100

homes running the platform

1

certificate per device: a cloned or stolen one stays out

1

event stream for every downstream service

Plus one Elasticsearch cluster to trace a failure end to end. The same ideas live on in IoT Telemetry, my open-source Java and Kafka project for streaming sensor telemetry.

06

Stack

  • Java 8
  • Spring Boot
  • MQTT
  • Kafka
  • mTLS
  • PKI
  • Elasticsearch
  • Gatling
  • JMeter
  • Microservices
  • SQL
IoT Telemetry on GitHub Read: what holds up outside the demo The full role on the About page
Contact

Building software that has to work.

Open to senior backend roles in Berlin, hybrid or remote. Just as happy to talk distributed systems with no job attached.

Book a 20-min intro call hello@rejali.de