Why this guide exists
System Design interviews are not just about naming technologies. They test whether you can explain trade-offs, choose the right tool for the constraint, and communicate clearly under pressure.
At IT Career Gym, we see strong engineers freeze because they know the concept but cannot structure the answer. This guide gives you a definition, a whiteboard-friendly table or flow, a 30-second answer, and a trap that makes candidates sound junior.
Use it as a theory refresher or a mock script. Open Find a partner and quizzes while you read — the 30-second lines are meant to be said out loud, not highlighted.
Disclaimer. This is vocabulary for trade-offs, not a design of one production system. Constraints win. The gym does not promise an offer.
1. Replication
Definition. Keeping multiple copies of the same data on different nodes.
Why it matters: availability, read scaling, geo-distribution, disaster tolerance.
-
Write path
Client / app → primary DB.
-
Copies
Primary → replica 1 and replica 2.
-
Reads
Read traffic can land on replicas. Failover is the other job.
| Goal | How replication helps | Trade-off |
|---|---|---|
| Availability | Replica can take over if primary fails | Failover complexity |
| Read scalability | Reads spread across replicas | Replica lag |
| Geo-distribution | Data closer to users | Cross-region consistency issues |
| Durability | More copies exist | Storage and ops cost |
“Replication keeps multiple copies of data for availability and read scaling. The primary handles writes, and replicas serve reads or stand by for failover. The main trade-off is consistency versus latency, especially with asynchronous replication.”
Common trap. Saying replication is the same as backup. It is not. A bad DELETE can replicate everywhere.
2. Sharding
Definition. Horizontal partitioning: one large dataset split into independent shards, usually across servers.
-
Router
Application → shard router.
-
Keyspace
Shard A: users A–H. Shard B: I–P. Shard C: Q–Z.
| Aspect | Replication | Sharding |
|---|---|---|
| Purpose | Copies of the same data | Split different data |
| Main benefit | Availability, read scaling | Write scaling, smaller datasets |
| Query impact | Reads can go to replicas | Cross-shard queries become hard |
| Failure impact | Replica can replace primary | One shard failure affects a subset |
| Common combo | Each shard is often replicated | Sharding + replication |
“Sharding scales writes by splitting data across nodes. Each shard owns a subset of the keyspace. The hard parts are routing, rebalancing, cross-shard transactions, and hotspots.”
Common trap. Sharding too early. It adds major operational complexity.
3. Database types
There is no “best database.” There is only fit for access patterns, consistency needs, and scale.
-
Need ACID transactions?
Yes → relational (PostgreSQL / MySQL). No → pick by access pattern.
-
Access pattern
Key lookup → Redis / DynamoDB. Documents → MongoDB. Wide-column / time-series → Cassandra. Relationships → Neo4j.
| Type | Examples | Data model | Best for | Watch out |
|---|---|---|---|---|
| Relational / SQL | PostgreSQL, MySQL | Tables, rows, strict schema | Transactions, joins, reporting | Vertical scaling limits, sharding complexity |
| Document | MongoDB, CouchDB | JSON-like documents | Flexible schemas, catalogs | Joins and multi-doc transactions |
| Column | Cassandra, HBase | Column families | Write-heavy, time-series | Query flexibility |
| Key-value | Redis, DynamoDB | Key → value | Caching, sessions, low-latency lookup | Limited query patterns |
| Graph | Neo4j | Nodes and edges | Social graphs, recommendations | Scaling and operational cost |
“I choose a database based on access pattern and consistency. SQL for ACID and relational queries. Key-value for simple low-latency lookups. Document for flexible schemas. Column for write-heavy workloads. Graph for relationship-heavy queries.”
4. Database index types
Indexes speed up reads but slow down writes and consume storage. Close the holes in a deep quiz before you ask them on a mock.
| Index type | Best for | Weak for | Notes |
|---|---|---|---|
| B-tree / B+tree | Range queries, sorting | Very high-cardinality exact match only | Default in many SQL databases |
| Hash | Exact equality = | Range scans | Fast point lookups |
| Composite | Multi-column filters | Too many columns | Column order matters |
| Full-text | Text search | Structured numeric queries | Often uses inverted index |
| Spatial | Geo queries | General-purpose queries | R-trees / geohashes |
| Clustered | Physical row order | Only one per table | Table data is ordered by index |
| Non-clustered | Separate lookup structure | Extra indirection | Stores pointers to rows |
- B+tree: root → internal nodes → leaf nodes → row pointers.
- Hash: key → hash bucket → row pointer.
“Indexes trade write cost and storage for faster reads. B+tree is great for ranges and sorting. Hash is great for equality. Composite indexes must match query column order. Clustered indexes define physical order; non-clustered indexes point to rows.”
Common trap. Adding indexes everywhere. Every index increases write amplification.
5. Forward proxy vs reverse proxy
- Forward: client → forward proxy → internet → server. Hides the client from the server.
- Reverse: client → reverse proxy → backend 1 / backend 2. Hides the backends from the client.
| Aspect | Forward proxy | Reverse proxy |
|---|---|---|
| Sits in front of | Clients | Servers |
| Hides | Client identity from server | Backend architecture from client |
| Typical uses | Access control, anonymity, caching, bypassing restrictions | Load balancing, SSL termination, caching, security |
| Who configures it | Client or network admin | Service provider |
“A forward proxy represents clients to servers. A reverse proxy represents servers to clients. Forward proxies are about client-side control and anonymity. Reverse proxies are about scaling, TLS, caching, and protecting backends.”
6. Load balancing algorithms
Clients → load balancer → app server 1 / 2 / 3.
| Algorithm | How it works | Best for | Risk |
|---|---|---|---|
| Round Robin | Rotates requests | Homogeneous servers | Ignores load |
| Weighted Round Robin | Rotates by weight | Mixed server capacities | Weights need tuning |
| Least Connections | Sends to least busy | Long-lived connections | State tracking |
| IP Hash | Hashes client IP | Session stickiness | Uneven distribution |
| Least Time | Picks lowest latency / connections | Latency-sensitive systems | More complex |
“Round Robin is simple but ignores server load. Least Connections works well for uneven request durations. IP Hash gives session affinity. Weighted algorithms handle heterogeneous hardware. The right choice depends on session model, request duration, and failure behavior.”
Round robin on paper is not a mock
Say least-connections vs IP hash out loud. A partner hears the hole that a highlighter does not.
7. 2PC vs 3PC distributed transactions
2PC happy path, as numbered steps — not a sequence renderer:
-
Prepare
Coordinator asks participant 1 and 2. Both vote yes.
-
Commit
Coordinator sends commit. Both reply done. If the coordinator dies after prepare, participants stay blocked.
| Protocol | Phases | Blocking? | Fault tolerance | Practical use |
|---|---|---|---|---|
| 2PC | Prepare → Commit / Rollback | Yes, if coordinator fails | Low availability | Legacy / distributed DBs |
| 3PC | CanCommit → PreCommit → DoCommit | Less blocking | Better but complex | Rare |
| Saga | Local transactions + compensations | Non-blocking | Eventual consistency | Modern microservices |
“2PC blocks participants if the coordinator fails after prepare. 3PC adds a PreCommit phase to reduce blocking, but it is complex and still not perfect. In modern microservices, Saga is often preferred because it uses local transactions and compensations.”
Common trap. Recommending 2PC for high-scale microservices without discussing availability.
8. Transaction outbox vs transaction inbox
-
Produce
Service A writes business data and an outbox row in one DB transaction. CDC / poller publishes to Kafka.
-
Consume
Service B stores the message id in an inbox, then an idempotent handler runs once.
| Pattern | Used by | Purpose | Mechanism | Guarantee |
|---|---|---|---|---|
| Transaction Outbox | Producer | Reliable event publishing | Write event to outbox in same DB transaction | Event is not lost if the business action commits |
| Transaction Inbox | Consumer | Reliable / idempotent processing | Store message ID before processing | Prevents duplicate processing |
“Outbox solves reliable publishing: the business write and event write happen in one local transaction. A separate process publishes it. Inbox solves reliable consumption: the consumer stores message IDs and processes only once. Together they support exactly-once-style behavior.”
9. Replication vs backups
| Aspect | Replication | Backup |
|---|---|---|
| Purpose | High availability, read scaling | Recovery from corruption, deletion, disasters |
| Data state | Live, continuously updated | Point-in-time snapshot |
| Serves traffic? | Yes, replicas can serve reads | No |
| Protects against | Node failure, AZ failure | Logical errors, ransomware, accidental deletes |
| Risk | Bad writes propagate | Restore time can be long |
- Replication: primary — live copy → replica.
- Backup: data at T1 stored separately → restore at T2.
“Replication is for availability and read scaling. Backups are for recovery. Replication does not protect you from a DELETE FROM users, because the delete replicates. Backups give you a point-in-time restore.”
10. Data partitioning strategies
| Strategy | How it works | Pros | Cons | Example |
|---|---|---|---|---|
| Range | Split by key range | Efficient range scans | Hotspots | Users A–H, I–P |
| Hash | Hash key → shard | Even distribution | No range queries | hash(user_id) % N |
| List | Explicit mapping | Business control | Manual maintenance | Country / region |
| Geo-based | Place data near users | Low latency | Data sovereignty complexity | EU users in EU |
| Modulo N | id % N | Simple | Hard to reshard | Small systems |
“Range partitioning is good for scans but risks hotspots. Hash partitioning distributes evenly but breaks range queries. List and geo partitioning give business control. Modulo is simple but painful when N changes.”
11. Synchronous vs asynchronous vs semi-synchronous replication
-
Write
Client → primary.
-
Replicate
Primary → replica. Sync waits for ACK before OK to the client. Async does not.
| Mode | Primary waits for | Latency | Consistency | Data loss risk |
|---|---|---|---|---|
| Synchronous | All replicas | High | Strong | Very low |
| Asynchronous | No replicas | Low | Eventual | Possible |
| Semi-synchronous | At least one replica / quorum | Medium | Better than async | Reduced |
“Synchronous replication waits for all replicas, so it is consistent but slower and less available. Asynchronous is fast but can lose recent writes. Semi-synchronous waits for at least one replica, balancing latency and durability.”
12. Delivery guarantees: at-most-once, at-least-once, exactly-once
Producer → broker → consumer → idempotent processing / dedup store.
| Guarantee | Meaning | Duplicates? | Loss? | Requires |
|---|---|---|---|---|
| At-most-once | Send once, no retry | No | Possible | Nothing special |
| At-least-once | Retry until ACK | Possible | No | Idempotent consumer |
| Exactly-once | Process once, no loss / dupes | No | No | Transactions + idempotency + dedup |
“At-most-once may lose messages. At-least-once guarantees delivery but can duplicate, so consumers must be idempotent. Exactly-once is usually an end-to-end application property achieved with at-least-once transport plus idempotency, deduplication, and transactional writes.”
Common trap. Claiming exactly-once is free. It is not. It is a system design outcome.
Visual cheat sheet: one map for all 12
A theory map, not a vendor list. Jump to the section you still fumble:
Interview answer framework
Use this structure for almost any System Design theory question. Rehearse the five steps on a pair mock.
| Step | What to say | Example |
|---|---|---|
| 1. Define | One-sentence definition | “Sharding splits data across nodes.” |
| 2. Purpose | Why it exists | “To scale writes and reduce per-node data size.” |
| 3. Trade-off | What you lose | “Cross-shard queries and transactions get harder.” |
| 4. Example | Real system | “User data sharded by user_id.” |
| 5. Alternative | When not to use | “Start with replication and read replicas first.” |
Bonus: a drill prompt — not a second product
A voice script for self-study. Do not paste a résumé, email, or user id into any model. A live partner still comes from Find a partner.
You are an IT Career Gym System Design interviewer.
Ask me one System Design theory question at a time from this list:
- replication
- sharding
- database types
- indexes
- forward vs reverse proxy
- load balancing algorithms
- 2PC vs 3PC
- transaction outbox vs inbox
- replication vs backups
- partitioning strategies
- synchronous vs asynchronous replication
- delivery guarantees
For each answer:
- Score me from 1–5 on clarity, depth, and trade-off thinking.
- Point out what a senior engineer would add.
- Give me a better 30-second answer.
- Ask one follow-up question.
- Then move to the next topic only when I say “next.”
Start with replication.
-
Read
One concept from the map above.
-
Explain aloud
The 30-second answer, then a follow-up.
-
Draw
Primary/replica or the shard router. Bring a pet-project board if you have one.
-
Compare
Name the trade-off. Then drill the next topic.
Final thoughts
System Design theory is not memorization. It is vocabulary for trade-offs. If you can define the concept, draw it, explain when to use it, and name the downside, you will sound senior even before you mention a specific vendor.
Want a human on the other side of the board? Open a search. The article is the script, not the loop.
Questions people actually ask
Tap a row. Only one stays open — these are trade-off traps, not a glossary of what system design is.
-
Is replication the same as a backup?
No. Replication is a live copy for availability and reads. A bad DELETE replicates everywhere. A backup is a point-in-time snapshot for recovery.
Link to this answer -
Should I shard on day one?
Usually no. Sharding scales writes, but routing, rebalancing, hotspots, and cross-shard transactions are expensive. Start with replication and read replicas unless write volume already forces a split.
Link to this answer -
How do I pick SQL vs key-value vs column in 30 seconds?
Need ACID and joins? Relational. Simple low-latency lookup? Key-value. Flexible documents? Document store. Write-heavy time-series? Column. Relationship walks? Graph. Access pattern first, brand second.
Link to this answer -
If the broker says exactly-once, is the consumer done?
No. Exactly-once is an end-to-end property: at-least-once transport plus idempotency, deduplication, and transactional writes. The broker slogan is not a free pass.
Link to this answer -
Should I recommend 2PC for high-scale microservices?
Not as the default. 2PC blocks if the coordinator fails after prepare. Saga with local transactions and compensations is the usual modern answer. Name 2PC only when you also name the availability cost.
Link to this answer -
Outbox or inbox — which side am I on?
Outbox is the producer: write the business row and the event in one local transaction, then publish. Inbox is the consumer: store the message id and process once. Together they support exactly-once-style behavior.
Link to this answer -
Does IT Career Gym run an architecture simulator or book a FAANG interviewer?
No. Matching finds another engineer for a pair mock. You draw the shard router and say the 30-second answers yourselves. The gym does not host the video room and does not promise an offer.
Link to this answer -
Hash or range partitioning if I need range scans and I fear hotspots?
Range is good for scans and bad for hotspots. Hash spreads evenly and breaks range queries. Say both, then pick from the actual access pattern — not from a default.
Link to this answer
Draw it, then say it
Open a search, pick one concept, and keep the quizzes for the holes. Already have an account? Log in and start matching.
Also in this series: Avito hiring loop · Pair mock interview · Amazon system design · Stripe system design · Microsoft system design · Last week before the interview