DEV Community: Santosh Ravi Teja Goteti

Interviewers don't grade your system design diagram. They grade whether you can defend it. Take a look at this System design prep app, play around with it and see if it can help you in any ways!

Santosh Ravi Teja Goteti — Wed, 07 Oct 2026 01:49:18 +0000

Santosh Ravi Teja Goteti

Oct 6

I built a system design app that teaches why and helps you in interviews

#showdev #systemdesign #webdev #ai

6 min read

I built a system design app that teaches why and helps you in interviews

Santosh Ravi Teja Goteti — Tue, 06 Oct 2026 04:19:54 +0000

SysDesign Studio is an open-source, interactive way to practice system design interviews. Evolve architectures step by step, trace failure paths, and defend every decision.

Most system design prep teaches you to draw boxes: load balancer, cache, queue, done.

Then the interviewer asks, "Why a cache and not read replicas?" or "What happens when that Redis node dies?" A memorized diagram can't answer either question.

That gap is what interviews actually test. So I built SysDesign Studio, an open-source app for practicing the reasoning behind the boxes.

⭐ Source:

Santoshrt999 / sysDesign-studio

SysDesign Studio

Learn to reason about systems, not just draw them.

A polished learning app for system design interviews. It helps engineers reason through architecture decisions, trade-offs, bottlenecks, and failure modes instead of memorizing buzzwords.

Built with Next.js, TypeScript, Tailwind CSS, and a content-driven problem model so each design lesson is easy to extend without touching the UI.

Author

This project is created and maintained by Santosh Goteti.

About

SysDesign Studio is built for engineers who want to strengthen the mental models behind real systems:

why a component exists in the first place
what problem it solves under realistic load
which alternatives were considered and rejected
what breaks first as scale increases
how the design evolves from a simple starting point to a resilient system

This repository turns those ideas into a guided interview-style learning journey.

Why this project?

System design interviews are not about drawing fancy diagrams — they…

View on GitHub

The problem with how we prep

Most resources show you the final architecture of a system. That's like learning chess by staring at checkmate positions. You never see:

Why each component showed up, and what number forced it in
Which alternatives were on the table, and why they lost
What breaks next: every fix introduces a new failure mode
How the design evolved from one server to global scale

Interviewers aren't grading your diagram. They're grading whether you can defend it.

How it works: a 7-stage interview flow

Every problem follows the shape of a real interview:

Stage	What you practice
1. Understand	Clarifying questions, plus how each answer changes the design
2. Size	Back-of-envelope math that always ends in a "so what" for the design
3. Start simple	APIs, data model, sync vs. async, and the simplest design that works
4. Evolve	v1 → v7, one bottleneck at a time
5. Flows	Animated write, read, and failure paths through the diagram
6. Deep dives	The hard sub-problems, with options and a recommendation
7. Defend	Trade-offs, follow-up questions, and common mistakes

Every evolution step uses the same strict template:

Problem → Evidence (numbers) → Options (each with a verdict) → Decision → New risks + mitigations → "Say it"

The "Say it" line is what you'd literally say out loud to the interviewer. It's the piece I wished I'd had when I was preparing.

Four problems are fully written, with more on the way!

Problem	Difficulty	The core tension
🔗 URL Shortener	Medium	A read-heavy key-value system where ID generation is the hard part
🚦 Rate Limiter	Medium	A ~1 ms allow/deny decision on every request, with counters shared across a fleet
📞 Phone Directory	Medium	"Who's calling?": a lookup that must answer while the phone is still ringing
🕷️ Web Crawler	Hard	Politeness, dedupe, and a frontier that feeds thousands of fetchers without hammering anyone

Each one has 7 evolution steps, 7–8 flows (including failure scenarios), 3 deep dives, trade-offs, follow-ups, and mistakes to avoid.

Here's a taste of each.

🔗 URL Shortener, v3: "Cache the read path"

