Skip to main content
Interview Essential: These fundamentals are the building blocks of every system design. Interviewers expect you to naturally incorporate these concepts without being asked.

Quick Reference Card

Scalability

Scalability is the system’s ability to handle increased load. Think of it like a restaurant: vertical scaling is buying a bigger kitchen for your one chef; horizontal scaling is opening more locations with more chefs. The bigger kitchen has limits (there is only so large a building can be), but multiple locations can grow almost indefinitely — at the cost of coordinating menus, supply chains, and quality across them.

Vertical vs Horizontal Scaling

Vertical vs Horizontal Scaling

Vertical Scaling

Pros: Simple, no code changesCons: Hardware limits, single point of failure, expensive

Horizontal Scaling

Pros: Unlimited scale, fault tolerant, cost-effectiveCons: Complex, stateless requirement, data consistency

Latency vs Throughput

These two metrics are the heartbeat and breathing rate of your system. Latency tells you how fast a single request moves through the pipe; throughput tells you how many requests the pipe can handle at once. They are related but not interchangeable — you can have low latency with low throughput (a single fast server) or high throughput with high latency (a batch processing cluster). In interviews, always clarify which one the requirements prioritize, because optimizing for one often comes at the expense of the other.

Latency Percentiles

Availability

Availability = Uptime / (Uptime + Downtime)

The “Nines” of Availability

Achieving High Availability

Availability Layers

CAP Theorem

In a distributed system during a network partition, you must choose between consistency and availability. This is often stated as “pick 2 out of 3,” but that framing is slightly misleading — partition tolerance is not optional in any real distributed system (networks will fail). The real question is: when a partition happens, do you refuse to serve requests (CP) or serve potentially stale data (AP)? Think of it like a chain of restaurants during a phone outage between locations. A CP restaurant stops taking orders until it can confirm inventory with the warehouse (“Sorry, we cannot guarantee we have that dish right now”). An AP restaurant keeps serving but might accidentally sell a dish it has run out of (“We will fix it later if there is a conflict”). Neither approach is universally better — it depends on whether your users tolerate errors or staleness. CAP Theorem

Consistency (C)

All nodes see the same data at the same time

Availability (A)

Every request gets a response (success or failure)

Partition Tolerance (P)

System works despite network partitions

Real-World Trade-offs

ACID vs BASE

ACID (Traditional Databases)

ACID is the safety contract of relational databases. Think of it like a bank wire transfer: the money leaves your account and arrives in the recipient’s account as one indivisible operation. If anything fails mid-way, the entire operation is rolled back as if it never happened.

BASE (NoSQL Databases)

BASE is the pragmatic alternative for systems that prioritize availability and scale over strict transactional guarantees. Think of it like a social media “like” count — if two servers temporarily disagree on whether a post has 4,999 or 5,001 likes, nobody notices and the counts will converge shortly. You are trading immediate precision for the ability to handle millions of concurrent operations without locking.
Interview Pattern: When an interviewer asks “SQL or NoSQL?”, never answer with just the technology. Frame it as: “The consistency requirements of [feature X] suggest ACID guarantees, so I would lean toward a relational store here. But for [feature Y] where we are read-heavy and can tolerate brief staleness, a NoSQL store with eventual consistency gives us better horizontal scalability.” This shows you understand the why, not just the what.

Consistency Patterns

Strong Consistency

Every read receives the most recent write. All nodes see the same data at the same time. Consistency Patterns

Eventual Consistency

Reads might return stale data, but eventually all nodes will have the same data. Eventual Consistency

Read-Your-Writes Consistency

Users always see their own writes immediately, even if other users see stale data. Read Your Writes

Back-of-the-Envelope Estimation

Common Calculations

Storage Estimation

Memory Estimation

Interview Tip: Don’t worry about exact numbers. Round liberally and show your reasoning. 86,400 ≈ 100,000 is fine for estimation.

Interview Questions on Fundamentals

Answer: Choose CP (Consistency over Availability) when:
  • Financial systems: Bank transfers, payments - incorrect balance is worse than unavailability
  • Inventory management: Overselling is costly (e.g., airline seats)
  • Booking systems: Double-booking causes real-world problems
  • Leader election: Only one leader should exist at a time
Key phrase: “In this case, returning wrong data is worse than returning no data.”
Answer: Redundancy at every layer:
  1. Multiple DNS providers
  2. CDN with many edge locations
  3. Load balancers in active-passive or active-active mode
  4. Multiple application servers (stateless)
  5. Database replication (primary + replicas)
  6. Multi-region deployment
  7. Health checks and automatic failover
  8. Circuit breakers to prevent cascade failures
Answer: “When you post on social media, your friend might not see it for a few seconds because the data needs to propagate across replicas. This is acceptable because:
  1. Availability is more important than instant consistency
  2. The delay is usually sub-second and imperceptible
  3. The data will eventually be consistent everywhere
Compare to a bank transfer where you MUST see accurate balance immediately - that needs strong consistency.”
Answer: Use the “divide by 100,000” rule:
  • DAU × requests per day ÷ 100,000 ≈ QPS
  • Example: 100M DAU × 10 requests = 1B / 100,000 = 10,000 QPS
  • Peak = 2-3x average
For storage:
  • 1 request = ~500 bytes → 10,000 QPS = 5 MB/second = 432 GB/day