System Design - lesson 4 | HackIndia Skills

Key point

Remember this

Cache reduces repeated work. Load balancing spreads live traffic across server copies.

Use them only where your design has a reason. In your submission, say what becomes faster, what can go stale, and what happens when one server fails.

Where cache fits

A cache stores a recent answer close to your app. It is useful when many users ask for the same data, like college event listings, product catalogues, leaderboard pages, or user profiles.

Do not cache everything. Cache reads that are common, slow, and safe to be slightly old for a short time.

Your to-do

Pick cache data

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

List your top three read APIs.
Mark which ones return mostly the same answer for many users.
Choose one endpoint where a 30 to 300 second stale answer is acceptable.
Set a TTL, which means the cache expiry time.
Write what you will do when the cache is empty: read from DB, then store the result.

0 of 5 done

Common mistake

Common cache mistake

Beginners cache private or fast-changing data without a plan. This can show wrong balances, old payment status, or another user’s data.

For hackathon projects, keep it simple. Cache public or low-risk data first. If data must be exact, read from the database.

Where load balancing fits

A load balancer sits before your servers. The client calls one public URL. The load balancer sends each request to one healthy server instance.

This helps when traffic grows, or when one server crashes. It does not fix slow database queries by itself. It only spreads requests across app servers.

Example

Express cache example

This simple in-memory cache is fine for learning and a demo. It will reset when the server restarts, and each server instance has its own cache.

For a real multi-server app, use a shared cache like Redis, then mention Redis in your design. If you ask AI to generate this code, check TTL, user data leakage, and error handling.

// server.js
import express from "express";

const app = express();
const cache = new Map();
const TTL_MS = 60 * 1000;

async function getEventsFromDb() {
  return [
    { id: 1, name: "HackIndia campus demo", city: "Bengaluru" },
    { id: 2, name: "AI build night", city: "Pune" }
  ];
}

app.get("/api/events", async (req, res) => {
  const key = "events:list";
  const cached = cache.get(key);

  if (cached && Date.now() < cached.expiresAt) {
    return res.json({ source: "cache", data: cached.data });
  }

  const data = await getEventsFromDb();
  cache.set(key, { data, expiresAt: Date.now() + TTL_MS });
  res.json({ source: "db", data });
});

app.listen(3000, () => console.log("API on port 3000"));

Tip

Write the diagram note

Your system design section does not need a perfect cloud setup. It needs a clear choice.

Example note: Client calls API Gateway or Load Balancer. It forwards to two Node.js API servers. API servers read public event lists from Redis cache first. On cache miss, they read PostgreSQL and store the result in Redis for 60 seconds.