DEV Community: Shohruh Sharipov

The 5-step framework I use for any system design interview (6 worked examples)

Shohruh Sharipov — Sat, 12 Sep 2026 16:53:33 +0000

Most people fail system design interviews by jumping straight to boxes. The fix is a fixed order:

Clarify — functional + non-functional requirements, say the numbers out loud.
Estimate — users, requests/sec, storage. Rough is fine; having a number is the point.
High-level design — the minimum boxes that satisfy step 1.
Deep-dive the hard part — the one component that makes this problem this problem. This is where you score.
Tradeoffs — what you gave up and why.

Applied to the six classics — URL shortener, rate limiter, DB scaling, news feed, caching/LRU, chat — in one animated video:

Which of the six would you least want to get? Mine is the news feed.

What ChatGPT is actually doing when it answers you

Shohruh Sharipov — Sat, 12 Sep 2026 16:51:43 +0000

It doesn't "understand" you. It does one thing, over and over: guess the next token, append it, guess again. Once that clicks, the weird behavior stops being mysterious:

Tokens, not letters — that's why it can't count the r's in "strawberry".
Meaning is geometry — words become vectors; "king" sits near "queen".
Attention decides which earlier words matter for the next one.
Pretraining makes a wild autocomplete; RLHF turns it into an assistant.
Temperature is why the same prompt gives different answers.
The context window is why it "forgets" — the oldest text literally falls off.
Hallucination is the model doing its job (plausible text) where plausible ≠ true.

Nine minutes, fully animated, no math required:

Which of these surprised you the most when you first learned it?

Your app went viral. Adding servers made it worse. Here's why.

Shohruh Sharipov — Sat, 12 Sep 2026 16:50:32 +0000

It's midnight, someone huge shares your app, 100,000 people show up — and the page dies. You add three servers. It gets worse.

The rule that finally made this click for me: before you add capacity, find out where the request is actually waiting.

Follow one slow request and the whole "scaling" story falls out in order:

It's usually the database, not the app — the app only looks busy holding unfinished work.
More app servers = more waiters, one cook. They all hit the same DB and exhaust its connection pool.
Index the hot query before buying hardware.
Cache it — but respect the stampede when a hot key expires.
Queue the slow work — and watch the backlog; async can be "silently hours behind."
Retries make outages worse without backoff + jitter.
Two buyers, one last ticket → one atomic conditional write.

Every fix moves the bottleneck. That's not failure — that's the job.

I animated the whole thing as one request hopping through each fix:

Where does your slow request wait? I'd genuinely like to hear the war stories.

How HashMap Really Works in Java (Under the Hood)

Shohruh Sharipov — Fri, 04 Sep 2026 18:18:28 +0000

Every Java developer uses HashMap. Far fewer can explain what actually happens when you call put() or get(). Here's what's going on under the hood.

I animated the whole thing below 👇 — writeup underneath.

From key to bucket

When you put a key in:

HashMap calls the key's hashCode() to get an int.
It spreads the bits (to reduce clustering) and maps it to one of N buckets — essentially hash & (N - 1).
The entry is stored in that bucket.

get() runs the same math to jump straight to the right bucket. That's why average lookups are O(1) — no scanning the whole map.

Collisions

Two different keys can land in the same bucket. HashMap handles this with separate chaining — a linked list inside the bucket. Since Java 8, once a single bucket gets long enough (8+ entries), it converts that list into a balanced tree, so a worst-case bad-hash scenario degrades to O(log n) instead of O(n).

Resizing (rehashing)

A HashMap has a load factor (default 0.75). Once it's ~75% full, it doubles the bucket array and rehashes every entry into the bigger table. This keeps buckets short and lookups fast — but a resize is an expensive, occasional cost.

Why it matters in practice

equals() and hashCode() must agree. Break that contract and keys effectively "disappear" — you store with one and can't retrieve with an equal one.
Size it up front for large inserts (new HashMap<>(expectedSize)) to avoid repeated resizes.

I make animated breakdowns like this — data structures, system design & backend, visualized — on CodeAnimated.

▶ Full channel: https://www.youtube.com/@CodeAnimatedDev

Why Your Counter Shows 847 Instead of 1000 (Race Conditions, Explained)

Shohruh Sharipov — Fri, 04 Sep 2026 18:08:35 +0000

