Explain Redis design, persistence, and scaling

Quick Overview

Explain Redis design, persistence, and scaling evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Explain Redis design, persistence, and scaling

Company: TikTok

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Explain Redis core data structures (strings, lists, sets, sorted sets, hashes, streams) and typical time/space characteristics. Compare RDB and AOF persistence, including durability, performance, and recovery trade-offs. Describe eviction policies and TTL behavior under memory pressure. Explain replication, Sentinel failover, and Cluster sharding. Discuss transactions, Lua scripting, and pitfalls of distributed locks (e.g., clock skew, fencing tokens). Outline strategies to prevent cache stampede and handle hotspot keys.

Quick Answer: Explain Redis design, persistence, and scaling evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/TikTok
TikTok logo
TikTok
Jul 15, 2025, 12:00 AM
hardSoftware EngineerTechnical ScreenSystem Design
5
0

Explain Redis design, persistence, and scaling

Redis: Data Structures, Persistence, Eviction, High Availability, and Operational Pitfalls

Context: You are designing a latency-critical backend that relies on Redis both as a cache and as a data store. Explain the following topics to demonstrate practical, production-oriented understanding.

  1. Core data structures
    • Strings, Lists, Sets, Sorted Sets (ZSET), Hashes, Streams
    • Typical time and space characteristics
  2. Persistence mechanisms
    • Compare RDB and AOF: durability, performance, recovery trade-offs
  3. Memory pressure
    • Eviction policies and TTL behavior under memory pressure
  4. High availability and scaling
    • Replication, Sentinel failover, and Cluster sharding
  5. Programmatic semantics
    • Transactions, Lua scripting
  6. Distributed locks
    • Pitfalls (e.g., clock skew, process pauses, network partitions) and fencing tokens
  7. Cache reliability at scale
    • Strategies to prevent cache stampede and handle hotspot keys

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More TikTok•More Software Engineer•TikTok Software Engineer•TikTok System Design•Software Engineer System Design