Problem: every redirect hits the database. That's 350K reads/s at peak against one primary.

Evidence: a single Postgres primary handles roughly 10–20K primary-key lookups/s, so we're 20–30× over. Reads outnumber writes 100:1, and the traffic is heavily skewed.

Options:

❌ Read replicas: you'd need 25+ full copies, replication lag breaks the "creator clicks immediately" case, and it ignores the skew. It's the expensive way to buy throughput.
❌ Shard now: sharding is coming for storage reasons, but for reads alone it's slower to roll out and costs more.
✅ Cache-aside with Redis: the hot set is about 100 GB, and you get a hit rate above 90%.

The insight that makes the cache win is that short-code → URL mappings never change. The classic cache headache, invalidation, mostly disappears; the only exception is takedowns.

New risks the step introduces: a cache stampede on a viral link (fixed with single-flight request coalescing), losing a cache node (Redis Cluster with replicas), and scanners probing random codes (negative caching plus per-IP limits).

💬 Say it: "Short-code-to-URL mappings never change, so caching them is unusually safe. With 100:1 reads and a skewed distribution I expect a 90%+ hit rate, which brings DB load from 350K/s down to about 35K/s."

🚦 Rate Limiter: the race condition nobody draws

The naive version is GET count → compare → SET count. With two gateways, both can read 99 and both allow request #100. In a load test with 1,000 concurrent checks against a 100-token bucket, about 140 got through.

The step compares three fixes. GET/SET from the gateway is racy and slow. Optimistic locking (WATCH/MULTI) is correct, but its retries pile up on hot keys exactly when you need speed. The winner is a token bucket in a single atomic Lua script: one round trip, no race, and it uses Redis's clock so gateway clock skew doesn't matter.

The deep dives then cover algorithm choice, how exact the count really needs to be, and the classic question: fail open or fail closed?

📞 Phone Directory: the fastest lookup is the one you never make

Caller ID has a hard deadline: the answer must arrive before the user picks up. The server path is already about 15 ms, but mobile p99 round trips run 300–800 ms on weak networks.

Two tricks from this problem:

A Bloom filter for unknown numbers. About 30% of lookups are numbers we've never seen, so a cache can't help. A 3.6 GB Bloom filter answers "definitely not here" in memory.
An on-device snapshot. The top 5M numbers cover about 50% of lookups but weigh only about 100 MB. They ship nightly through a CDN with daily deltas, so half of all lookups never leave the phone and keep working offline.

It also covers the messy parts real systems face: number normalization, merging conflicting crowd-sourced names, and privacy-by-design deletion.

🕷️ Web Crawler: why the frontier is not "just a Kafka topic"

The estimate that changes everything: politeness limits you to about 1 request/s per host. To reach 2,000 pages/s, you must be fetching from at least 2,000 different hosts at every moment. A 500M-URL site would take about 16 years at that rate.

So the frontier can't be one global FIFO. A broker can't express "not before time T, per host, with priority." The design uses a purpose-built scheduler instead: priority front queues, a back queue per host, and a min-heap keyed on next_allowed_time. Kafka still shows up, between fetch and parse, where ordering and timing don't matter.

The failure flows cover slow and hostile sites, fetchers dying mid-fetch, crawler traps (infinite URL spaces), and a frontier partition losing its politeness state during failover.

Failure paths are first-class

Every problem includes animated failure flows that run on the final architecture, with failing hops drawn in red:

A cache node dies mid-spam-wave
A viral link triggers a stampede
A whole region goes down
An event gets processed twice

Each flow can also be viewed as an auto-generated sequence diagram.

Under the hood

Next.js 15, React 19, TypeScript, Tailwind v4
@xyflow/react for the architecture diagrams, with custom floating edges
Packets animate along edges with SVG animateMotion
Mermaid sequence diagrams are generated from the same flow data
Framer Motion for stage transitions

The design decision I'm happiest with is that content is pure data. Each problem is a single TypeScript file, and each evolution step is a delta on the previous diagram:

