Client-side cluster support in Redis - Time & Space Complexity
When using Redis with client-side cluster support, the client decides which server to talk to for each request.
We want to understand how the time to find the right server grows as the number of keys or servers increases.
Analyze the time complexity of this simplified client-side cluster key lookup:
// Assume slots is a map from slot number to server
function getServerForKey(key) {
const slot = hash(key) % totalSlots;
const server = slots[slot];
return server;
}
This code finds the server by hashing the key and looking up the slot in a map.
Look for repeated steps that affect performance.
- Primary operation: Computing the hash of the key and accessing the slot map.
- How many times: Once per key lookup; no loops inside this function.
The time to find the server depends on the hash and a direct map lookup, which stays quick even if the number of keys grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 keys | About 2 operations per lookup (hash + map access) |
| 100 keys | Still about 2 operations per lookup |
| 1000 keys | Still about 2 operations per lookup |
Pattern observation: The lookup time stays almost the same no matter how many keys there are.
Time Complexity: O(1)
This means the time to find the right server does not grow as you add more keys; it stays constant.
[X] Wrong: "Looking up the server will take longer as the number of keys grows because there are more keys to check."
[OK] Correct: The client uses a hash and direct slot map, so it does not check keys one by one. It jumps straight to the right server.
Understanding how client-side cluster support keeps lookups fast helps you explain efficient distributed systems in interviews.
What if the slot map was stored as a list instead of a map? How would the time complexity change?