MongoDB Bucket Pattern for Time-Series
Fast recall
Quick revision
Core answer
bucketId, a time range, a measurements array, and pre-aggregated summary fields like count, sum, min, max. This cuts document count by 10–1000x, shrinks index size dramatically, reduces storage overhead, and accelerates range queries — ideal for IoT sensors, metrics, logs, and stock ticks. MongoDB 5.0+ introduced native time-series collections that automate bucketing, but the hand-rolled pattern still wins when you need custom grouping (per-user per-hour) or non-time keys.Whether you can identify and apply MongoDB schema patterns beyond naïve one-document-per-event modeling
Inserting one document per sensor reading, ignoring index/storage blow-up; or picking bucket size without considering the 16MB doc limit
Mention MongoDB 5.0+ native time-series collections, show pre-aggregation fields, and explain the 16MB cap driving bucket-size choice
Interview-ready guide
Interview answer
Frame the problem
- Naïve one-doc-per-event blows up index and storage
- Bucket pattern groups events into one document per entity per window
Describe the shape
bucketStart,bucketEnd,measurementsarray, pre-aggregatedcount/sum/min/max- Upsert with
$push+$inc+$min+$max+$setOnInsert - Index on
(metaField, bucketStart)
Mention the 16MB limit
- Choose bucket granularity so peak bucket stays below ~10MB
- Late-arriving data requires retroactive upsert
Call out MongoDB 5.0+ time-series
timeseries: { timeField, metaField, granularity }- MongoDB auto-buckets, auto-compresses, exposes normal API
- Hand-roll still wins for custom pre-aggregation or non-time group keys
MongoDB Bucket Pattern for Time-Series
Direct Answer
The bucket pattern stores many small time-stamped events grouped into a single parent document (one bucket per entity per time window), instead of one document per event. Each bucket has a bucketId, a time range, a measurements array, and pre-aggregated summary fields like count, sum, min, max. This cuts document count by 10–1000x, shrinks index size dramatically, reduces storage overhead, and accelerates range queries — ideal for IoT sensors, metrics, logs, and stock ticks. MongoDB 5.0+ introduced native time-series collections that automate bucketing, but the hand-rolled pattern still wins when you need custom grouping (per-user per-hour) or non-time keys.
Common Mistakes & Pitfalls
Inserting one document per sensor reading, ignoring index/storage blow-up; or picking bucket size without considering the 16MB doc limit
Check your understanding
Answer these without looking back at the article.
- How do you handle late-arriving measurements that belong to a closed bucket?
- What's the trade-off between hourly and minute-level bucket granularity?
- How do MongoDB 5.0+ time-series collections compress numeric columns internally?
- When would you prefer InfluxDB or TimescaleDB over MongoDB time-series?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.