Resilience
High availability and business continuity
The scanning platform is built to survive interruption. When a component goes silent its work is taken over, the queue keeps every job, and each handover is recorded.
How leader election works
One node runs the watchdog duties of the cluster, and that node is chosen through an advisory lock in PostgreSQL. If the leader fails the lock is released and the next node takes over. You do not install a separate coordination cluster, so the number of systems your team has to operate stays the same.
Why work is not lost
Every job is written to a queue and claimed by a worker under a lock. If the worker goes silent the lock expires and the job is handed to another worker. When the earlier owner returns late with a result, the version stamp no longer matches and the result is rejected, so the same job is never counted twice. A job that still cannot be completed after repeated attempts moves to a separate queue for review.
None of this behaviour requires configuration. The cluster runs this way from the first boot.
Common questions
Do we configure anything for high availability?
No. Leader election runs over PostgreSQL's advisory locks, no external coordination cluster is added, and the number of systems to operate does not grow.
Is a half-finished job lost when a worker dies?
No. The lock drops and the job is redistributed. A late result from the old owner fails the version check and is rejected, so no job is counted twice.
What happens when the leader goes down?
The next node takes over. The lock is released, the watchdog duties continue and the handover itself is recorded.