DEV Community: tem chelsy

My First System Design Class Taught Me More Than a Year of Coding

tem chelsy — Mon, 11 May 2026 10:53:30 +0000

I walked into my first system design class expecting to write code. I walked out drawing boxes on a whiteboard and asking questions I had never thought to ask before. No syntax. No frameworks. Just shapes, arrows, and a deceptively simple prompt:

Design a service where users paste in a long URL and get back a short one.

That was it. The whole brief. Something every developer has used a hundred times — bit.ly, TinyURL, the link shortener baked into Twitter. I had never once thought about what was behind it. By the end of that session, I couldn't stop thinking about it.

This is what I learned.

The system design interview has a shape

Before we drew anything, our instructor made one thing clear: every system design problem follows the same five steps.

Clarify → Estimate → Sketch → Deep dive → Failure modes

That structure sounds obvious on paper. In practice, it is the hardest discipline to maintain. Every instinct in a developer's brain says start building. System design punishes that instinct. The first thing you do is ask questions — not answer them.

For the URL shortener, those questions were:

Is this read-heavy or write-heavy?
How short is "short"? What is the key format?
Do URLs expire?
Do users have accounts, or is it anonymous?
Do we need analytics?
Is this a global service?

Each answer reshapes the entire design. If URLs never expire, you don't need TTL logic anywhere in the system. If it's anonymous only, you don't need a users table. If you don't need analytics, you can use a 301 redirect instead of a 302 — a small technical detail with surprisingly large consequences.

The act of clarifying is not stalling. It is the design.

One number that changes everything

Once we agreed on scope, we did math. Quick, rough, back-of-envelope math — the kind where you round aggressively and the goal is order of magnitude, not precision.

Assume 100 million URLs created per day. That is roughly 1,200 writes per second. Now assume each short URL gets clicked ten times on average. That is 12,000 reads per second. Round up for peak traffic and you are looking at something closer to 120,000 reads per second.

The ratio of reads to writes is about 100 to 1.

💡 Key idea: That single number — 100:1 — is the most important fact about a URL shortener. It tells you where to spend your engineering effort, what will break first, and what your architecture needs to optimise for.

This system is not a writing system that also does reads. It is a reading system that occasionally accepts writes. That distinction changes every decision that follows.

The two endpoints

The API for a URL shortener is almost insultingly simple. Two endpoints:

POST /shorten    →  takes a long URL, returns a short code
GET  /:code      →  redirects to the original URL

That second endpoint is where all the complexity lives. It runs 100 times more often than the first. It needs to respond in under 10 milliseconds. It needs to handle viral traffic spikes — a single link being clicked by millions of people in minutes.

There is also a small but meaningful technical decision hiding in that GET endpoint: 301 or 302?

	301 Permanent	302 Temporary
Browser caches it?	✅ Yes — forever	❌ No — re-checks every time
Analytics work?	❌ No	✅ Yes
Can expire the URL?	❌ No	✅ Yes
Saves bandwidth?	✅ Yes	❌ No

We use 302. The analytics and expiry control are worth the extra traffic.

How do you generate the short code?

This is where it gets interesting. There are three approaches, each with real trade-offs.

Option 1 — Hash the URL

Run the long URL through MD5. Take the first 43 bits. Encode in base62. You get a 7-character code.

Pro: Same URL always gives the same short code. Natural deduplication.

Con: Collisions happen at scale. You need a DB check and retry loop on every write.

Option 2 — Auto-incrementing counter

Keep a global counter. Every new URL gets the next number, encoded in base62.

Pro: Simple, no collisions.

Con: A global counter is hard to share across many servers. At 1,200 writes/sec it becomes a bottleneck. Also leaks how many URLs have been created.

Option 3 — Key Generation Service ✅ (preferred)

A separate service pre-generates a pool of random 7-character base62 keys offline. The Write API claims one atomically. Each server holds a local batch of 1,000 keys in memory.

Pro: Zero collisions. No retry loops. Sub-millisecond key assignment.

Con: Extra service to maintain. Needs at least two replicas (it is a single point of failure).

💡 Remember: In a design interview, none of these is wrong. What matters is naming the trade-offs and defending your choice.

Where does the data live?

The storage layer has two parts working together.

PostgreSQL holds the source of truth — a urls table mapping each short key to its long URL, owner, creation time, and expiry. We use read replicas (three or four of them) because the redirect path is read-only and those 120,000 reads per second can be distributed across multiple servers.

