How to handle configurable alert deduplication in a vehicle tracking system
07:14 27 Jul 2026

We are building a vehicle tracking system where tracking devices continuously generate events.

For example, if a vehicle is overspeeding, the device may send an overspeed event every second:

10:00:00 - Vehicle P123ABC Overspeeding  
10:00:01 - Vehicle P123ABC Overspeeding  
10:00:02 - Vehicle P123ABC Overspeeding  

We already store all raw events in an events/telemetry table. However, we also need an alerts table for actionable alerts that can be assigned to users.

I don't want to create thousands of alert records for the same continuous overspeeding incident. Ideally, these events should result in one alert:

Vehicle P123ABC - Overspeeding Status: OPEN First detected: 10:00:00 Last detected: 10:00:02

When the vehicle stops overspeeding, the alert can be closed. If it starts overspeeding again later, a new alert should be created.

The challenge is making the deduplication configurable because different alert types may have different rules.

For example:

Overspeeding → group while the vehicle remains above the speed threshold. Geofence violation → group by vehicle + geofence. Harsh braking → potentially treat each event as a separate alert. Some alerts → group events within a configurable time window.

We are considering using geohashing to group alerts, but I'm concerned about vehicles crossing geohash boundaries and unrelated incidents occurring in the same area.

What is a good general architecture/data model for configurable alert deduplication and grouping in a vehicle tracking system?

Should deduplication be based on:

Time windows? Vehicle state? Spatial proximity/geohash? A combination of these?

Are there established patterns for this problem?

advice postgresql database-design duplicates