Skip to content

Glossary

Terminology definitions used throughout FrogDB documentation.


A thread-local partition within a single FrogDB node. Each internal shard has its own:

  • HashMap (key-value store)
  • Memory budget
  • Expiry index
  • WAL writer

Keys are assigned to internal shards via: internal_shard = hash(key) % num_shards

Not to be confused with: Hash slot (cluster-level distribution).

See: storage.md, concurrency.md

A logical partition (0-16383) for distributing data across nodes in cluster mode. Redis Cluster compatible.

Keys are assigned to slots via: slot = CRC16(key) % 16384

Relationship: key -> hash_slot(key) -> node -> internal_shard(key)

See: storage.md, clustering.md

TermScopeAlgorithmRangePurpose
Hash SlotCluster (multi-node)CRC160-16383Which node owns a key
Internal ShardNode (multi-thread)xxhash640 to num_cpusWhich thread processes a key

Key distinctions:

  • Transactions require same internal shard (all keys on same thread)
  • Multi-key commands (MGET/MSET) check hash slots by default
  • allow-cross-slot-standalone relaxes slot checks, but not shard requirements for transactions
  • -CROSSSLOT error uses “slot” terminology for Redis compatibility

A {tag} syntax in key names that controls hash slot assignment. Only the content between the first { and } is hashed.

Example: {user:123}:profile and {user:123}:sessions hash to the same slot.

Purpose: Enables multi-key operations (MGET, transactions) on related keys.

See: storage.md

Terminology Note: Cross-Shard vs Cross-Slot

Section titled “Terminology Note: Cross-Shard vs Cross-Slot”
TermLevelContext
Hash slotCluster16,384 slots for cluster routing
Internal shardNodeThread-local partitions within a node

Error codes:

  • -CROSSSLOT is always used (Redis compatibility), even for internal shard violations

An external control plane that manages FrogDB cluster topology. Responsibilities include:

  • Node health monitoring
  • Failover decisions
  • Slot migration coordination
  • Configuration distribution

FrogDB uses an orchestrated model (like DragonflyDB) rather than gossip protocol (like Redis Cluster).

See: clustering.md

A synchronization mechanism for coordinating multi-shard operations without traditional locks. Ensures atomicity across shards while maintaining the shared-nothing architecture.

See: vll.md


A sequential log of all write operations, persisted to RocksDB. Enables durability and crash recovery.

Modes:

  • async: WAL writes queued, fsync by OS
  • periodic: fsync every N milliseconds (default: 1000ms)
  • sync: fsync after every write

See: persistence.md

A point-in-time capture of all key-value data, stored as an RDB-compatible file or RocksDB checkpoint.

FrogDB approach: Epoch-based (logical point-in-time) rather than fork-based (physical point-in-time).

A logical timestamp used for snapshot coordination. When a snapshot begins:

  1. Current epoch is recorded
  2. All shards iterate keys, writing values from epoch start
  3. Concurrent writes go to WAL (not snapshot)

A technique where data is copied only when modified. FrogDB uses explicit COW buffers for forkless snapshots instead of Redis’s fork-based approach.


The wire protocol used by Redis and compatible systems.

VersionFeatures
RESP2Simple strings, errors, integers, bulk strings, arrays
RESP3Adds maps, sets, booleans, doubles, push messages, attributes

See: protocol.md

An error returned when a multi-key operation references keys in different hash slots.

-CROSSSLOT Keys in request don't hash to the same slot

Solution: Use hash tags to colocate related keys.

ErrorContextMeaning
-CROSSSLOTMulti-key ops, transactions, LuaKeys don’t hash to same slot
-MOVED slot host:portCluster modeKey’s slot is on different node
-ASK slot host:portCluster migrationKey is being migrated
-WRONGTYPEType mismatchOperation against wrong data type
-OOMMemory limitOut of memory, writes rejected
-TIMEOUTVLL queueOperation timed out waiting for locks
-NOSCRIPTLua scriptingScript not found in cache
-BUSYLua scriptingScript exceeded time limit

Note: FrogDB uses -CROSSSLOT (not -CROSSSHARD) for Redis compatibility, even when the underlying check is at the internal shard level.


An eviction policy that removes keys based on last access time. FrogDB uses sampling LRU (like Redis) rather than exact LRU.

An eviction policy that removes keys based on access frequency. Uses a logarithmic counter with decay.

A buffer of eviction candidates maintained across sampling rounds. Improves eviction accuracy by accumulating worst candidates over time.


A segment-based hash table used by DragonflyDB. 30-60% more memory efficient than Redis. FrogDB uses griddle::HashMap currently; Dashtable is a future consideration.

A Rust crate providing incremental-resize HashMap. Spreads resize cost across inserts to avoid latency spikes.

See: storage.md


Redis transaction commands. MULTI starts queuing, EXEC executes atomically.

FrogDB guarantees:

  • Execution atomicity: Yes (no interleaving)
  • Durability: Configurable (depends on sync mode)
  • Rollback: No (partial failures don’t undo prior commands)

Optimistic locking command. Monitors keys for changes; EXEC fails if watched keys were modified.

Sending multiple commands without waiting for responses. Reduces round-trip latency. Not transactional; commands may interleave with other clients.


The node accepting writes for a set of hash slots. Also called “master” in Redis terminology.

A node receiving replicated data from a primary. Serves read traffic and can be promoted on failover.

Partial synchronization protocol for replication. Allows replicas to catch up from replication backlog without full sync.

A circular buffer of recent write operations. Enables PSYNC when a replica reconnects after brief disconnection.


The latency experienced by the slowest requests (e.g., p99, p999). FrogDB optimizes via shared-nothing architecture, incremental resize (griddle), and sampling eviction.

Operations per second. FrogDB targets high throughput via thread-per-core model, connection pinning, and batched WAL writes.


AbbrevMeaning
AOFAppend-Only File (Redis persistence format)
RDBRedis Database (snapshot format)
TTLTime To Live (key expiration)
OOMOut Of Memory
ACLAccess Control List
TLSTransport Layer Security
FIFOFirst In, First Out
CRC16Cyclic Redundancy Check (16-bit)