Two threads each increment a shared counter 1,000 times. You expect 2,000. You run it — and get 1,847. Where did the missing increments go?

I animated exactly what happens below 👇 — the writeup is underneath.

Why `count++` isn't safe

count++ looks like one operation. It's actually three:

READ the current value
ADD 1
WRITE it back

Between any two of those steps, another thread can jump in. Both threads read the same value, both add 1, both write the same result — and one increment is silently lost. Do that thousands of times across two threads and you land below 2,000.

Three ways to fix it

synchronized — only one thread in the critical section at a time. Simple, correct, a little heavy.
AtomicInteger — lock-free, backed by a CPU compare-and-swap. Best for counters: counter.incrementAndGet().
ReentrantLock — explicit lock() / unlock() when you need finer control.

Why race conditions are so nasty

They almost never show up in single-threaded tests. They only appear under real concurrency, under load — which is why they slip into production and are miserable to reproduce. If shared, mutable state is touched by more than one thread, it must be synchronized.

I make animated breakdowns like this — concurrency, system design & backend, visualized — on CodeAnimated.

▶ Full channel: https://www.youtube.com/@CodeAnimatedDev

How Banks Detect Fraud in 27 Milliseconds (The System Design)

Shohruh Sharipov — Fri, 04 Sep 2026 17:54:44 +0000

You tap your card in New York. Two minutes later, someone tries to use it in Lagos — and the bank blocks it instantly. How does it decide in under 30 milliseconds, across billions of transactions a day?

I animated the whole pipeline below 👇 — the rest of this post walks through it in text.

The 5-stage pipeline (~27ms total)

1. Ingest — Apache Kafka (~1ms). Millions of transactions per second stream in. Kafka appends each to a log, so nothing is lost and everything is processed in real time.

2. Rules engine (~2ms). Fast, hard-coded checks run first: geo-velocity (NYC → Lagos in 2 minutes = physically impossible), amount vs. the user's historical average, and time-of-day / spending-limit patterns.

3. ML model (~15ms). The heavy lifting. A model trained on 500M+ real transactions takes features — amount, geo distance, merchant category, device fingerprint — and outputs a fraud probability score.

4. Graph database (~8ms). Checks whether this card, merchant, or device is connected to known fraud rings. One fraudster's network can span thousands of cards, and a graph query surfaces that instantly.

5. Decision engine (~1ms). Combine the signals into a score:

0–30 → auto-approve
31–69 → send an OTP challenge
70–89 → human analyst queue
90–100 → instant block + SMS alert

A combined score of 94/100 means BLOCKED, and the cardholder is notified in about a second.

Why it's fast

Every slow decision is pushed off the critical path: Kafka absorbs bursts, the rules engine kills obvious cases before the ML model ever runs, and scoring is precomputed features plus fast inference — never a big database scan on the hot path.

I make animated breakdowns like this — system design, backend & DevOps, visualized — on CodeAnimated.

▶ Full channel: https://www.youtube.com/@CodeAnimatedDev

Free developer online tools

Shohruh Sharipov — Fri, 27 Feb 2026 10:27:36 +0000

I built DevUtilities.dev — 16 free developer tools, no sign-up, everything runs in your browser.
Tired of pasting JWTs into sketchy sites with cookie banners and pop-ups. So I built my own: JWT decoder, JSON formatter, regex tester, UUID generator, YAML↔JSON converter, QR code generator, cron builder and more.
Your data never leaves your machine. No account needed. Just open and use.
👉 https://devutilities.dev
What tools do you wish existed? Drop them in the comments.

Tags: #webdev #tools #productivity #javascript

DEV Community: Shohruh Sharipov

The 5-step framework I use for any system design interview (6 worked examples)

What ChatGPT is actually doing when it answers you

Your app went viral. Adding servers made it worse. Here's why.

How HashMap Really Works in Java (Under the Hood)

From key to bucket

Collisions

Resizing (rehashing)

Why it matters in practice

Why Your Counter Shows 847 Instead of 1000 (Race Conditions, Explained)

Why count++ isn't safe

Three ways to fix it

Why race conditions are so nasty

How Banks Detect Fraud in 27 Milliseconds (The System Design)

The 5-stage pipeline (~27ms total)

Why it's fast

Free developer online tools

Why `count++` isn't safe