Difficulty Medium→HardRead ~25 minMaster 1–2 weeksLevels Mid–Staff
Prerequisites
Basic HTTP and databases One message queue exposure helps Interviewers love comparisons because they force trade-offs , not memorized
definitions. For each pair: say when to use A, when to use B, and when neither.
Kafka vs RabbitMQ
Difficulty HardRead ~8 minMaster 3–5 daysLevels Senior
Interview cheat comparison
Dimension Kafka RabbitMQ
Model Durable partitioned log Smart broker queues / exchanges Ordering Per partition key Per queue (with caveats) Replay Native via offsets / retention Not the primary design Routing Coarse (topics/keys) Rich exchanges/bindings Throughput Very high sequential I/O Lower; flexible patterns Use when Event streaming, analytics, replay Task queues, complex routing, RPC-ish
Expected interview answer
Kafka is a distributed commit log for high-throughput streams and replay. RabbitMQ is a message broker optimized for flexible routing and work queues. Choose Kafka for event sourcing/stream processing; Rabbit for task distribution with rich routing. Never promise global order on Kafka.
Common mistakes
Calling Kafka a 'queue' only Using Rabbit for multi-day replay lakes Ignoring consumer group rebalance costs Production
LinkedIn created Kafka for activity streams Many Uber/Netflix pipelines are log-centric Rabbit remains common for background jobs in Rails/JVM apps Follow-ups: Exactly-once? Poison messages? Multi-region mirror?
Redis vs Memcached
Difficulty MediumRead ~6 minMaster 2–3 daysLevels Mid–Senior
Dimension Redis Memcached
Data structures Rich (strings, ZSET, hashes, streams) Simple key/value blobs Persistence Optional AOF/RDB Ephemeral Clustering Redis Cluster Client-side sharding historically Use when Counters, leaderboards, locks, queues, cache Simple hot-blob cache at huge QPS
Expected answer
Memcached is a fast ephemeral slab allocator for opaque values. Redis is a data-structure server that can also cache. Prefer Memcached for simple massive get/set caches; Redis when you need atomic structures, TTLs with logic, or persistence.
Production
Facebook historic Memcached scale GitHub/Twitter Redis use cases AWS ElastiCache offers both REST vs GraphQL
Difficulty MediumRead ~7 minMaster 2–4 daysLevels Mid–Senior
Dimension REST GraphQL
Contract Resources + verbs Schema + queries/mutations Over/under fetch Common without BFF Client specifies fields Caching HTTP cache-friendly Harder at edge; need persisted queries Complexity Many endpoints Resolver/N+1 risks Use when Public APIs, simple CRUD, cacheable GETs BFF for varied clients, graph-shaped data
Expected answer
REST maps cleanly to HTTP semantics and CDNs. GraphQL reduces round-trips for product UIs but shifts complexity to the server (authz per field, query cost limits, N+1). Many companies use both: REST/gRPC internally, GraphQL at the BFF edge.
Common mistakes
No query depth/cost limits in GraphQL Ignoring HTTP caching benefits of REST Equating GraphQL with 'no versioning needed' Production
GitHub public GraphQL API Netflix/Shopify BFF patterns Twitter/X and many mobile BFFs SQL vs NoSQL (interview framing)
Difficulty MediumRead ~6 minMaster 3–5 daysLevels Mid–Senior
See also the book chapter SQL vs NoSQL . In interviews, lead with
access patterns , transactions, and query flexibility — not hype.
Expected answer
SQL when relations + multi-row transactions matter. NoSQL when partition key access dominates and you need horizontal scale with simpler transactions. Secondary access patterns need indexes, search, or carefully designed dual writes.
Strong consistency vs availability (CAP lite)
Ticket booking and payments need strong inventory/ledger correctness. Feeds and likes often
choose availability + eventual consistency. Say the product consequence out loud — that is the
interview.