Skip to content
Bluetape4k docs1.11

Choosing Lettuce or Redisson

Latest stable Based on Bluetape4k release 1.11.0

Choose the abstraction, not the library name

Section titled “Choose the abstraction, not the library name”

Both clients connect to Redis, but their primary abstractions differ. Decide whether the application wants to compose Redis commands directly or use higher-level distributed objects with their own lifecycle.

RequirementLettuceRedisson
Sync/async commands and pipelinesPrimary pathAvailable, but not the focus of these helpers
Awaiting futures in coroutinesawaitSuspending, coroutine commandsRFuture adapters and suspended batch/transactions
Object codecsBinary, JSON, and Protobuf codecsJSON, Fory, and compressed codecs
Distributed locks, maps, and queuesDesign with raw commandsRedisson distributed objects
Stream consumer-group helpersBuild with command APIsValidated RStreamSupport helpers
Local cached mapsCheck the 1.11.0 loaded-map limitsNear Cache over RLocalCachedMap

Lettuce is a direct fit when Redis commands, pipelines, and explicit key design are central to the service. LettuceClients supplies client and command entry points, while RedisFutureSupport bridges futures to suspending calls.

A coroutine adapter does not turn the Redis operation into a cancellable transaction. Assign connection ownership, timeouts, and reconnect behavior first in Clients and connections.

Redisson fits distributed locks, maps, Streams, batch and transactions, or local cached maps. The redissonClient {} DSL reduces setup, but the application still owns and shuts down the returned client.

Near Cache is not just a faster-map switch. Pub/Sub invalidation, reconnect behavior, Codec compatibility, and cache names are operational contracts. See Local cached maps and invalidation.

A service may use Lettuce commands and a Redisson lock together. It then owns two client pools, retry policies, timeouts, and shutdown paths. If both clients share a keyspace, test the exact Codec bytes rather than assuming compatibility.

Cross-client failure fallback is risky. A command can succeed at the server before the first client reports a timeout, and the second client can execute it again. Do not add automatic fallback without idempotency and result-reconciliation rules.