I build backends from the wire up — binary device protocols at one end, API contracts at the other, and fifty-six million events a day moving between them.

Fleet reports cover long date ranges over high-volume telemetry. Generate one inside a request and it times out. Generate several at once and the API stops answering anyone.

The design is a straight producer/consumer split. The reporting service owns report definitions, timezone-aware cron scheduling and enqueueing; a dedicated worker consumes a BullMQ queue, renders the artefact — xlsx via exceljs, PDF via pdf-lib — uploads it to S3 and emails a link. The request returns immediately; the file arrives when it is ready.

Two things that sound like details and are not. The queue is also the load-levelling mechanism — a customer scheduling twelve monthly reports for the first of the month is a spike you want absorbed and worked off at the pace the worker sets, not served all at once. And every report type needs its own column configuration, because a temperature report and a speeding report share almost nothing except the vehicle it happened to.

Nine configurable alarm types — parking, idling, engine, speed, temperature, seatbelt, geofence duration, geofence speed, panic — each evaluated against a live telemetry stream, each respecting a per-device activation schedule, each routed over RabbitMQ to the notification service for delivery by push, email or SMS.

Detection was never the hard part. Noise was. An alarm engine that fires correctly but constantly is worse than no alarm engine, because operators stop reading the alerts and then miss the one that mattered. Most of the real work went into activation-time validation, duty-hour windows and threshold tuning — deciding that a temperature alarm on a vehicle parked and unplugged overnight is not an event.

Turf.js supplies the geometry — is this point inside that polygon — while entry, exit and dwell are state layered on top of it. I built that logic out as standalone spikes before it went near the service, which is unusual for me and was correct here.

A nightly mongodump of the whole database is the obvious thing to write and the wrong thing to run. The volume was lopsided: the bulk telemetry was almost all of the database on disk, while the records you actually need to bring a customer back were a small fraction of it — and the expensive half barely changed shape from one night to the next.

So the job runs two cadences out of one cron entry. The operational data is dumped nightly; the bulk telemetry is dumped on a much longer cycle, and only when the archive for that period is missing, which makes it safe to re-run — running it twice in a day overwrites the nightly archive and skips the expensive one. Each archive is gzipped on the way out of mongodump, written to a .part file, and renamed only after the dump exits clean and the file is non-empty. An interrupted run leaves no artefact that could be mistaken for a good backup. The finished archive is copied to S3, and the retention window is enforced in both places rather than only on the box.

The detail I would defend in review is how it prunes: on the date parsed out of the filename, never on mtime. Modification time is not a property of a backup — a plain cp resets it, so does rsync without -t, so does restoring from another tool — so a pruner that trusts it either keeps archives forever or deletes a fresh one, and you find out which during an incident. Beyond that it is unglamorous on purpose: POSIX sh rather than bash, so it does not depend on bash being installed (it does lean on GNU date for the cut-off arithmetic), set -eu so any failed step stops the run, and logging to both stdout and a file, so whatever collects cron output sees each run while the full history stays on disk.

JWTs are stateless. That is the feature, and it is exactly why revoking one is awkward: a signed token stays valid until it expires whether or not you still want it to be.

I built session management on Redis-backed session caching, which buys revocation at the cost of reintroducing the state JWTs were chosen to avoid. That trade is the whole design decision, and I would make it again: every request now pays a Redis lookup. The alternatives are short-lived access tokens with refresh, which leaves a revoked token usable until it expires, or a blocklist, which is a session store wearing a hat. What it enabled: revoke one session, revoke all sessions except the current one, list active sessions per user, and an administrative path to clear every cached session for an account.

Around it sits the full user lifecycle — an admin invites a user, an invitation email goes out, the user sets a password, gets auto-logged-in and verified, and has 2FA enforced if their organisation requires it. Deactivation blocks login without deleting the account, and deleted users are soft-deleted so they disappear from queries without breaking every historical record that referenced them.