Hello Interview Concepts

Question 1

What is Redis?

Answer 1

• Single-threaded, in-memory, data structure server.
• Designed for speed (sub-millisecond latencies) and simplicity.

Question 2

Redis core concept and Why Redis?

Answer 2

Single-threaded: Requests are processed sequentially, making ordering and concurrency handling simple.

In-memory: Fast, but data is not durable unless explicitly configured.

Data structures: Supports more than just key-value:
Strings, Hashes, Lists, Sets, Sorted Sets
Streams, Geospatial indexes, HyperLogLogs, Bloom filters

Versatile: works as cache, pub-sub system, rate limiter, leaderboard, event stream processor, geo-spatial indexing.

Can handle 100k - 1M TPS write / sec and read latency in microsecond range

Question 3

Redis for Rate Limiting

Answer 3

Uses INCR and EXPIRE to allow a set number of actions per time unit.
Simple but effective; not fair or ordered, so starvation can occur.
More advanced implementations include leaky bucket, token bucket, etc.

⚖️ Not fair or ordered
The limiter doesn’t keep track of who came first or who’s been waiting.
There’s no queue or fairness logic — just a counter.
So if 10 clients try to access at the same time, whichever 5 hit Redis first win, the rest get denied.

🚫 Starvation can occur
A client or service might consistently get denied, even if it’s retrying politely.
If one instance is faster or closer to Redis, it might always get in first.
Others might never get a chance, even though they’re making legitimate requests.

🧠 Alternatives for fairness
Use token bucket or leaky bucket algorithms.
Implement a distributed queue.
Add backoff and retry with jitter to give others a chance.

Question 3

Redis as Cache

Answer 3

• Reduces load on backend databases.
• Use EXPIRE for TTL or configure LRU eviction when memory is full.
• Watch out for hot key issues; mitigate by appending random suffixes to keys.

Question 4

Redis as streams

Answer 4

Redis Streams are append-only logs with timestamped entries.
Use Consumer Groups for parallel and fault-tolerant processing.
Guarantees at-least-once delivery (not exactly-once).
Purpose: Distribute tasks to workers in an ordered, fault-tolerant way.

Message is stored in the stream (durable until deleted).
Supports Consumer Groups: allows multiple workers to coordinate message processing.
If a consumer fails, another one can claim the unprocessed message.
⚠️ Might deliver the same message more than once → duplicates possible, but messages aren’t lost.
Great for: job queues, async processing, audit logs, etc.

Question 5

Redis for leaderboards

Answer 5

Use Sorted Sets (ZADD, ZRANGE) for ranking items.
Good for “top-N” style problems (e.g., top 5 most liked tweets).
Watch out for single-node limits when ranking across large datasets.

Question 6

Redis for Geospatial Indexing

Answer 6

Add items via longitude/latitude to build fast proximity searches.
Internally uses geohashing + sorted sets.
Not ideal if location updates are infrequent or data is static.

Question 7

Redis as Pub/Sub

Answer 7

Lightweight messaging system for inter-service communication.
At-most-once delivery—messages may be dropped.
Good for real-time chat or alerts, not for guaranteed delivery scenarios.
Purpose: Real-time communication between services.

Redis Pub/Sub – At-most-once delivery
Message is transient — not stored anywhere.
If no subscriber is listening at the moment the message is published → it’s lost.
No retries, no persistence, no acknowledgment.
Fast and lightweight — but no delivery guarantees.
Great for: real-time messaging, chat apps, notifications where some loss is okay.