Gbluetape4k Leader
Detailed 1-leader model 한국어

Visual companion · Release 0.4.0 · Redis Lettuce

From 1 → N
leader slots.

LeaderGroupElector keeps the token-and-lease model and changes one boundary: up to maxLeaders candidates may own independent slots.

Bounded slot admission

Every active slot has its own token and TTL.

Ready.
LeaderElector1 lock → 1
→
LeaderGroupElector1 group → N occupied slots
Candidates
Redis slot-token group
activeCount0
availableSlots0
isFullfalse
tick 0waitTime 2minLeaseTime 1group autoExtend not available

Latest slot events

TickCandidateOperation TokenTTLOutcome

Step 01 · Delta model

Same lease, bounded multiplicity

The detailed LeaderElector companion explains acquire, token, TTL, expiry, and release. Here each admitted candidate receives an independent slot token.

One logical group

All candidates use the same lockName.

N independent tokens

At most maxLeaders tokens remain active.

Same skip contract

A full group can produce LeaderRunResult.Skipped.

No business partition

A token is ownership evidence, not a stable shard number.

Step 02 · Settings

Capacity is the additional setting

maxLeaders

Maximum concurrent slot owners. Direct options accept values greater than or equal to 1.

Candidate count

Use more candidates than slots to make saturation visible.

waitTime / leaseTime

Keep their single-leader meanings for each slot attempt and TTL.

minLeaseTime

Keeps a successful slot for a minimum duration after fast completion.

No group autoExtend option

Explicit active-lock extension exists as an advanced contract, but this delta companion does not animate it.

Step 03 · Direct API

Run work only after slot admission

val group = connection.leaderGroupElection(
    LeaderGroupElectionOptions(
        maxLeaders = 3,
        waitTime = 500.milliseconds,
        leaseTime = 10.seconds,
    )
)
val value = group.runIfLeader("thumbnail-workers") {
    processNextClaimedBatch()
}

val state: LeaderGroupState =
    group.state("thumbnail-workers")
Claim before processing.

processNextClaimedBatch() still needs a queue or claim table. Slot admission alone does not assign unique work.

Step 04 · Spring Boot

Annotation validation is stricter

@LeaderGroupElection(
    name = "thumbnail-workers",
    maxLeaders = 3,
    waitTime = "PT0.5S",
    leaseTime = "PT10S",
)
fun processNextClaimedBatch(): BatchSummary? =
    service.processNextClaimedBatch()

While direct LeaderGroupElectionOptions accepts maxLeaders >= 1, Spring startup validation requires @LeaderGroupElection.maxLeaders > 1 and directs a single leader to @LeaderElection.

Return types

Synchronous, suspend, and Mono are supported. Flux and Kotlin Flow are rejected because per-slot stream lease extension is undefined.

Step 05 · Failure and recovery

Capacity returns after release or expiry

Run saturation to see a contender skip. Run expiry to see one token disappear and a later candidate enter the newly available capacity with a new token.

Slot IDs are not work IDs.

Do not turn a rendered slot position into a business partition. Use application-owned work distribution.

Release evidence

Pinned to 0.4.0