Single-leader and multi-leader replication both have someone in charge of each write. Leaderless replication drops that idea entirely. There's no leader to fail over, no leader to elect. A write goes to several replicas at once, a read asks several replicas at once, and simple arithmetic about overlaps decides whether the read sees the write.
This is the design Amazon described in its 2007 Dynamo paper, and it lives on in Cassandra, ScyllaDB and Riak. It's built for workloads where staying writable through failures matters more than anything else, like a shopping cart that must never refuse an "add item".
No leader at all
Every piece of data is stored on N replicas, typically 3. To write, the client (or a coordinator node acting for it) sends the write to all N replicas at once, and treats it as successful once W of them confirm. To read, it asks replicas and waits for R of them to answer, then uses the newest version among the answers.
%% caption: N = 3, W = 2. Two confirmations are enough, so the write succeeds even though replica C is down. sequenceDiagram autonumber participant CO as Coordinator participant A as Replica A participant B as Replica B participant RC as Replica C CO->>A: write v7 CO->>B: write v7 CO-xRC: write v7, replica C is down A-->>CO: ok B-->>CO: ok Note over CO: 2 of 3 confirmed, so success
Notice what didn't happen. Nobody detected that C was down, voted, or promoted anything. The write simply needed 2 of 3, and got them. When a node dies in a leaderless system, there's no failover at all. That's the main attraction.