IoT Sensor Readings Store with Bucketed Time Series in MongoDB

The problem: small clinics cannot see their cold chain

Vaccines, insulin and many other medicines must be stored within a narrow temperature range, commonly 2 to 8 °C. Large hospitals and national programmes use dedicated temperature loggers, but many small clinics and pharmacies still rely on a thermometer checked once or twice a day and a paper log. A fridge that warms up overnight during a long power cut, or because a door was left ajar, can go unnoticed until the stock has to be thrown away.

Sensors are cheap. The hard part is the data: a fridge reporting every 30 seconds produces nearly three thousand readings a day, a pharmacy chain with a hundred fridges produces millions a month, and the dashboards still have to be fast. How you store that time series in MongoDB decides whether the system stays quick and affordable, which is what makes it a good final year project.

What already exists and the gap

• WHO prequalified temperature monitoring devices, such as 30-day electronic temperature loggers, are used in national immunisation programmes, but they are standalone devices and their data is often read manually.
• ThingSpeak, AWS IoT SiteWise and Azure IoT offer IoT data platforms, powerful but general, with pricing and setup that do not suit a single pharmacy.
• InfluxDB and TimescaleDB are databases built for time series, and Grafana is the usual dashboard on top.

The gap is a small, affordable monitoring system built for clinics, with alerts and compliance reports they can actually use, and a backend whose storage design you have measured rather than assumed.

Inspiration

MongoDB's Building with Patterns series introduced the bucket pattern using exactly this kind of IoT example: group many readings into one document per sensor per time window instead of one document per reading. MongoDB later built the same idea into the database as time series collections, which bucket readings internally. Comparing the two, on your own data, is the heart of this project.

What you build

• Clinic staff: see every fridge's current temperature, get an alert on excursions, acknowledge it with a note.
• Pharmacy or clinic manager: see all sites, open 24-hour and 7-day charts, download a weekly compliance report.
• Devices: ESP32 boards with a sensor, sending readings over MQTT to an ingestion service.

Main flows: device sends readings, dashboard updates, a fridge drifts out of range, an alert fires and is acknowledged, a weekly report is generated.

The technically interesting part

• One document per reading versus buckets. Start with the naive design so you have a baseline, then build a bucket pattern collection: one document per sensor per hour with an array of readings plus pre-computed count, sum, min and max (the computed pattern), updated with $push and $inc in a single upsert. Watch for the unbounded array trap and cap each bucket.
• Native time series collections. Create a time series collection with a timeField, a metaField holding the sensor and site, and a suitable granularity. Measure it against your hand-built buckets on storage, index size, write throughput and query speed. Check the current manual for which update and delete operations time series collections allow, since that affects corrections to bad readings.
• Retention with TTL. Expire raw readings after a set period with expireAfterSeconds, while hourly summaries written by a scheduled $merge pipeline are kept longer. Decide and justify the retention periods.
• Dashboards from aggregation. Use $match on sensor and time range first, $dateTrunc or $group to roll readings up per hour, and $setWindowFields for moving averages. Every chart should be one pipeline you can explain.
• Indexes. A compound index on sensor and time for the bucket design; the time series collection's own indexing for the other. Prove both with explain output.

Show your supervisor the three schemas side by side, the benchmark table, and a dashboard query's explain plan.

How to evaluate it

• Storage: data and index size per million readings for each design, from collection statistics.
• Writes: sustained readings per second from the simulator before errors or backlog appear.
• Reads: p95 latency for the 24-hour chart, the 7-day chart and the weekly report on 10 million readings.
• Alerts: time from a fridge leaving the safe range to the alert appearing, measured on real hardware with a warm hand or an open door.
• Resilience: unplug the network for ten minutes and show no readings were lost.

Mind the free tier: an Atlas free cluster has 512 MB of storage, so run large benchmarks on a local MongoDB and keep the free cluster for the demo.

Suggested plan

• Weeks 1 to 2: hardware, MQTT, a simulator, and the naive one-document-per-reading store.
• Weeks 3 to 5: ingestion service with batching and buffering, bucket pattern design.
• Weeks 6 to 8: time series collection design, TTL, hourly summaries.
• Weeks 9 to 11: benchmarks at scale, dashboard, alerts.
• Weeks 12 to 15: compliance report, field test in a real or borrowed fridge, report.

Path to a product

Cold chain monitoring is a real business: pharmacies, clinics, vaccine stores, blood banks, restaurants and food distributors all need it, and many still use paper logs. A low-cost sensor kit plus a monthly subscription for dashboards, alerts and compliance reports is a proven model. Start with one pharmacy chain or clinic network willing to pilot it, and let their compliance reports sell it to the next.

Scope warning

Do not design custom PCBs or build your own mobile app in the core scope; development boards and a responsive web dashboard are enough. Support one sensor type well. Do not attempt certification of the device as a medical instrument.

Learn what you need on Sefism

• MongoDB roadmap: data modelling patterns, indexes and the aggregation pipeline, in order.
• MongoDB cheat sheet: the bucket and computed patterns, TTL indexes, unbounded arrays and $merge.
• MongoDB Manual: the time series collections section and the aggregation stage reference.
• MongoDB Atlas: a free cluster for the demo, and what its limits mean for your data volume.
• MongoDB Compass: inspect bucket documents and compare collection sizes.
• PyMongo Documentation or MongoDB Node.js Driver Documentation: batched writes from your ingestion service.

Get help with this idea

The risk here is spending the semester on hardware and leaving the storage design untested. Tauseef can help you set up the schema comparison early, size the benchmark to your hardware, and turn the results into the core of your report. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session