Redis sits in front of Postgres as a cache. Every time a URL is created, it is written to both Postgres and Redis simultaneously (write-through caching). When someone follows a short link, the Read API checks Redis first.

Cache hit  → return long URL instantly (no DB touched)
Cache miss → fetch from Postgres, repopulate Redis, return URL

At an 80% cache hit rate, only 24,000 of those 120,000 reads per second reach the database. Without caching, you would need five times more database capacity.

Caching is the cheat code for read-heavy systems.

The full architecture

When you put all of this together, the system looks like this:

         Client / Browser
               ↓
         Load Balancer
         ↙            ↘
    Write API        Read API
    ↙      ↘              ↓
Key Gen  PostgreSQL ← Redis
              ↓         (cache miss)
         Analytics
          (async)

The write path and read path are intentionally separated. Writes are rare and can be slightly slower — a user waiting 200ms to get a short link is acceptable. Reads are constant and must be instant.

How analytics work without slowing redirects

This is one of the trickiest parts. A redirect must be fast. Recording a click is slow. You cannot do both synchronously.

When someone follows a short link, the Read API returns the 302 redirect immediately. After the response is sent — while the user is already being redirected — the server records the click to an in-memory queue. A background process drains that queue every 2 seconds with a single bulk INSERT.

User clicks → 302 returned instantly
            ↓ (after response, async)
        click pushed to queue
            ↓ (every 2 seconds)
        bulk INSERT into clicks table

The user never waits. The database is not hammered. This is the core principle: never make the user wait for work they don't need to see the result of.

What could go wrong

This is the senior-engineer move. After the happy path works, ask: what fails?

🔴 Cache stampede

A viral link goes cold, its cache entry expires, then suddenly 100,000 users click it at the same moment. All miss Redis and flood Postgres simultaneously.

Fix: Redis mutex lock on miss — one thread fetches from DB, the rest wait briefly for the cache to repopulate.

🔴 Key Generation Service goes down

No new short URLs can be created. The entire write path is blocked.

Fix: Run 2+ KGS replicas. Each Write API server holds a local batch of 1,000 pre-fetched keys and continues working for minutes during a KGS outage.

🔴 Single link gets too hot

5 million clicks per minute overwhelms even the Redis shard serving that key.

Fix: Local in-memory cache on each Read API server (5s TTL). CDN caches the redirect at the edge — requests never reach your servers at all for the hottest links.

🟡 Database primary fails

Writes are blocked. Read replicas continue but may be slightly stale.

Fix: Automated leader election (Patroni). Queue writes in Redis during the ~30-second failover window.

🟡 Expired URL still in Redis

The URL expired in Postgres but Redis still returns the old entry.

Fix: Set Redis TTL 30 seconds shorter than the actual expiry. Check expires_at on every DB read as a safety net.

What I actually learned

The URL shortener is the "hello world" of system design for a reason. It is small enough to finish in one session and rich enough to introduce almost every major concept: caching, replication, key generation, rate limiting, async processing, failure modes.

But the deeper lesson was not about any of those things specifically.

1. The shape of a system matters more than the code inside it.
The same code that works for 1,000 users collapses under 1,000,000 — not because the code changed, but because the shape around it was never designed to scale.

2. The first question is never "how do I build this?"
It is "what does this actually need to do?" The 100:1 ratio was not a number I calculated and forgot. It was a constraint that filtered every subsequent decision. Good system design is a chain of consequences from the question you asked at the start.

3. Naming what fails is not pessimism — it is engineering.
Every system fails eventually. The difference between a resilient system and a fragile one is not whether failures happen, but whether someone thought through what to do when they do.

I came in expecting to write code. I left knowing how to think about systems.

That is a harder skill. And a more important one.

This is my write-up from Session 1 of a system design course. If you are following along, your homework is to sketch this same architecture on your own — without looking at notes — and find where you get stuck. That is exactly where the learning is.

Drop your questions or your own diagrams in the comments. Let's figure it out together. 👇

How I Implemented the SM-2 Spaced Repetition Algorithm in My Flashcard App

tem chelsy — Thu, 05 Mar 2026 10:16:35 +0000

What Is Spaced Repetition?

Here's the problem with traditional studying: you review everything equally, whether you know it or not. That's inefficient.

Spaced repetition flips this. Cards you struggle with come back sooner. Cards you know well get pushed further into the future. Over time, you spend your energy exactly where it's needed.

The SM-2 algorithm (developed by Piotr Wozniak in 1987) is the math behind this. It's the same core logic used in Anki — one of the most popular study tools in the world.

📐 The SM-2 Formula Explained

Every card tracks three values:

