Oxaira
AirQ, an air quality monitoring system: an ESP32 device, Spring Boot services, messaging and web and mobile apps.
The problem
Sensor data must reach an understandable interface and trigger alerts without coupling capture, analysis and notification.
What I built
An ESP32 with DHT11 and MQ135 sensors sends readings over HTTP. Separate Spring Boot services cover analytics and alerts, notifications and SMS through Twilio, with Angular and Flutter apps.
Outcome
A system of independent services, from the board to the phone. Documented from the team’s repositories.
Decisions that mattered
- 01
One service, one responsibility
Analytics, notifications and SMS are separate services, each with its own database.
- 02
An air quality domain
The analytics service models readings, alerts and insights as aggregates, with separate commands and queries.
- 03
Messaging to decouple
RabbitMQ carries alerts to notifications, and Kafka was explored for the event stream.
Technologies
- Spring Boot
- RabbitMQ
- Kafka
- MySQL
- Angular
- Flutter
- ESP32
C4 model. The pulsing line is the main path of a request.
Level 1 · who uses the system and what it connects to
Level 2 · the applications and data stores it is made of
Level 3 · the components inside the API
- Person
- System
- Container
- Database
- External
- Main path
- 01ESP32 sensor
- 02Analytics
- 03RabbitMQ
- 04Notifications
- 05SMS
- 06App