# Defend a Redis Choice and Explain Database Index Trade-offs During a project deep dive, an interviewer asks why your system used Redis and whether the underlying database query should also have an index. Explain how you would justify the Redis decision, identify cases where it is the wrong tool, and reason about an index for a representative read path without assuming that either optimization is automatically beneficial. ### Constraints & Assumptions - The durable database remains the source of truth unless you explicitly choose another model. - Reads and writes both matter; improving one path may make the other more expensive. - Failures, stale values, and cache invalidation must be part of the design. ### Clarifying Questions to Ask - What workload or latency problem motivated Redis, and what evidence measured it? - Is Redis acting as a cache, queue, rate limiter, lock service, or primary data store? - Which query predicates, joins, sort order, selectivity, and update frequency define the database path? - What consistency and data-loss behavior can the product tolerate? ### Solving Hints Start from the workload and correctness contract. Compare the design with a simpler database-only option, then explain how measurement would validate the choice. ### What a Strong Answer Covers - A workload-specific reason for Redis, an ownership model, TTL/invalidation behavior, and failure handling. - Alternatives and reasons not to add another stateful dependency. - How B-tree-style indexes accelerate selected access paths and why column order matters. - Write amplification, storage, selectivity, covering indexes, and query-plan verification. - Metrics and experiments that can confirm or reject both optimizations. ### Follow-up Questions - How do you prevent a cache stampede after a popular key expires? - What happens when Redis is unavailable or contains stale data? - Why might a database ignore an index that appears to match a filter?