The Symptoms: Project Management Drift and Stale Locks

Every Monday morning our Project Management board tells a different story than the work on the ground. One team picks up a task, another team edits the same task, and the lock management layer in the old task service quietly expires at the worst possible moment. The result is duplicated effort, missing updates, and a recurring argument about which spreadsheet is the real source of truth. The tasks of the teams are not the problem. The problem is that our lock state is spread across a relational table, a browser cache, and a cron job that nobody wants to own.

We decided to fix the foundation instead of adding more process. The new design treats every task lock as an event with a verifiable lifecycle. It uses apple hardware at the edge, wired ethernet for predictable timing, a WebSocket gateway for live updates, and a message broker for durable fan-out. The first diagram shows the flow.

flowchart TD A[Apple Ethernet Edge] --> B[WebSocket Gateway] B --> C[Event Bus] C --> D[Quantum Lock Service] C --> E[Project Management Task ORM] D --> F[Message Broker] E --> F F --> G[Dockerized Task Workers] G --> H[Team Task Views] D --> I[Lock Audit Ledger] C --> J[Dead Letter Queue]

Apple Ethernet Edge Nodes as the Source of Truth

Each office now runs a small apple Mac mini as an edge coordinator. The nodes are connected by ethernet, not Wi-Fi, because task lock heartbeats deserve stable latency. The edge node emits a task heartbeat every two seconds and signs it with an internal key. If a heartbeat is missing, the lock management service starts a lease review. This gives us a crisp boundary between the physical office and the central Project Management service.

The edge nodes are boring on purpose. They do one thing: turn local task activity into events. We do not let them talk to the database directly. They publish to the event-driven backbone and forget about it. The backbone handles the rest.

The Event-Driven Backbone and WebSocket Gateway

Every task action becomes an event: task claimed, task renewed, task released, lock revoked, and task comment added. A WebSocket gateway keeps the browser views live without polling. The gateway does not own state. It subscribes to the message broker and forwards only the events a user is allowed to see.

The message broker is the spine. We use separate topics for lock events, task events, and audit events. Consumers are idempotent and replayable. If a consumer falls behind, it catches up from the broker instead of hammering the Project Management API. This is the event-driven model we wanted: facts first, views second, spreadsheets never.

Quantum Lock Management for the Tasks of the Teams

Lock management now runs as its own service. When a task needs to be claimed, the service asks a quantum random number generator for a lease nonce. The nonce is mixed with the task ID, the team ID, and the edge heartbeat. The resulting lock token is easy to verify and hard to guess. We do not claim that the quantum source makes the business logic magical. We claim that it gives every lease a high-entropy identity, which makes audit correlation cleaner and removes accidental token reuse.

The service holds active leases in memory for speed and writes every transition to the message broker. A lease has a short ttl and must be renewed by the owning worker. If the worker disappears, the edge heartbeat stops and the lease enters review. The tasks of the teams stay protected without a central row lock held open for the length of a lunch break.

Persistence Through an ORM and Audit Ledger

We persist task and lock metadata through an ORM. The ORM gives us explicit mappings, migrations, and a single place to reason about relations. Every lock transition is also appended to an audit ledger. The ledger is append-only and keyed by the quantum lease nonce. The ORM is not the lock authority. The ORM is the durable record of what the lock authority decided.

This separation matters. Read models can be rebuilt from the broker and the ledger. The ORM stays clean and queryable for reporting. When someone asks who held a task at 14:32, we can answer from the ledger without reconstructing history from application logs.

Dockerized Task Workers

Each task domain runs in its own docker container. The containers are small, stateless, and subscribed to specific broker topics. A worker claims a lease, performs the task operation, and releases the lease through the lock management service. If a worker crashes, docker restarts it and the broker redelivers the event. The lease review path handles the gap.

We use one deployment per domain, not one giant worker. That keeps the blast radius of a bad deploy small. It also lets us scale the noisiest tasks of the teams without scaling everything else. The containers share no local state. The broker is the queue and the audit ledger is the memory.

Operational Rituals and Rollout

We rolled this out team by team. Each team got a dashboard for lock latency, lease renewals, dead-letter counts, and edge heartbeat health. Project Management now has a live view of lock ownership instead of a nightly reconciliation report. The first week produced more alerts than we expected, mostly because the dead-letter queue was doing its job and surfacing malformed events.

We are now standardizing on this pattern for every shared task workflow. The combination of apple edge nodes, ethernet heartbeats, event-driven messaging, a WebSocket gateway, quantum lease nonces, docker workers, ORM persistence, and a message broker gives us one understandable path for lock management. The tasks of the teams move faster because the system tells the truth about who holds what. Project Management finally has a board that matches reality.