Variable	Meaning
`repetitions`	How many times you've answered correctly in a row
`easeFactor` (EF)	How "easy" the card is (starts at 2.5, min 1.3)
`interval`	Days until next review

After each review, the user rates their recall from 0 to 5:

0–2 = Failed (didn't remember)
3 = Barely remembered
4 = Correct with some hesitation
5 = Perfect recall

Here's the core logic:

function sm2(card, quality) {
  // quality: 0-5 rating from the user

  if (quality < 3) {
    // Failed — reset streak, review again soon
    card.repetitions = 0;
    card.interval = 1;
  } else {
    // Passed — calculate next interval
    if (card.repetitions === 0) {
      card.interval = 1;
    } else if (card.repetitions === 1) {
      card.interval = 6;
    } else {
      card.interval = Math.round(card.interval * card.easeFactor);
    }
    card.repetitions += 1;
  }

  // Update ease factor
  card.easeFactor = card.easeFactor + (0.1 - (5 - quality) * (0.08 + (5 - quality) * 0.02));

  // Ease factor never drops below 1.3
  if (card.easeFactor < 1.3) card.easeFactor = 1.3;

  // Set next review date
  card.nextReviewAt = new Date();
  card.nextReviewAt.setDate(card.nextReviewAt.getDate() + card.interval);

  return card;
}

That's it. The whole algorithm fits in about 20 lines.

How I Modeled This in the Database

In my Laravel backend, each card record in the cards table stores its SM-2 state:

// database/migrations/create_cards_table.php

Schema::create('cards', function (Blueprint $table) {
    $table->id();
    $table->foreignId('deck_id')->constrained()->cascadeOnDelete();
    $table->text('front');
    $table->text('back');

    // SM-2 fields
    $table->integer('repetitions')->default(0);
    $table->float('ease_factor')->default(2.5);
    $table->integer('interval')->default(1);
    $table->timestamp('next_review_at')->nullable();

    $table->timestamps();
});

When a study session ends, the frontend sends the user's rating to the API, and the backend runs the SM-2 calculation and updates these fields.

🔁 The Study Session Flow

Here's how a full study session works end-to-end:

1. Fetch due cards (Laravel Controller)

// CardController.php

public function getDueCards($deckId)
{
    $cards = Card::where('deck_id', $deckId)
        ->where(function ($query) {
            $query->whereNull('next_review_at')
                  ->orWhere('next_review_at', '<=', now());
        })
        ->get();

    return response()->json($cards);
}

Cards are "due" if next_review_at is null (never studied) or in the past.

2. User studies & rates each card (Vue 3 frontend)

<!-- StudySession.vue -->
<template>
  <div class="card-container">
    <div class="card" @click="flipped = !flipped">
      <div v-if="!flipped">{{ currentCard.front }}</div>
      <div v-else>{{ currentCard.back }}</div>
    </div>

    <div v-if="flipped" class="rating-buttons">
      <button v-for="rating in [0, 1, 2, 3, 4, 5]"
              :key="rating"
              @click="submitRating(rating)">
        {{ ratingLabel(rating) }}
      </button>
    </div>
  </div>
</template>

<script setup>
import { ref } from 'vue'
import { useStudyStore } from '@/stores/studyStore'

const store = useStudyStore()
const flipped = ref(false)
const currentCard = computed(() => store.currentCard)

async function submitRating(quality) {
  flipped.value = false
  await store.rateCard(currentCard.value.id, quality)
}

function ratingLabel(q) {
  const labels = ['Blackout', 'Wrong', 'Wrong (familiar)', 'Hard', 'Good', 'Easy']
  return labels[q]
}
</script>

3. Backend applies SM-2 and saves

// StudySessionController.php

public function rateCard(Request $request, $cardId)
{
    $card = Card::findOrFail($cardId);
    $quality = $request->input('quality'); // 0-5

    // Run SM-2
    if ($quality < 3) {
        $card->repetitions = 0;
        $card->interval = 1;
    } else {
        if ($card->repetitions === 0) {
            $card->interval = 1;
        } elseif ($card->repetitions === 1) {
            $card->interval = 6;
        } else {
            $card->interval = round($card->interval * $card->ease_factor);
        }
        $card->repetitions += 1;
    }

    $newEF = $card->ease_factor + (0.1 - (5 - $quality) * (0.08 + (5 - $quality) * 0.02));
    $card->ease_factor = max(1.3, $newEF);
    $card->next_review_at = now()->addDays($card->interval);

    $card->save();

    return response()->json($card);
}

What I Learned Building This

1. SM-2 is deceptively simple. The algorithm itself is tiny — the complexity is in building the session UX around it (card flipping, ratings, progress tracking).

2. The ease factor is the secret sauce. Cards you consistently ace get pushed further and further apart automatically. Cards you keep failing stay frequent. You don't need to configure anything — it self-adjusts.

3. "Due cards" queries need an index. Once you have thousands of cards, querying by next_review_at gets slow. I added a database index on that column and it made a noticeable difference:

$table->index('next_review_at');

4. Failed cards should NOT reset interval to 0. A common mistake is setting interval = 0 on failure, which means the card shows up immediately in the same session forever. Setting it to 1 (review tomorrow) feels much better in practice.

What's Next

The SM-2 algorithm is from 1987 — it works, but there are newer alternatives. The FSRS algorithm (Free Spaced Repetition Scheduler) is a modern neural-network-based approach that reportedly outperforms SM-2. It's on my roadmap to implement next.

If you're curious about the full project — including AI card generation with Groq LLaMA, community decks, and Google OAuth — the repo is here: github.com/chelsynew72/flashcard-app and the live demo is at flashcard-app-five-gamma.vercel.app.

Have you built anything with spaced repetition? I'd love to hear how you approached it — drop a comment below!

Next.js Finally Made Caching Make Sense — At Least to Me

tem chelsy — Fri, 20 Feb 2026 15:07:26 +0000

Okay so I have to be honest. When I first started learning Next.js, caching was the thing that broke my brain the most. I'd make a change to my data, refresh the page in production, and nothing would update. I'd Google it, find some Stack Overflow answer about revalidatePath or no-store, paste it in, and sometimes it worked. Sometimes it didn't. I never really understood why.

Turns out I wasn't alone. A lot of developers — including experienced ones — found Next.js caching confusing. And with Next.js 16, the team actually did something about it.

What Was the Problem?

In older versions of Next.js, caching happened automatically behind the scenes. Your pages were cached by default, and if you wanted fresh data, you had to know exactly which option to add, where to add it, and in what kind of file. The framework was making decisions for you without really telling you.

For a junior dev like me, that's really hard to debug. You don't know if the problem is your code, your fetch call, your deployment, or the framework itself quietly doing something you didn't ask for.

The New Way: `"use cache"`

Next.js 16 introduces something called Cache Components, and the main idea is just one line: "use cache".

You put it at the top of a component, a page, or even a single function — and that's what gets cached. If you don't write it, the page runs fresh on every request by default. That's it. You're in control now.

"use cache"

export default async function BlogPost() {
  const post = await fetchPost()
  return <article>{post.content}</article>
}

For me, this is so much easier to reason about. I can look at any file and immediately know: does it have "use cache" or not? That's my answer. No more digging through docs trying to figure out why my data is stale.

Pages Can Now Be Both Fast and Fresh

There's also something called Partial Pre-Rendering, and Next.js 16 is where it actually starts to click.

Here's the idea: imagine you have a blog post page. Most of it never changes — the title, the text, the author. But there's a comment counter at the bottom that should always be live. Before, you had to choose: make the whole page fast and static, or make the whole page dynamic and slower. There was no in-between.

Now you can cache the parts that don't change and let the live parts load in separately. The page still loads instantly. The comment counter catches up right after. Users get both.

That's genuinely cool and something I struggled to do cleanly before.

Dev Server Is So Much Faster Now

Next.js 16 also makes Turbopack the default bundler. I didn't fully understand what a bundler was when I started, but what I do know is that my dev server used to take a while to start and Fast Refresh sometimes felt slow on bigger projects.

With Turbopack, it's noticeably faster. And now it caches stuff between restarts, so when you stop and start your dev server, it doesn't have to redo everything from scratch. Small thing, but when you're restarting your server ten times a day while debugging, you feel it.

Less Boilerplate With the React Compiler

This one I'm still wrapping my head around, but basically — if you've ever been told to use useMemo or useCallback to stop your components from re-rendering too much, Next.js 16 includes the React Compiler which handles a lot of that automatically.

I'll be honest, I've copy-pasted useCallback without fully understanding it more than once. Knowing the compiler can handle some of that optimization for me is reassuring.

I'm still learning Next.js every day, and I don't have all the answers. But Next.js 16 is the first version where I feel like the framework is working with me instead of quietly doing things I can't see. The caching changes alone would have saved me hours of confusion when I was starting out.

If you're also a junior dev trying to figure this stuff out — yeah, it was confusing before. It's better now.