{
  version: "v3",
  title: "Cache the read path",
  problem: "Every redirect hits the database: 350K reads/s at peak against one primary.",
  evidence: "A single Postgres primary does roughly 10–20K simple PK lookups/s...",
  options: [ /* each with pros, cons, and a verdict */ ],
  decision: "Cache-aside: on GET, try Redis...",
  newRisks: [ /* risk + mitigation pairs */ ],
  sayIt: "Short-code-to-URL mappings never change, so caching them is unusually safe...",
  delta: {
    addNodes: [{ id: "cache", label: "Cache", sub: "Redis Cluster ~100 GB", kind: "cache", x: 960, y: 80 }],
    addEdges: [{ id: "api-cache", from: "api", to: "cache", label: "GET / SET" }],
  },
}

diagramAt(problem, n) replays the deltas to build the diagram at any step and tracks which nodes changed, which drives the NEW / CHANGED highlights. Flows are validated against the final diagram's edges, so a flow can't route a packet along a connection that doesn't exist.

As a result, adding a new problem never touches the UI.

What's next

[ ] More problems: Video Streaming, Chat App, News Feed, Payment System, Distributed KV Store, and more
[ ] Practice mode: reveal one stage at a time and sketch your own answer first
[ ] Drag-and-drop canvas to build your own design and compare it to the reference
[ ] Building-block guides, decision trees, and a scaling cheat sheet

Try it / contribute

git clone https://github.com/Santoshrt999/sysDesign-studio.git
cd sysDesign-studio
npm install
npm run dev

Want to add a problem? It's one TypeScript file plus one line in the registry. PRs and content reviews are very welcome, especially from people who've sat on the interviewer side of the table.

Which system design problem should I write next? Tell me in the comments 👇

If this helps your prep, a ⭐ on GitHub helps others find it.

I built a Claude Code skill that scores your legacy Java code 1–100 and modernizes it to Java 21

Santosh Ravi Teja Goteti — Thu, 21 May 2026 00:59:53 +0000

The problem with Java 8 → Java 21 migrations

If you're working on a Java 8 codebase — or trying to break into banking and legacy system roles — this article is for you. Every Java 8 codebase has the same problems. You know they exist, but finding and fixing them across 50,000 lines is slow:

double for monetary values → silent FX precision loss in production
Unguarded order.getCounterparty().getAccount( ).getBalance() → NPE in settlement
synchronized HashMap → race conditions under concurrent trade load
Executors.newFixedThreadPool(200) → bottleneck at peak volume
60-line DTOs with manual equals/hashCode → noise hiding domain logic

What I built

A two-skill Claude Code plugin that acts as a
Senior Java Architect:

Skill 1 — /java-modernization-review
Analyzes your Java file, saves a full report to
analysis.md, and stops.
You review it before any code is touched.

Skill 2 — /java-modernization-implement
Reads analysis.md, applies every change,
writes *Modern.java alongside
the original. Never overwrites your file.

The scoring system

Every review produces a Before/After score
across 9 dimensions (100 points total):

## Scoring breakdown (100 points total)

🔴 NPE prevention — 15 pts
🔴 Monetary precision (BigDecimal) — 15 pts
🔴 Thread safety — 15 pts
🟡 Streams & collections — 10 pts
🟡 Exception handling — 10 pts
🟡 Modern data carriers (Records) — 10 pts
🟡 Concurrency model (virtual threads) — 10 pts
🟡 Modern Java features — 10 pts
🟢 Financial domain rules — 5 pts

Real example: TradeProcessor.java

Legacy code the skill flagged as critical:

