Key takeaways
- Ingestion, aggregation and reports are bounded per-tenant work done on the request path
- Two jobs run as in-process cron: device liveness and data retention
- Both are idempotent sweeps with no per-item retry needs
- Introduce a queue when per-event background work appears, not before
Queues are not free
A queue adds infrastructure, retry policy, monitoring and failure modes. It earns its place when work is slow, spiky or needs per-item retries. Most of this platform's work is none of those.
The two jobs we do run
Device liveness runs every minute. It marks devices whose heartbeat lapsed as offline and raises one deduplicated notification per device. Data retention runs daily at 02:00 and deletes events, sessions and reports older than each organization's configured window.
Idempotence over retries
Both jobs are sweeps. Running one twice, or missing a run, is harmless because the next run reaches the same end state. That removes the main reason to reach for a queue.
When to change course
If you add per-event background work, such as queued export generation, you want retries, backoff and visibility. That is the point to introduce a real queue.