System Design Fundamentals Every Developer Should Master

System design interviews get a bad reputation for being abstract whiteboard theater, but the underlying concepts — load balancing, caching layers, database replication, consistency tradeoffs — are exactly the decisions that determine whether a real product survives its first viral moment or falls over. This is a grounded pass through the fundamentals, aimed at developers who want the mental models, not interview scripts.

Start with numbers, not diagrams

The single most common mistake in system design — in interviews and in real architecture reviews — is reaching for boxes and arrows before establishing basic numbers: expected requests per second, read/write ratio, data size, and latency requirements. A system serving 50 requests per second with a 100:1 read/write ratio looks nothing like one serving 50,000 requests per second with a 1:1 ratio, even if the feature set is identical.

Load balancing: spreading, not just routing

Load balancers do more than round-robin traffic across servers. They're also your first line of defense for health checking (removing unhealthy instances from rotation), TLS termination, and — with layer 7 load balancers — routing based on request content, which matters once you split a monolith into services.

• Round robin — simple, works well when instances are roughly equal capacity.
• Least connections — better under uneven request duration, common for long-lived connections.
• Consistent hashing — critical when you want the same client routed to the same backend, e.g. for in-memory caching per node.

Caching: the highest-leverage lever, with a cost

Nothing improves perceived performance faster than a well-placed cache. But every cache is a bet that stale data is acceptable for some window of time, and the size of that window is a product decision disguised as a technical one.

// Cache-aside pattern with Redis — the most common starting point.
export async function getUser(id: string) {
  const cacheKey = `user:${id}`;
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  const user = await db.user.findUnique({ where: { id } });
  if (user) {
    await redis.set(cacheKey, JSON.stringify(user), "EX", 300); // 5 min TTL
  }
  return user;
}

// Invalidate on write to avoid serving stale data past the TTL window.
export async function updateUser(id: string, data: Partial<User>) {
  const user = await db.user.update({ where: { id }, data });
  await redis.del(`user:${id}`);
  return user;
}

Database scaling: the part that actually gets hard

Stateless application servers scale horizontally almost for free — add more instances behind a load balancer. Databases don't get this luxury, because state has to live somewhere consistent. The standard progression looks like this:

CAP theorem, applied instead of memorized

During a network partition, you must choose between consistency (every read sees the latest write) and availability (every request gets a response). Most real systems don't pick one absolutely — they pick per operation. A checkout flow favors consistency; a 'likes' counter favors availability. Knowing which one your feature needs, per feature, is more useful than knowing the theorem's name.

Consistency requirements are a product decision wearing a technical disguise. — Arjun Mehta, Principal Software Engineer, NavikaTech

Putting it together

<Diagram caption="A typical read-heavy web application at moderate scale" nodes={[ "Client → CDN (static assets)", "Client → Load Balancer → App Servers (stateless, autoscaled)", "App Servers → Redis cache (hot reads)", "App Servers → Primary DB (writes) + Read Replicas (reads)", "Async jobs → Message Queue → Workers", ]} />

None of these pieces are exotic. The skill in system design isn't knowing that Redis exists — it's knowing which of these five boxes your current bottleneck actually lives in, and resisting the urge to add the other four preemptively.

Conclusion

Good system design is less about exotic technology and more about correctly identifying constraints — traffic shape, consistency needs, and failure modes — before choosing tools. Master the fundamentals in this article and you'll be equipped to reason about the vast majority of real architecture decisions you'll face.