// C1 — NPE: any of these can be null
  return order.getCounterparty().getAccount().getB
  alance();

 // C2 — Precision loss on every FX trade
 double total = 0.0;
  total += t.getAmount() * t.getFxRate();

  // C2 — Precision loss on every FX trade
 double total = 0.0;
  total += t.getAmount() * t.getFxRate();

 // C3 — Race condition on position updates
  private HashMap<String, Double> positionMap = new HashMap<>();
  public synchronized void updatePosition(String cp, double delta) {
      Double current = positionMap.get(cp);
      positionMap.put(cp, current == null ? delta : current + delta);
  }

// C4 — Swallowed settlement failure
  } catch (Exception e) {
      // TODO: handle later
  }

After /java-modernization-implement:

  // C1 fixed — Optional chain, no NPE possible
 public BigDecimal getCounterpartyBalance(Order order) {
      return Optional.ofNullable(order)
          .map(Order::getCounterparty)
          .map(Counterparty::getAccount)
          .map(Account::getBalance)
          .orElseThrow(() -> new IllegalArgumentException("Account balance unavailable"));
  }

  // C2 + C3 fixed — BigDecimal stream + lock-free map
  private final ConcurrentHashMap<String, BigDecimal> positionMap = new
  ConcurrentHashMap<>();
  public void updatePosition(String counterparty, BigDecimal delta) {
      positionMap.merge(counterparty, delta, BigDecimal::add);
  }

// Java 21 — virtual threads
  private final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

Score: 3/100 → 95/100 (+92 points)

What it covers — every Java release from 9 to 21

Priority 1 — Streams, Optional, method references
Priority 2 — var, helpful NPE messages, built-in HTTP client (Java 9–11)
Priority 3 — Records, sealed classes, pattern matching, text blocks (Java 12–16)
Priority 4 — Virtual threads, structured concurrency, lock-free atomics (Java 17–21)
Priority 5 — String templates, type inference improvements (Java 18–21)
Priority 6 — Date→java.time, StringBuffer→StringBuilder, reactive→virtual threads
Priority 7 — Module system (module-info.java)

Two-step workflow — review before any code changes

Step 1 — /java-modernization-review
→ Analyzes file
→ Saves analysis.md
→ Stops and waits for your approval

Step 2 — /java-modernization-implement
→ Reads analysis.md
→ Applies every change
→ Writes *Modern.java (original untouched)
→ Prints final score + delta

Install in Claude Code

/plugin marketplace add Santoshrt999/Java-Claude-Skills
/plugin install java-claude-skills@java-modernization-review
/plugin install java-claude-skills@java-modernization-implement
/reload-plugins

Full source code and the TradeProcessor example are in the repo:
👉

Santoshrt999 / Java-Claude-Skills

Claude Code skill: review and modernize legacy Java 8 code to Java 21 with AI. Generates a 1-100 score. Specialized for financial systems.

Java Claude Skills — Java 8 → Java 21 Modernization for Claude Code

AI-powered Java code modernization skill for Claude Code.
Analyzes legacy Java, generates a prioritized upgrade report, scores it 1–100, and applies every change — all inside your editor.

Why this skill?

Migrating Java 8 code to Java 21 is high-value but tedious — every codebase has the same problems:

Problem	Impact
`double` for monetary values	Silent precision loss on every FX calculation
Unguarded chained `.get()` calls	NPE crashes in production settlement flows
`synchronized` HashMap	Race conditions on position updates under load
Fixed thread pools	Bottleneck at 200–500 concurrent trades
Boilerplate DTOs with 60+ lines	Noise that obscures domain logic

This skill acts as a Senior Java Architect in your Claude Code session. It knows every Java feature from 8 through 21, enforces financial-domain safety rules, and produces code you can ship — not just advice.

Skills

…

View on GitHub

Again, if you're working on a Java 8 codebase — or trying to break into banking and legacy system roles — this repo is built for you.
The financial domain examples are intentional: trade processors, FX arithmetic, position maps, settlement logic. That's the code you'll actually face in banking interviews and on the job. Practice modernizing it here before you touch production.
Curious what scores you're seeing on your own codebases. Drop them in the comments.