This guide came out of a single, deep preparation session for a senior backend engineering interview. The topic was a game leaderboard — something that looks simple on the surface but hides a surprising amount of distributed systems complexity underneath.

What emerged wasn't just a leaderboard design. It was a way of thinking about system design problems: how to ask the right clarifying questions, how to scope complexity, how to move through a 45-minute interview without getting lost.

There are two things you can take from this guide. The leaderboard design itself — Redis sorted sets, sharding, approximate ranking, fan-out patterns. And the meta-skills — how to structure an interview, how to use clarification questions as a steering tool, how to demonstrate senior judgment under time pressure.

SW
SansWord LinkedIn →

SansWord came into this session already knowing more than they realized. The questions were sharp from the start — not "how does Redis work" but "is this actually a top-k problem, or is it something harder?" That's the instinct of someone who has built real systems and knows where the complexity usually hides.

What stood out most was the habit of stopping to verify understanding before moving on. Not nodding and continuing, but actually restating — "let me describe this in my own words and check if I'm right." That habit is rare, and it's why the concepts in this guide are explained the way they are: not as facts to memorize, but as reasoning to reconstruct.

The guide exists because SansWord is part of a system design book club in the Bay Area and wanted to bring the session back to the group. That instinct — to learn in public, to bring others along — is probably the most useful thing here, and the reason this is a guide rather than just notes.

What's in this guide

Part 1

Leaderboard System Design

From a simple Redis sorted set to a sharded, approximate-ranking system serving 100M players. Covers global, regional, friend, and guild leaderboards.

→
Part 2

System Design Interview Skills

How to structure 45 minutes, use clarification questions as a steering tool, present tradeoffs, and push back on requirements like a senior engineer.

→
Part 3

Mock Interview Examples

Two formats: a full end-to-end example showing ideal structure and answers, and a speed round showing how to stay concise under pressure.

→
Part 4

Using AI to Prepare

How this entire guide was built through a conversation with Claude — and how you can run your own preparation session using the same approach.

→

How to use this guide

If you're preparing for a system design interview, start with Interview Skills to understand the meta-structure, then read Leaderboard Design as a worked example. Use the Mock Interview as a reference for what good answers sound like, then run your own session using the AI Prep approach.

If you're here to learn distributed systems concepts, Leaderboard Design is a self-contained deep dive. The concepts — Redis sorted sets, range-based sharding, approximate ranking, fan-out patterns — apply well beyond leaderboards.

Sections marked fundamental are accessible to anyone with basic backend knowledge. Sections marked advanced assume comfort with distributed systems concepts.

Prerequisites

To get the most out of this guide, you should already be comfortable with the following. If any of these feel shaky, spend time on them first — the advanced concepts won't stick without a solid foundation.

Data structures. Sorted structures and why they exist, binary search intuition (O(log N)), hash maps for O(1) lookup, heaps for top-k problems.

Complexity. O(1), O(log N), O(N), O(N log N) — and the instinct that O(N) is a red flag at 100M scale.

Databases. Why PostgreSQL is a source of truth (ACID, durability), what a cache is and why it's never authoritative, read vs write patterns and why they scale differently.

Distributed systems basics. CAP theorem intuitively, horizontal vs vertical scaling, sharding concepts, replication (primary + replicas), eventual consistency.

Message queues. Producer/consumer pattern, at-least-once delivery, why Kafka is replayable and why that matters for recovery.

API design. REST conventions, pagination (offset vs cursor), rate limiting.