Follow-up · The Nearest-Zone Answer, §06
§06 of The Nearest-Zone Answer called π-worker routing “the same primitive, not a separate design” — tag the zones fronting a π server, reuse the nearest-zone lookup unmodified. That held right up until the plan changed from one π server per customer to a fleet shared across 10+. This is what replaced it, and what building the replacement didn't require.
A dedicated worker table and a nearest-worker API — same formula, new subject.
Nothing calls this API for proxy assignment yet — it's a real, working answer you can query, not yet automatic.
§06's original plan — model each worker as a zone — didn't survive a shared fleet.
01
§06's answer was reasonable for what it assumed: one organization, one π server. A zone is inherently org-scoped, so modeling a π worker as a zone worked fine when each org had its own. It stops working the moment a worker is shared — Threatmatic-owned infrastructure, not customer data. Model it as a zone anyway and every org gets its own copy of the same physical box: one row per org, per worker. Provisioning has to fan out to all of them. So does every health-flag flip. The fan-out problem gets worse, not better, as the customer count grows — exactly the direction this was supposed to scale.
02
The underlying idea from §06 was right — pick the nearest one, using coordinates the device or the assignment step already has. What changed is what “the nearest one” is a row of.
Considered, reconsidered
An org-scoped zone row per worker per customer — N copies of the same physical box, N provisioning steps, N health flags to keep in sync.
What shipped
One pi_worker row per physical worker, full stop — no organizationId at all, because a shared worker was never customer data to begin with. Every org routes to it the same way.
03
The exact haversine query from §06, pointed at a different table:
GET /api/pi-workers/nearest?lat=<number>&lng=<number>&tag=<optional>
x-api-key: org_...| Param | Required | What it does |
|---|---|---|
lat / lng | Yes | Coordinates of whichever device is about to need a worker assigned. |
tag | No | Narrows the search to workers sharing this tag — same convention as zones. |
6371 * acos(
cos(radians(:lat)) * cos(radians(worker.latitude)) *
cos(radians(worker.longitude) - radians(:lng)) +
sin(radians(:lat)) * sin(radians(worker.latitude))
)Great-circle distance, filtered to healthy workers, ordered ascending, one row back.
{
"data": [{
"id": "01a3f2c1-...",
"title": "pi-worker-01",
"entryPoint": "10.86.0.94:8081",
"latitude": 33.6846,
"longitude": -117.8265,
"distanceKm": 4.2
}]
}04
The honest alternative to “pick the nearest one” is a live load balancer — something in front of the fleet, steering each connection in real time. That's a real piece of infrastructure. It didn't get built, and here's specifically why it didn't need to:
Each device is already spread across a real map. Point every one at whichever healthy worker is physically closest, and the fleet's total load ends up spread the same way — without anything coordinating it live. One assignment-time lookup does the job a traffic cop would otherwise have to.
05
Not automatic yet
This is a real, working lookup you can query today. The step that assigns a device its proxy worker doesn't call it yet — same gap §06 flagged for zones, not yet closed here either.
Genuinely out of scope
Where a device's own coordinates come from wasn't decided in this pass — on purpose. This piece is about the lookup, not the geolocation source feeding it.