A multi-tenant security-operations platform for an Israeli security-services company. Control rooms see every site, device, responder and open alert on one map, act on an alert without leaving it, and reach field teams by app, SMS, voice call and chat. I led the architecture and the hard performance and reliability work across seven repositories over almost three years.
The client secures residential communities, campuses and other sites, many of them at once. Alerts came from camera and video-management systems, responders were on the move, and residents and teams had to be reached by phone, SMS and messaging apps. Each site used its own tools, and nothing showed the whole operation in one place. An operator handling an alert needed to see who was close, what their status was and what the procedure said. They needed it in seconds, often in Hebrew and on a desk that stays open all shift.
The diagram is wider than the screen: swipe sideways to see all of it →
Every request is checked against the account → site → team hierarchy and a four-tier role model. Messaging and video-system sync run in separate workers, so a slow provider never holds up an operator's click.
The live alerts list is the most-read screen. Instead of joining six related tables on every request, a denormalised table holds only open alerts and is written in the same transaction as the alert. The trade-off is keeping two copies consistent, and we had to fix two gaps before it held in every flow.
List and map views call thin endpoints (10 of 35 site fields). Alert and event panels load a thin record first and open the heavier sections only when someone expands them. It means more endpoints to maintain, but every first paint is light.
SMS, voice-call and push fan-out to a whole site moved into a RabbitMQ task queue and a separate worker. The API answers straight away and providers can be slow or retried without blocking the operator. The cost is one more service to deploy and monitor.
A user can have a phone, a web tab and a control-center seat. The server decides which one is live, and clients handle three states: active, switched (in-app prompt) and logged out. A session is only torn down on a real 401 or 403, never on a network error.
Each repo carries project rules, a memory bank and skills for its patterns: controllers, storage, Redux API calls and permissions. Larger changes start as a written spec; the responder app archived 57 of them. Reviews got shorter and new team members got productive sooner. The cost is keeping the rules up to date.
Most of the measurable gains came from problems that only showed up with real sites, real alert volume and real phones. A selection:
As tenants grew, filtered lists and soft-deleted rows were scanned on every request.
Indexed every foreign key and every soft-delete flag, then kept adding covering indexes on hot filters (327 in total). A nightly job now refreshes statistics on the main and audit databases.
Each sync run pulled devices and alerts per site and then closed stale alerts row by row.
Bulk upserts, plus one stored procedure that closes all stale alerts and clears the cache in a single call. The worker locks one site at a time and runs a configurable number of sites in parallel.
Some list endpoints paged before sorting, so users saw an arbitrary slice of the data that only looked sorted.
Sorting moved ahead of paging in the shared list pattern, with more sort fields and documentation, and the pattern became a repo skill so new endpoints follow it.
Sending to a whole site ran the SMS, voice-call and push sends inside the API request.
All three now go through the task queue and a dedicated messaging worker.
It eager-loaded site, control room, device, type, readiness state and creator for every row, on every refresh.
Added a cache table of open alerts only, read with no joins. I found and fixed two consistency gaps: one update path skipped the cache, and the control-room field was never filled.
Native background location on the phones hit a 401 deadlock, posted duplicates and stopped when the app was killed.
Native location services on iOS and Android keep their own token store and send queue. The queue is flushed when the app opens, and there is one refresh path.
The refresh layer treated a DNS failure like a rejected token, so responders were sent back to OTP login.
Failures are now classified where they happen. The refresh makes 3 attempts with 400 → 800 ms backoff, and only a real 401 or 403 ends the session.
Opening an alert or event panel fetched everything at once, and permission checks used a linear search through configuration arrays on every table row.
The panel fetches a thin record first and loads its sections lazily. Hot lookups use a reference-cached id → entity index. Map routes are code-split.
1 table, no joins, open alerts only
10 fields per site; one call for up to 1,000 sites
one stored-procedure call per run, sites in parallel
queued to a worker; API returns in ≈0.3 s
3 attempts with backoff; session kept, offline banner shown
queued locally (location: up to 500 points, 4 h TTL) and sent in bulk on reconnect
push a version tag → Docker image to the registry (4 services), ≈10 min
Numbers with ≈ are estimates. The rest are counted from the code and the commit history.
Free scoping call · 30 minutes · No commitment
Write a few lines: the process or system, what hurts today (time, errors, cost or an AI pilot that stalled) and who uses it. After a short call you get a written plan and a fixed quote within ≈3 days.
Opens a pre-filled email · reply within one business day
The model reads. The code counts.
All projects