DEV Community: kirandeepjassal-crypto

Design a Notification System — Push, SMS & Email at Scale (with Production .NET Code)

kirandeepjassal-crypto — Sat, 05 Sep 2026 19:30:59 +0000

"Design a notification system" looks like an integration task — call Twilio, call SendGrid, done. The interview lives in everything around those calls: how do you fan one event out to a million recipients across three channels, make sure a marketing blast never delays someone's login OTP, avoid double-sending when your queue redelivers a message, and survive Twilio having a bad afternoon? It's a queues-and-reliability problem wearing an integration costume.

This is the condensed walkthrough; the full guide (the pipeline, the four hard parts, delivery tracking, and the full production .NET 9 code) is on my site 👇

Full guide: https://prepstack.co.in/blog/design-a-notification-system-system-design

The design at a glance

Concern	Decision
Core shape	Enqueue → per-channel workers → providers (decouple ingestion from delivery)
Fan-out	Expand recipients → one queued message per (user, channel)
Priority	Separate queues — transactional never waits behind bulk
Delivery guarantee	At-least-once + dedup (exactly-once across third parties is a myth)
Failures	Retry with backoff + jitter, then dead-letter queue
Politeness	User preferences, quiet hours, per-user rate limiting

Why it's a queue problem, not an integration problem

Estimate it: 100M notifications/day ≈ ~1,160/sec average — trivial. But a campaign blast to 50M users in minutes is tens of thousands/sec. The spike is the design driver, and a queue in the middle absorbs it so you never hand that burst straight to a rate-limited provider.

 Event sources (services, campaigns)
       │
       ▼
 [ Notification Service ]  — validate · apply prefs · dedup · render template
       │
       ▼
 [ Message Queue ]                    (priority: transactional vs bulk)
    │              │              │
    ▼              ▼              ▼
[Push worker]  [SMS worker]  [Email worker]     — scale independently
    │              │              │
    ▼              ▼              ▼
  APNs / FCM     Twilio          SES            — third-party providers
    │              │              │
    └──── delivery receipts (webhooks) ────▶ update status · DLQ on repeated failure

The four hard parts

1. Fan-out. One event can target millions. Expand the recipient list and enqueue one message per (user, channel) — in batches for huge audiences, so one request doesn't block producing millions of messages. Fan-out is where a tiny API call becomes a tidal wave; the queue is the seawall.

2. Priority — the OTP must not wait. A marketing blast enqueues tens of millions of messages. If a login OTP lands behind them in the same FIFO queue, it's useless by the time it arrives. Separate queues by priority — a high-priority transactional queue with its own workers, and a bulk queue for campaigns. Never let them share a lane.

3. Deduplication. Queues are at-least-once: a worker crash after sending but before acking causes redelivery. Guard every send with an idempotency key (eventId + userId + channel) checked against Redis before dispatch. If it's already marked sent, skip.

4. Retries + dead-letter queue. Providers fail (timeouts, 500s, throttling). Retry with exponential backoff + jitter up to a max, then send to a dead-letter queue for inspection rather than losing it or retrying forever. Wrap each provider in a circuit breaker, and ideally fail over to a backup provider.

"Sent" ≠ "delivered" ≠ "read"

Handing a message to Twilio isn't the phone buzzing. Consume delivery-receipt webhooks to move status from sent → delivered (or bounced/failed), and suppress future sends to a hard-bounced address. Apply user preferences and quiet hours before enqueueing, and cap frequency per user (batch low-priority notifications into a digest). This is both compliance (TCPA/GDPR/CAN-SPAM) and anti-fatigue.

I shipped this in production

We fan out ~15M events/day (budget.threshold.crossed, campaign.completed, conversion.tracked) to customer webhooks, email, and push. V1 dispatched inline in the request that produced the event — a deploy that recycled the app mid-flight dropped every in-memory delivery, and one slow customer endpoint dragged API latency up with it. Moving to outbox → Azure Service Bus → worker pool:

Metric	Before	After
Events dropped per deploy	Thousands	0 (outbox + queue)
First-attempt delivery success	n/a	~96%
Eventual delivery success	Lost on first failure	~99.98% (backoff + retry)
API write-path p95	Coupled to slow endpoints	120ms (decoupled)
Failing-endpoint handling	Retried inline, blocked workers	Auto-disabled after 20 consecutive failures

The producer never blocks on a customer's endpoint — it only writes to the queue — and the worker owns the retry clock via scheduled messages, so a slow or dead endpoint can never back-pressure the API. A Redis SET-based dedup key makes at-least-once safe to retry; the breaker sheds load from any endpoint that has failed 20 times in a row. (Full .NET 9 producer + worker + circuit breaker is in the post.)

The model to carry forward

A notification system is a queue that buffers your events from unreliable third-party channels. Everything hard about it — fan-out, priority, dedup, retries — is solved by not calling providers inline. Three habits it teaches: put a queue in the middle (it answers bursts, outages, and retries at once); separate urgent from bulk (the OTP-behind-the-newsletter failure is the one interviewers probe for); assume redelivery, so dedup.

The full guide has the full pipeline, all four hard parts in depth, delivery tracking + preferences, the design checklist, the complete production .NET 9 outbox→Service Bus worker (dedup, backoff+jitter, circuit breaker, DLQ), and the "when it's overkill" honest section:

https://prepstack.co.in/blog/design-a-notification-system-system-design

Originally published on PrepStack.

Design a Distributed Cache — Consistent Hashing, Eviction & Replication (with Production .NET Code)

kirandeepjassal-crypto — Fri, 04 Sep 2026 08:13:59 +0000

"Design a distributed cache" is really two interviews stacked on top of each other. First: build an in-memory cache on one machine — the classic O(1) LRU question. Then the twist that makes it distributed: the hot data is bigger than one machine's RAM, so you spread it across a cluster — and now you have to answer how keys map to nodes without every key moving when a node joins, what happens when a node dies, and how the cache stays consistent with the database behind it.

This is the condensed walkthrough; the full guide (the O(1) LRU structure, all the write policies, the hard parts, and the full production .NET 9 code) is on my site 👇

Full guide: https://prepstack.co.in/blog/design-a-distributed-cache-system-design

The design at a glance

Concern	Decision
Single-node cache	Hashmap + doubly-linked list → O(1) LRU get/put
Sharding	Consistent hashing with virtual nodes
Eviction	LRU default; LFU for skewed popularity
Availability	Replication (primary + replicas), promote on failure
Cache ↔ DB	Cache-aside by default; write-through / write-back / write-around as needed
Consistency	Eventually consistent — accept a small stale window

The single-node cache: O(1) LRU

Before distributing anything, build the one-machine cache with two structures: a hashmap key → node for O(1) lookup, and a doubly-linked list ordered by recency (MRU at the head, LRU at the tail).

get(key):   look up in map; move its node to the head; return value
put(key,v): insert at head; if over capacity, evict the tail (LRU); update map

Moving to the head and evicting the tail are both O(1). This is the atom every cache node is built from.

The core of the interview: consistent hashing

Why hash(key) % N fails. It works until N changes. Add one node (N → N+1) and the modulus changes for almost every key, so nearly the entire cache remaps — a mass of misses that all fall through to the DB at once. Adding capacity shouldn't nuke your cache.

Consistent hashing. Map both nodes and keys onto a ring (0 … 2^32). A key is owned by the first node clockwise from its hash.

0 ──── A ──── key1 ──── B ──── key2 ──── C ──── key3 ──(wraps)── 0
                └▶ B          └▶ C          └▶ A (wraps around)

Add node D between B and C and only the keys in arc (B … D] move — roughly 1/N of the keys. Everything else stays put. ~1/N churn instead of ~everything.

Virtual nodes. With only N points on the ring, placement is uneven and one node can own a giant arc (a hotspot). Place each physical node at many points (100–200 vnodes) so load averages out, nodes can be weighted, and a departing node's load spreads evenly instead of dumping on one neighbor.

Eviction

LRU (least recently used) — the default; great for temporal locality.
LFU (least frequently used) — better when a stable set of keys is persistently hot and you don't want a one-off scan to flush them.
TTL expiry runs alongside whichever policy you pick.

Write policies (where cache correctness lives)

Cache-aside (lazy loading) — the default. Read cache; on a miss read the DB and populate. On a write, update the DB and invalidate the key. Simple and resilient; the trade is a stale window + a miss-penalty on cold keys.
Write-through — write cache and DB synchronously. Always fresh, higher write latency.
Write-back — write cache, flush to DB async. Fast writes, but a crash before flush loses data.
Write-around — write straight to the DB, skip the cache; fills on later reads. Good for write-once-read-rarely data.

The genuinely hard parts

Cache invalidation — TTL is the pragmatic default; delete-on-write is tighter; event-driven is tightest and most complex.
Thundering herd (cache stampede) — a hot key expires and thousands of misses hammer the DB at once. Fixes: single-flight/locking, jittered TTLs, stale-while-revalidate.
Hot keys — one wildly popular key overwhelms its owning node; consistent hashing can't split a single key. Replicate the hot key to multiple nodes or cache it in the client.

Replication

Each shard has a primary + replicas. Replicas serve reads and stand ready for failover — when a primary dies, a replica is promoted and only that shard briefly degrades. Without replication, a dead node turns every key it held into a miss and spikes the DB.

I shipped this in production

Our dashboard recomputes campaign KPIs by aggregating over a 1.2B-row CampaignEvents table in Azure SQL. Every dashboard load fanned out into repeated full aggregate scans — the same tenant/campaign/date-range combos recomputed thousands of times a minute, p95 at 2,100ms, pinning the DB. A cache-aside layer (short TTL for freshness, version-token invalidation on ingestion for correctness):

Metric	Before	After
Dashboard KPI query p95	2,100 ms	48 ms
Database CPU	78%	22%
Working set	2.1 GB	380 MB
SQL cost	baseline	~$280/mo saved

Correctness comes from a per-campaign version token, not the TTL: a Kafka ingestion event bumps the version, which instantly makes every cached date range for that campaign unreachable — no SCAN/DEL sweep at 3,200 req/sec. The key is kpi:{tenant}:{campaign}:{range}:v{version}. (Full .NET 9 DashboardKpiService is in the post.)

The model to carry forward

A distributed cache is an O(1) LRU cache, sharded by consistent hashing, kept loosely in sync with a database. The single-node part is a data-structures exercise; the distributed part is all about change — making node joins/failures cheap (consistent hashing + vnodes) and the cache-DB gap manageable (write policies + invalidation). It rests on one permission: the cache is allowed to be a little wrong for a little while, and that's what buys the speed. Three habits: reach for consistent hashing the moment you shard, name the thundering herd, and pick a write policy on purpose.

The full guide has the O(1) LRU walkthrough, consistent hashing + vnodes in depth, all four write policies, replication/failover, the thundering-herd/hot-key fixes, the design checklist, and the complete production .NET 9 cache-aside KPI service:

https://prepstack.co.in/blog/design-a-distributed-cache-system-design

Originally published on PrepStack.

Design a Rate Limiter — Token Bucket, Sliding Window & Distributed Limits (with Production .NET Code)

kirandeepjassal-crypto — Wed, 02 Sep 2026 16:20:09 +0000

"Design a rate limiter" sounds like a five-minute answer — count requests, block past the limit. Then the interviewer starts pulling threads: which algorithm, and what's the burst behaviour at the window edge? Where does the counter live when you have 500 app servers? What happens to two requests that read the same counter at the same millisecond? What if the counter store goes down — block everyone or let everyone through? Those follow-ups are the whole interview.

This is the condensed walkthrough; the full guide (all five algorithms, the distributed section, and the full production .NET 9 code) is on my site 👇

Full guide: https://prepstack.co.in/blog/design-a-rate-limiter-system-design

The design at a glance

Concern	Decision
Algorithm	Token bucket (bursts, O(1)) or sliding-window counter (accurate, smooth)
Where it lives	API gateway / middleware, in front of app servers
State store	Redis — shared across all servers so the limit is global
Atomicity	Redis + a Lua script (or `INCR`) so concurrent requests can't over-count
On store failure	Fail open for general throttling; fail closed for security limits
Response	`429` + `Retry-After` and `X-RateLimit-*` headers

Why it's inline-on-every-request

A rate limiter runs on every request, so its cost is paid by all traffic, all the time. That reframes every choice: the algorithm must be O(1), the store lookup atomic and sub-millisecond, and the failure mode must not take your whole API down. Say the API peaks at 1M req/sec — the limiter must sustain 1M checks/sec at < 1 ms each.

The counting algorithms (the core of the interview)

1. Fixed window counter. INCR a per-window key; reset each window. Dead simple, O(1) — but the boundary burst: a client sends the full limit at 00:00:59 and again at 00:01:00 → 2× the limit in ~1 second. Know this trap.

2. Sliding window log. Store a timestamp for every request (Redis sorted set); drop old ones, count the rest. Perfectly accurate, no boundary burst — but memory grows with volume. Expensive for busy clients.

3. Sliding window counter (the sweet spot). Approximate the rolling window with two fixed-window counts weighted by overlap:

estimated = current_count + previous_count × (overlap fraction)
# 30s into the current minute: prev_count × 0.5 + current_count

O(1) memory, smooths the boundary burst, close enough for almost everything. What many CDNs use.

4. Token bucket (the industry default — Stripe, AWS). A bucket holds up to C tokens, refills at r tokens/sec; each request takes one, empty = reject.

allow(client):
  now = time()
  tokens = min(C, tokens + (now - lastRefill) * r)   # lazy refill
  lastRefill = now
  if tokens >= 1: tokens -= 1; return ALLOW
  return DENY

Stores only {tokens, lastRefill} (O(1)), allows controlled bursts up to C while holding the average at r, refills lazily (no timer).

5. Leaky bucket. FIFO queue processed at a constant rate; overflow rejected. Where token bucket allows bursts, leaky bucket smooths them into a steady stream — useful for shaping traffic to a rate-sensitive downstream.

What to pick: token bucket for a general API limiter; sliding-window counter when you want accuracy without the log's memory. Fixed window only when the boundary burst genuinely doesn't matter.

Making it distributed (the second hard part)

Local counters don't add up. 500 servers each with their own bucket → client gets 500 × limit. Fix: a shared Redis store, one authoritative count.
The read-modify-write race. Two requests hit two servers, both read tokens=1, both allow, both decrement → two through a bucket that had one. Fix: atomicity — INCR for fixed window, a Redis Lua script wrapping read-check-write for token bucket / sliding window (runs atomically, no interleaving).
The Redis round trip on every request. Co-locate + pipeline; or a hybrid local approximation reconciled periodically; or sticky routing (hash each client to a fixed server so its local bucket is authoritative).
Redis as a hot spot / SPOF. Shard counters by clientId, replicate for failover; shard a single extremely hot client's budget across keys.

Fail open vs fail closed

If Redis is unreachable, do you allow everything (fail open — protects availability, risks overload) or block everything (fail closed — protects the resource, risks an outage)? Default to fail open for general throttling; fail closed for security-critical limits like login or payment attempts. It's a one-sentence answer that shows judgment.

I shipped this in production

Our public API peaks at ~3,200 req/sec across tenants and originally had no per-tenant ceiling — a single runaway scraper could push p99 into the seconds and drag every other tenant down. Moving a per-tenant token bucket to the gateway (atomic Redis Lua, 200 burst / 100 req/s):

Metric	Before	After
API p95 latency	480 ms	120 ms
p99 during a single-tenant burst	multi-second spikes	flat, no cross-tenant spike
Blast radius of one abusive tenant	all tenants degraded	isolated (429 + Retry-After)
Per-tenant budget	none	token bucket, 200 burst / 100 req/s

The read-refill-check-decrement is a single atomic Redis Lua script, so concurrent gateway instances can never double-spend a tenant's budget, and the tenant id is read from the verified token (never a caller-supplied argument) so one client can't spend down another's bucket. (Full .NET 9 middleware + Lua script is in the post.)

The model to carry forward

A rate limiter is an algorithm choice wrapped in a distributed-consistency problem. Three habits it teaches: (1) name the boundary burst; (2) make the shared update atomic, always — the read-modify-write race is the bug that quietly lets everyone past; (3) decide the failure mode on purpose.

The full guide has all five algorithms in depth, the full distributed section, the design checklist, the complete production .NET 9 token-bucket middleware + Lua script, and the "when it's overkill" honest section:

https://prepstack.co.in/blog/design-a-rate-limiter-system-design

Originally published on PrepStack.

Design a URL Shortener (bit.ly) — The Complete System Design Walkthrough (with Production .NET Code)

kirandeepjassal-crypto — Tue, 01 Sep 2026 18:33:57 +0000

"Design a URL shortener" is the question almost every system design interview opens with — and that's exactly why it's worth nailing. It looks trivial ("it's just a hashmap"), but the follow-ups are where candidates fall apart: how do you generate a short code with no collisions at a billion URLs? How do you serve 120,000 redirects a second without melting the database? 301 or 302?

This is the condensed walkthrough; the full guide (every step, all three key-generation approaches, the Kafka analytics path, and the full production .NET 9 code) is on my site 👇

Full guide: https://prepstack.co.in/blog/design-a-url-shortener-system-design

The design at a glance

Concern	Decision
Short code	7-char base62 → ~3.5 trillion combinations
Key generation	Key Generation Service (KGS) — pre-generate unique keys, hand them out
Storage	Key-value store (`shortCode → longUrl`), sharded by `shortCode`
Read path	Cache-first (Redis) — 100:1 read:write means the cache does the work
Redirect	301 for performance, 302 if you need per-click analytics
Scale	~1,200 writes/sec, ~120,000 redirects/sec, ~90 TB over 5 years

Estimates decide everything

100M new URLs/day, 100:1 read:write:

Writes:  100,000,000 / 86,400 ≈ 1,160/sec   (~1.2k/sec — trivial)
Reads:   100x writes          ≈ 116,000/sec  (~120k/sec)
Peak (≈2–3x)                  ≈ ~300k/sec
Storage (5 yr): ~180B URLs × ~500 B ≈ ~90 TB

Two takeaways: writes are trivial, and ~120k reads/sec is what forces caching and replication. The redirect path must almost never touch disk.

Why 7 chars? 62^6 ≈ 57B (too few for ~180B URLs); 62^7 ≈ 3.5 trillion (plenty). So 7 it is.

The heart of the problem: generating the short code

Approach A — hash the URL. Truncate MD5/SHA-256 to 7 base62 chars. Problem: truncation will collide, forcing a DB check + re-hash on every write (stateful, slow), and identical URLs collide to the same code. Avoid.

Approach B — counter + base62. Each URL gets the next integer, base62-encoded. Zero collisions by construction, but a single counter is a bottleneck + SPOF, and sequential codes are guessable. Fix the bottleneck by handing out ranges (a coordinator gives each server a block of 10,000).

Approach C — Key Generation Service (what to ship). Pre-generate unique 7-char keys offline into a pool split into unused/used. On a write, grab an unused key and mark it used — O(1), no hashing, no collision check on the request path. Each server checks out a block into memory so it rarely hits the KGS. Run a standby replica; losing an in-memory block is harmless (3.5T keyspace).

The read path is cache-first

Client → LB → stateless app servers
                 │
           [ Redis ] ── hit (~90%+) ──▶ 301/302
                 │ miss
                 ▼
           [ KV store ] ─▶ populate cache ─▶ redirect

Link popularity is heavily skewed, so an LRU Redis cache holding the hot links absorbs the vast majority of the 120k reads/sec. Shard the KV store by shortCode — it's uniformly distributed, so no hot shards.

301 vs 302 — a real trade-off

301 (permanent) lets the browser cache the redirect: subsequent clicks skip your server entirely (fast, cheap, but you lose per-click analytics). 302 (temporary) routes every click through you: full analytics and a changeable target, at the cost of more load. Analytics-driven shorteners lean 302.

Tracking clicks without slowing the redirect

If you chose 302 and analytics matter, never write to an analytics DB on the redirect path. Fire-and-forget onto a queue and return immediately:

GET /{shortCode}
  → look up longUrl (cache)   ~1–2ms
  → emit click event to Kafka  fire-and-forget
  → 302 redirect               returned immediately
        [ Kafka ] → [ workers ] → [ analytics store ]

I shipped this in production

Our report-sharing feature first embedded a 36-char sequential-GUID primary key in the share URL — long, ugly, enumerable, and a SELECT against Azure SQL on every open. Rebuilt as exactly this design (KGS handing out 7-char base62 codes by the block, cache-first .NET 9 endpoint):

Metric	Before	After
Share-link format	36-char sequential GUID	7-char base62
Guessability	Enumerable	Crypto-random, ~3.5T keyspace
Redirect data source	Azure SQL every open	Redis cache-first, SQL only on miss
Cache hit rate	none	~97%
Redirect p95	~180 ms	~5 ms

The concurrency story is one SQL statement — UPDATE TOP (@blockSize) ... OUTPUT inserted.Code WITH (UPDLOCK, READPAST) — so many app servers check out disjoint blocks with no distributed lock, then serve each block from an in-memory queue. (Full KeyGenerationService + cache-first minimal-API redirect code is in the post.)

The model to carry forward

A URL shortener is a key-generation problem stapled to a caching problem. Three habits it teaches: (1) let the read:write ratio pick your architecture — 100:1 means "cache," full stop; (2) generate uniqueness ahead of time — pre-computing keys turns a collision problem into an O(1) hand-out; (3) name the 301 vs 302 trade-off.

The full guide has all three approaches in depth, the base62 code, custom-alias handling, the capacity table, the design checklist, the full production .NET 9 implementation, and the "when this is overkill" honest section:

https://prepstack.co.in/blog/design-a-url-shortener-system-design

Originally published on PrepStack.

How to Crack Any System Design Interview — A Repeatable 8-Step Framework

kirandeepjassal-crypto — Sun, 30 Aug 2026 16:42:18 +0000

Most people don't fail a system design interview because they don't know the technology. They fail because they have no method. They hear "Design Twitter," jump straight to "let's use a database," design one random corner in great detail, ignore the rest, and run out of time with a half-drawn box on the whiteboard. The candidates who pass aren't smarter — they follow a repeatable sequence, out loud, every single time.

This is the condensed framework; the full guide (every step in depth, the building blocks, the numbers to memorize, and a full worked example) is on my site 👇

Full guide: https://prepstack.co.in/blog/how-to-crack-system-design-interview-framework

Why the question is open-ended on purpose

"Design Twitter" has no single right answer, the scope is huge, and you have 45 minutes. That's the point — the interviewer isn't checking whether you memorized Twitter's architecture. They're watching how you navigate ambiguity, make trade-offs, and communicate. Give them a clear, structured walk through the problem and you pass, even if the final design isn't "perfect."

The framework at a glance

Step	What you do	Time (~45m)
1	Clarify requirements (functional + non-functional) and scope down	~5 min
2	Back-of-envelope estimates (QPS, storage, bandwidth)	~5 min
3	API design — the handful of endpoints that matter	~5 min
4	Data model — entities, SQL vs NoSQL and why	~5 min
5	High-level architecture — draw the boxes	~10 min
6	Deep-dive the hard part — the 1–2 interesting things	~10 min
7	Bottlenecks & scaling — cache, shard, replicate, queue	~5 min
8	Trade-offs & wrap-up	~3 min

The steps that actually decide pass/fail

1. Clarify + scope down. Never start designing — start asking. Functional (what it does) + non-functional (scale, latency, consistency, read:write ratio). Then cut ruthlessly to 2–4 features and park the rest out loud. The single most common failure is skipping this and designing the wrong system beautifully.

2. Estimate. You're after order of magnitude, not precision. The shortcut: there are ~86,400 s/day ≈ 10^5, so requests/day ÷ 100,000 ≈ average QPS, and peak ≈ 2–3×.

1,000,000,000 reads/day ÷ 86,400 ≈ 11,600 QPS average
Peak ≈ 3x ≈ ~35,000 QPS

That one number already tells you: no single DB serves this — you need caching, replicas, sharding.

3–4. API + data model. Define the contract first (cursor-based pagination, not offset; explicit auth). Then pick a store and justify it — "tweets are append-heavy, read by key, no joins, so a wide-column store scales better than relational here." The reasoning is graded, not the choice.

5. Draw the architecture. Client → load balancer → stateless app servers → cache/DB → response. Push heavy/slow work (media, notifications, fan-out) onto a queue + workers so the request path stays fast.

6. Deep-dive the ONE hard part. Every "Design X" has 1–2 things that make it interesting; the rest is plumbing:

Problem	The hard part
URL shortener	Short-code generation & collisions
Rate limiter	The algorithm + distributed counters
News feed	Fan-out on write vs read (celebrity problem)
Chat	Real-time delivery, ordering, presence
Uber	Geospatial indexing & matching
Payments	Idempotency & the ledger
YouTube	Transcoding pipeline & CDN

One well-reasoned deep-dive beats ten shallow boxes.

7–8. Bottlenecks + trade-offs. Ask "what breaks first?" → caching (name the invalidation), read replicas, sharding (state the shard key), async queues, CDN, remove single points of failure. Then close by naming the trade-offs you made and what you'd revisit. Raising bottlenecks before the interviewer does is a senior signal.

The ~10 building blocks every problem reuses

Load balancer · cache (Redis) · CDN · database (SQL for consistency, NoSQL for scale; replicas for read scale, sharding for write scale) · message queue (Kafka/SQS) · blob store (S3 — never put video in your DB) · consistent hashing · rate limiter / API gateway. Learn these cold and every "Design X" becomes an assembly problem.

The numbers to memorize

Latency: RAM ~100 ns, SSD random read ~100 µs, same-DC round trip ~500 µs, HDD seek ~10 ms, cross-continent round trip ~150 ms. Memory is fast, disk is slow, network is slower the farther it goes — so cache aggressively and keep data near users.
Powers of two: 2^10 ≈ 1 KB, 2^20 ≈ 1 MB, 2^30 ≈ 1 GB, 2^40 ≈ 1 TB.
Availability: 99.9% ≈ 8.7 h down/year · 99.99% ≈ 52 min · 99.999% ≈ 5 min. Each nine is ~10× harder — ask how many you actually need.

The mental model

A system design interview is a guided conversation about trade-offs, not a test with an answer key. The interviewer is your collaborator, not your examiner. Three habits separate a pass from a fail: clarify and scope before you design, let numbers drive decisions, and communicate relentlessly (no silent whiteboarding). Master the 8 steps, the 10 building blocks, and the handful of numbers, and "Design X" becomes the same well-worn walk applied to a new destination.

The full guide has every step in depth, the 45-minute timeline, the full building-blocks diagram, the complete latency/powers-of-two/QPS tables, a full "Design Pastebin" worked example in one lap, and the where-the-framework-bends honest section:

https://prepstack.co.in/blog/how-to-crack-system-design-interview-framework

Originally published on PrepStack.

React Authentication & Authorization — JWT, Refresh Token Rotation, RBAC, Azure AD, OAuth2 + PKCE (Real Code)

kirandeepjassal-crypto — Sat, 29 Aug 2026 17:06:13 +0000

Auth is the part of a React app where most teams get most of it right and one part dangerously wrong. The wrong part is usually the same: tokens in localStorage, no refresh strategy, role checks scattered through the UI, and a backend that trusts whatever the client sends. It works in dev, passes review, and quietly enables account takeovers in production.

This is the condensed, opinionated production playbook. The full guide (all the code, diagrams, the OAuth2+PKCE walkthrough, MSAL setup, and the architect's checklist) is on my site 👇

Full guide: https://prepstack.co.in/blog/react-authentication-authorization-jwt-refresh-tokens-rbac-azure-ad-oauth2-guide

AuthN vs AuthZ

Two different problems that share a header:

Authentication — who are you? Verified once at login → a token.
Authorization — what can you do? Checked on every request.

JWT — do this right or nothing else matters

A JWT is header.payload.signature. The signature is what makes it trustworthy — without verifying the signature on the server, a JWT is just JSON anyone can make up. The rules that aren't optional:

Short lifetime — 5–15 min. Refresh tokens handle long sessions.
Verify on the server, always — the client decodes for UI hints only; never trust client-side claims for authz.
RS256 (asymmetric) for SPAs — server signs with a private key, APIs verify with the public key.
Always check iss, aud, exp on the server.

Where to store the access token

Storage	XSS-safe?	Verdict
`localStorage`	❌ any XSS reads it	No — one XSS = account takeover
`sessionStorage`	❌ same risk	No
In-memory (module var / state)	✅	Yes — modern best practice
`HttpOnly` cookie	✅ JS can't read it	Yes (needs CSRF token)

The 2026 pattern: access token in memory, refresh token in an HttpOnly cookie. On reload, hit /refresh to mint a new access token. Lost-on-reload is the cost; no-XSS-leak is the benefit.

// auth/tokenStore.ts — in-memory access token
let accessToken: string | null = null;
export const tokenStore = {
  get: () => accessToken,
  set: (t: string | null) => { accessToken = t; },
};

Refresh token rotation + reuse detection — the security cornerstone

Every refresh issues a new refresh token and invalidates the old one. If a revoked token is ever used again, it was stolen → revoke the entire chain immediately.

t=0    RT1 issued at login          valid
t=10m  /refresh with RT1            mint RT2, RT1 revoked
t=20m  /refresh with RT2            mint RT3, RT2 revoked
t=21m  attacker uses stolen RT1     reuse detected -> revoke chain, force re-login

This is OAuth 2.0 Refresh Token Rotation. Auth0, Okta, and Azure AD do it by default; if you roll your own, do this. Use a single in-flight refresh so a burst of 401s doesn't hammer /refresh 50x in parallel:

let pendingRefresh: Promise<string | null> | null = null;
export function tryRefresh() {
  if (pendingRefresh) return pendingRefresh;    // everyone shares one promise
  pendingRefresh = fetch('/api/auth/refresh', { method: 'POST', credentials: 'include' })
    .then(async (r) => r.ok ? (await r.json()).access_token : null)
    .finally(() => { pendingRefresh = null; });
  return pendingRefresh;
}

RBAC — two layers, only one is real

UI LAYER (React)   -> hides buttons the user can't use -> purpose: UX      -> trust: NONE
SERVER LAYER (API) -> rejects requests the user can't make -> purpose: SECURITY -> trust: THE LINE

Client-side role checks are UX, not security. A user can open DevTools, edit React state, and reveal hidden buttons. That's fine — when they click, the server returns 403.

const PERMISSIONS = {
  'post.write':  ['editor', 'admin'],
  'post.delete': ['admin'],
  'billing.edit':['billing_admin', 'admin'],
} as const;

export function useCan() {
  const { user } = useAuth();
  return (p: keyof typeof PERMISSIONS) =>
    !!user && user.roles.some((r) => (PERMISSIONS[p] as readonly string[]).includes(r));
}

// server — same role map, but binding
[Authorize(Policy = "post.delete")]
[HttpDelete("/posts/{id}")]
public Task<IActionResult> DeletePost(string id) { /* ... */ }

The SPA's permission table and the server's policies must derive from the same source of truth. When they drift, security holes appear silently.

OAuth 2.0 + PKCE — the modern login

PKCE (Proof Key for Code Exchange) is the SPA-safe extension that replaced the banned Implicit Flow. The SPA generates a code_verifier, sends SHA256(verifier) as the challenge, and proves ownership at token exchange. Without PKCE, an attacker who intercepts the code could redeem it. If a tutorial uses response_type=token, it's pre-2019 — don't follow it. For production, use the BFF (Backend For Frontend) pattern: a thin server completes the token exchange and sets the refresh token in an HttpOnly cookie the SPA never sees.

Azure AD / Entra ID via MSAL

For B2B / enterprise, Azure AD gives you SSO, MFA, conditional access, audit logs, and app-role claims that map straight to your RBAC — for free. MSAL wraps the OAuth2+PKCE flow and does silent refresh for you. One rule:

cache: { cacheLocation: 'memoryStorage' }   // NOT localStorage, even though MSAL offers it

App Roles show up as a roles claim, so your useCan hook works unchanged. One RBAC table, two enforcement points, one identity source.

Production metrics (90-engineer SaaS migration)

Metric	Before	After
Auth security incidents / qtr	9	0
Auth support tickets / qtr	142	31 (−78%)
Session before re-login	8 h	30 days
Time to detect stolen token	never	< 1s
Custom auth code	~2,400 lines	~600 (−75%)
Time to add a new SSO customer	2 weeks	1 hour

The mental model

Auth is a system, not a feature. The SPA, API, and IdP must agree on one vocabulary (roles, claims, tenant) and one trust boundary (the server). Three habits keep it boring: treat the client as untrusted, use short access tokens + rotating refresh + HttpOnly cookies, and use the platform (Auth0/Azure AD/Cognito) unless you can name a reason that survives a security review.

The full guide has the complete token store + AuthProvider, the apiFetch refresh-on-401 wrapper, route guards, the full OAuth2+PKCE code, MSAL React setup + app-role mapping, the 11-point security fix-list, and the architect's checklist:

https://prepstack.co.in/blog/react-authentication-authorization-jwt-refresh-tokens-rbac-azure-ad-oauth2-guide

Originally published on PrepStack.

Event-Driven Architecture in .NET — Why, How, Real Code (ASP.NET Core + React) and When NOT to Use It

kirandeepjassal-crypto — Thu, 27 Aug 2026 17:20:55 +0000

Most teams reach for event-driven architecture (EDA) because they heard it "scales." Then they discover the hard part: events arrive out of order, get delivered twice, and a bug three services away surfaces as a customer complaint with no stack trace. EDA is powerful — and it trades one set of problems for another.

This is the honest, production version for .NET. This is the condensed take; the full guide (complete architecture diagram, real MassTransit code, the React SignalR live tracker, the tuning playbook, and the when-not-to section) is on my site 👇

Full guide: https://prepstack.co.in/blog/event-driven-architecture-aspnet-core-react-production-guide

What EDA actually is

In request/response, OrderService → (blocks) → PaymentService → (blocks) → InventoryService. If any link is slow or down, the whole chain stalls. In EDA, OrderService emits a fact — OrderPlaced — and moves on. Payment, inventory, email, and analytics all react independently through a broker. The producer doesn't know who's listening, doesn't wait, and doesn't break if a consumer is down. That decoupling is the whole point — and everything good and hard about EDA flows from it.

What it buys you

Kills tight coupling. Want a Slack alert on new orders? SlackService subscribes to OrderPlaced. OrderService never changes. New consumers are added, not integrated — open/closed at the architecture level.
Kills blocking latency. Checkout emits OrderPlaced and returns a 202 in tens of ms; the downstream work runs in parallel, async.
Handles spiky load. A flash sale queues in the broker (load leveling); consumers process at their own pace and you scale the bottleneck one independently.
Independent deployment + a free audit log (the event stream is the history).

What it costs (be honest)

Eventual consistency — the order isn't confirmed yet. If your domain needs strong consistency, EDA fights you.
Duplicate delivery — brokers guarantee at-least-once, not exactly-once. The same event will arrive twice. Every consumer with side effects must be idempotent.
Out-of-order delivery — don't assume order; partition by entity key when ordering matters.
Debugging across the boundary — the failure is "the order never confirmed," cause three hops away. Distributed tracing is mandatory.
Operational complexity — a broker to run, queues to monitor, DLQs to drain.

The two non-negotiables

1. The Outbox. The classic bug: save the order, then publish the event — but the process crashes between them. Now you have an order with no event. Fix: write the event into the same DB transaction as the business data, then a dispatcher publishes it after commit.

db.Orders.Add(order);
await publish.Publish(new OrderPlaced(order.Id, /* ... */));  // through the Outbox
await db.SaveChangesAsync();   // ONE commit: order + outbox event
return Results.Accepted($"/orders/{order.Id}", new { orderId = order.Id, status = "Pending" });

2. Idempotent consumers. At-least-once + retries guarantee duplicates. Charging twice is unacceptable — dedupe on message ID:

if (await _seen.AlreadyProcessed(ctx.MessageId!.Value)) return;  // skip duplicate
var result = await _gateway.ChargeAsync(msg.Total, msg.CustomerId);
await _seen.MarkProcessed(ctx.MessageId.Value);

The React payoff (SignalR, no polling)

NotifyService consumes OrderConfirmed and pushes it to the browser over SignalR; a useOrderStatus hook flips the UI from "Pending" to "Confirmed" in real time as the async events flow through — no polling. The user saw a fast 202, then watches the order tick to Confirmed live.

The production levers (each with a reason)

Lever	Buys you	Trade-off
Outbox	No lost events	One extra table + dispatcher
Idempotency	Safe aggressive retries	A dedupe store (Redis)
Prefetch + concurrency	Per-instance throughput	Tune carefully or OOM
Partitioning (by OrderId)	Ordering + parallelism	Key design; can't reorder later
KEDA autoscaling	Elastic capacity	K8s + autoscaler setup
DLQ + alerts	Poison isolation + visibility	Ops process to drain DLQ
Backpressure	Stability under spike	Lower peak throughput

When NOT to use it

Simple CRUD (a synchronous monolith is faster to build and easier to debug). Strong-consistency transactions (a bank balance correct the instant the call returns). Small teams without ops maturity. Low traffic with no scale problem. In all of these, EDA is complexity with no payoff.

The decision rule: adopt EDA when the cost of coupling and blocking exceeds the cost of eventual consistency and operational complexity. If you can't clearly say which side is heavier, you probably don't need it yet.

The full guide has the complete architecture diagram, the full MassTransit + Azure Service Bus code (Outbox, idempotent consumer, saga completion), the React SignalR tracker end-to-end, all 8 tuning levers with reasoning, and the 10-step incremental adoption playbook:

https://prepstack.co.in/blog/event-driven-architecture-aspnet-core-react-production-guide

Originally published on PrepStack.

Building a ChatGPT-Like App in React — Streaming, OpenAI, RAG, and pgvector (Real Code + Metrics)

kirandeepjassal-crypto — Wed, 26 Aug 2026 18:40:31 +0000

Building a ChatGPT-style assistant looks easy in a demo and breaks in three places when it goes to production: the responses don't stream (users stare at a spinner), the model hallucinates (it has no idea what's in your docs), and your costs explode. The difference between a demo and a shippable assistant is four techniques composed correctly.

I built a real SaaS "ask the docs" assistant in React and measured it. This is the condensed version; the full guide (the streaming route, the RAG pipeline, the vector-store decisions, and every metric) is on my site 👇

Full guide: https://prepstack.co.in/blog/react-ai-chatgpt-like-application-streaming-openai-rag-vector-databases-guide

The result (real SaaS docs assistant, ~3,000 docs, ~50k questions/mo)

Metric	Before (just LLM)	After (streaming + RAG + pgvector)
Hallucination rate	18%	4%
Irrelevant answers	35%	8%
Answer cites a source	0%	96%
"This was helpful"	51%	84%
Time to first token	3,500ms	250ms
pgvector retrieval (p95)	—	65ms
Cost per query	—	$0.003
Support tickets deflected	—	23% of product Qs

The four techniques

1. Streaming — non-negotiable UX, ship it first. A full response is a 3–13s wait; the first token lands in ~250ms. That took time-to-first-content 3,500ms → 250ms and abandon rate 14% → 3%. Use Server-Sent Events, not WebSocket — one-way server→client is all chat needs, and it's what OpenAI's own API uses.

2. OpenAI behind a server route — never the browser. The API key stays server-side, and the route is where rate limiting (per tenant + per user), prompt validation, cost caps, and observability live. Edge runtime streams best; log usage after the stream closes, never blocking on telemetry.

3. RAG stops hallucinations. Retrieve the relevant chunks from your docs, put them in the prompt, instruct the model to answer only from them. Hallucinations 18% → 4%, "helpful" 51% → 84%, and it deflected 23% of incoming support questions. The underrated lever is chunking + retrieval quality, not the model — a tuned RAG pipeline on gpt-4o-mini beats a naive one on gpt-4o, for less money.

4. pgvector is enough for almost everyone in 2026. The Postgres you already run, with an HNSW index → sub-100ms retrieval (p95 65ms) up to ~10M vectors. Resist adding a managed vector DB before you've tried Postgres; reach for Pinecone/Qdrant only at higher scale or specific latency needs.

The architecture

React (useChat) --POST /api/chat (SSE stream)--> Next.js API route
   |                                               1. rate-limit + validate
   |                                               2. embed question (OpenAI)
   |                                               3. retrieve top-k (pgvector cosine)
   |                                               4. build grounded prompt
   <---- tokens stream back -----------------------  5. stream from gpt-4o-mini
                                                    6. log usage + cache

The first SSE event sends the retrieved sources so the UI shows citation chips within ~100ms while the answer streams in.

The economics

Cost per query landed at $0.003. A response cache on the question hash (34% of questions are repeats) saves ~$4,200/month at 1M queries — without it the bill is 50% higher. One warning: watch the cost dashboard daily the first month. A single tenant looping the API can run a five-figure bill before you notice. Set hard per-tenant caps.

The mental model

A production AI assistant is four boring components composed correctly: a streaming UI, a server-side LLM call, retrieval over your own data, and a vector store to make that retrieval fast. None is exotic in 2026 — the engineering is making them work together: fast enough to feel instant, accurate enough to be trusted, cheap enough to scale. Ship streaming + RAG on day one; everything else is optimization.

The full guide has the complete streaming Next.js route, the manual + Vercel-AI-SDK React useChat, the RAG pipeline (chunking, embeddings, pgvector storage & retrieval), the HNSW vs IVF decision, prompt-injection defenses, cost monitoring, and the full latency/cost/quality/reliability tables:

https://prepstack.co.in/blog/react-ai-chatgpt-like-application-streaming-openai-rag-vector-databases-guide

Originally published on PrepStack.

Building Enterprise React Apps with Feature-Based Architecture (Real Code + Production Metrics)

kirandeepjassal-crypto — Mon, 24 Aug 2026 16:27:26 +0000

Every React app that survives long enough hits the same wall: the components/ folder has 240 files, every change touches a dozen of them, three teams step on each other in utils/, new hires take three weeks to find the right hook. The codebase didn't get worse — it got bigger, and the architecture stopped scaling.

The fix is feature-based architecture: organize by capability (billing, users, reports) instead of by kind (components, hooks, services). I migrated a real enterprise SaaS app this way and measured it. This is the condensed version; the full guide (the 4 rules, a complete feature in code, the lazy-load splits, and the migration playbook) is on my site 👇

Full guide: https://prepstack.co.in/blog/enterprise-react-feature-based-architecture-real-code-metrics

The result (same app, 240 components, before + after)

Metric	Before (type-based)	After (feature-based)	Δ
Build time (Vite, cold)	145s	92s	−37%
Initial JS (gzipped)	1.2 MB	380 KB	−68%
Routes loading > 1 MB	14	0	gone
Files touched per PR	12.4	5.1	−59%
Merge-conflict rate	21%	6%	−71%
Onboarding to first PR	18 days	7 days	−61%
Cross-feature bugs/qtr	23	4	−83%

Why type-based folders break

components/ hooks/ services/ works to ~30 components. Past that: ownership is fuzzy ("who owns useUserPermissions?"), every change touches everything, teams collide in utils/, dead code accumulates, and bundle splitting is impossible because billing is scattered across 8 folders. The question that matters — "where does the billing feature live?" — has the answer "everywhere."

The structure: organize by capability

src/
├── shared/        (ui, lib, api — cross-cutting, NO business logic)
├── features/
│   ├── auth/      (api, components, hooks, store, types, index.ts)
│   ├── billing/   (api, components, hooks, store, types, index.ts)
│   ├── users/
│   └── reports/
└── app/           (router, providers — composition root)

Each feature is self-contained with a single public entry point.

The 4 rules that make it work

1. One public index.ts per feature. It exposes 4 exports; the feature has 20+ internal files. That ratio is the boundary.

2. No cross-feature imports except via that index. Enforce with ESLint no-restricted-imports on features/*/* — at PR time, not in code review.

3. Cross-cutting code lives in shared/, with no business logic. Button/Modal → shared/ui. formatInvoice() → features/billing/lib. The test: if it names a domain concept, it's a feature concern.

4. Features depend on shared/ only, never each other. Billing needs the user? It takes a userId, not an import from auth. Autonomy is the point.

The biggest win: natural code-splitting

Because each feature is self-contained, lazy-loading is one line at the composition root:

const BillingRoutes = lazy(() => import('@/features/billing').then(m => ({ default: m.BillingRoutes })));
const AdminRoutes   = lazy(() => import('@/features/admin').then(m => ({ default: m.AdminRoutes })));

A user who never opens /admin/* never downloads the admin code. That's what took the initial bundle 1.2 MB → 380 KB — impossible when billing is scattered across 8 folders.

Migrate incrementally, never a rewrite

Add shared//features//app/ alongside the old folders (they coexist). Move the smallest, most isolated feature first (usually auth). Lock its boundary with ESLint. Repeat per feature, largest pain first. Drain the old folders. Each step ships independently — no big-bang PR. ~3 sprints for one squad in spare cycles, payback in ~6 weeks.

The honest part

Below ~20 components this is bureaucracy — don't impose it. Above ~50 with multiple teams, it's survival. And discipline is the architecture: without the ESLint boundary rule, "feature folders" decays into "type folders with a different name" in six months.

The mental model: type-based folders optimize for "where do I put a hook?" Feature-based folders optimize for "where does this capability live?" Get that right and your app stops getting harder to change as it gets bigger — the actual definition of architecture working.

The full guide has the 4 rules in depth, a complete billing feature end-to-end (types, api, hooks, components, routes, tests), the bundle-split output, the state-per-feature pattern, the migration playbook, and the full metrics matrix:

https://prepstack.co.in/blog/enterprise-react-feature-based-architecture-real-code-metrics

Originally published on PrepStack.

React Design Patterns Every Architect Should Know in 2026 (Real Code + Production Metrics)

kirandeepjassal-crypto — Sat, 22 Aug 2026 07:18:49 +0000

A senior React developer can write any component. An architect knows which pattern to reach for, when, and (crucially) when not to. Picking the wrong abstraction is one of the most expensive mistakes in a frontend codebase — it locks in shapes that end up everywhere, and untangling them costs months.

So I took a real production SaaS dashboard and consolidated it on the right patterns, measuring the impact. This is the condensed version; the full guide (all six patterns with before/after code, the composition diagram, the decision flow, and anti-patterns) is on my site 👇

Full guide: https://prepstack.co.in/blog/react-design-patterns-container-hooks-compound-render-props-hoc-provider-guide

The result (same app, before + after)

Moving from "HOC + render-props everywhere" → "Hooks + Compound + Provider":

Metric	Before	After	Δ
Component code lines	28,400	20,500	−28%
Avg component reuse	2.1×	5.8×	+176%
HOCs in codebase	14	2	−86%
Render-prop components	22	4	−82%
Custom hooks	8	47	+
Prop-drilling bugs/qtr	11	4	−63%
Storybook without mocks	38%	84%	+121%
New-dev first feature	9 days	5 days	−44%
DevTools tree depth	18	9	−50%

The 6 patterns, in one line each

1. Custom Hooks — the most important pattern. They replaced most of what HOCs and render props did. The rule: if you can name the behavior as a noun ("the searchable list", "the form draft"), it's a hook. Master these first.

2. Compound Components — HTML-shaped, composable APIs. <Tabs><Tab/></Tabs> sharing state via context. The whole Radix/shadcn design language is built on this. Best for design-system components.

3. Provider Pattern — app-scope concerns. Theme, auth, locale, feature flags. Still essential — but not a poor man's state manager (Context re-renders every consumer; use Zustand for high-frequency state).

4. Container/Presentation — now Server + Client Components. The principle (data vs view) survived; the syntax modernized. Server Component = container, 'use client' = presentation. Splitting them took Storybook-without-mocks 38% → 84%.

5. Render Props — mostly obsolete. Hooks beat it on nesting, composition, and TS. Survives only for true inversion-of-control (virtualizers, <Form>{form => ...}</Form>).

6. HOC — the demoted one. Wrapper-hell, prop collisions, messy types. If a new HOC appears in a 2026 PR, ask "could this be a hook?" — almost always yes. Survives only for legacy class components and library boundaries.

Where the wins came from

Custom hooks replacing HOC + RP duplication      ~38%
Server/Client (modern container/presentation)     ~22%
Compound components in the design system          ~16%
Providers replacing prop-drilling                  ~12%
Test-without-mocks (presentational components)     ~8%
Smaller DevTools tree (HOC removal)                ~4%

The mental model

Patterns aren't a checklist to use — they're a vocabulary for shapes of problems. Know which shape you're looking at, reach for the matching pattern deliberately (before someone reinvents it badly in a PR), and the team stops re-solving the same thing six ways. A team with a coherent pattern vocabulary moves 2× faster than one without.

Three habits that make it work: (1) write the vocabulary down (a patterns.md), (2) prefer hooks until forced otherwise, (3) compose patterns — a real app uses all six where each fits, and can be fully coherent without ever writing a new HOC.

The full guide has all six patterns with before/after code, the composition diagram, the full metrics table, the decision flow, and the anti-patterns table:

https://prepstack.co.in/blog/react-design-patterns-container-hooks-compound-render-props-hoc-provider-guide

Originally published on PrepStack.

React Performance Optimization — Every Technique with Before/After Code + Real Production Metrics

kirandeepjassal-crypto — Fri, 21 Aug 2026 05:01:18 +0000

"Make it faster" is the vaguest ticket in frontend. Faster what? Measured how? Most React perf advice is a pile of useMemo everywhere and a vague feeling of virtue — with no numbers to prove it helped (and sometimes it made things worse).

So I took a real production-shaped app — a SaaS analytics dashboard with a 12,000-row table, live filters, and charts — profiled its actual bottlenecks, and fixed them one technique at a time, measuring before/after each. This is the condensed version; the full guide (every technique with before/after code, diagrams, and the full metrics matrix) is on my site 👇

Full guide: https://prepstack.co.in/blog/react-performance-optimization-techniques-before-after-metrics-guide

The result (same app, profiled before + after)

Metric	Baseline	After	Improvement
LCP (load)	4.1s	1.3s	68% faster
INP (interactivity)	420ms	90ms	79% faster
JS bundle (gzipped)	880 KB	240 KB	73% smaller
Filter re-render	678ms	18ms	97% faster
Table mount	1,400ms	45ms	97% faster
Scroll FPS	22	60	smooth
Memory (heap)	310 MB	120 MB	61% less

Where the wins actually came from

Virtualization             ~35%
Code splitting + bundle     ~25%
Server Components / SSR      ~18%
Re-render elimination        ~12%
Concurrent features           ~6%
Smaller wins                  ~4%

The top three structural techniques delivered ~78% of the total gains. Scattering useMemo everywhere — what most perf posts lead with — was the smallest bucket.

The techniques, briefly

1. Virtualization — the biggest single win. The user sees ~30 rows; rendering the other 11,970 is waste. @tanstack/react-virtual took DOM nodes 96,000 → ~320. Virtualize any list over ~200 rows.

2. Code-splitting + bundle trimming. React.lazy + Suspense for the heavy export/settings modals (most users never open them), plus moment→date-fns and lodash→lodash/x. Bundle 880KB → 240KB, parse 2.3s → 0.7s.

3. Server Components / SSR / streaming. Fetch on the server, stream the shell instantly. Time-to-first-content 1.1s → 0.2s, client JS ~60% less, fetch waterfall eliminated.

4. Re-render elimination. memo + stable useCallback/useMemo stopped the chart panel re-rendering on every keystroke. But memo isn't free — apply where the Profiler shows a real repeated expensive re-render, not everywhere.

5. Concurrent features. useTransition / useDeferredValue keep the input snappy while filtering — INP 180ms → 90ms, zero dropped frames.

6. React 19 Compiler. Auto-memoizes for you, so most manual useMemo/useCallback becomes noise you can delete.

The mental model

React performance isn't "add useMemo and hope." It's a loop: profile → find the real bottleneck → apply the right technique → re-measure → keep it only if the number moved. Reach for structural wins (virtualize, split, server-render) first — they deliver 10× what scattered memoization does.

The full guide has every technique with before/after code, the diagrams, the complete metrics matrix, and the decision flow:

https://prepstack.co.in/blog/react-performance-optimization-techniques-before-after-metrics-guide

Originally published on PrepStack.

React State Management in 2026 — Context API vs Redux Toolkit vs Zustand vs Jotai (Same Cart, Real Code + Benchmarks)

kirandeepjassal-crypto — Wed, 19 Aug 2026 18:20:45 +0000

The React state-management debate has produced more bad takes than any other frontend topic. "Just use Context." "Redux is dead." "Zustand for everything." "Jotai is the future." All four are partially right and partially dangerous, depending on what you're building.

So instead of arguing, I built the same shopping cart — derived totals, async fetch, localStorage persistence, three subscribing components — in all four libraries, and benchmarked it. This is the condensed version; the full guide (all four implementations with real code, the complete matrix, and the decision flow) is on my site 👇

Full guide: https://prepstack.co.in/blog/react-state-management-context-redux-toolkit-zustand-jotai-comparison-guide

The one benchmark that reframes everything

1,000 components subscribed to one store. Update one value. How many re-render?

Library	Components re-rendered	Wall-clock
Context (single value)	1,000 (all)	42 ms
Context (split into 5)	~200	12 ms
Redux Toolkit (selectors)	1	2.1 ms
Zustand (selector)	1	1.8 ms
Jotai (atom)	1	1.5 ms

Context without splitting re-renders the world. The other three are within margin of each other — meaning the real differences are boilerplate and DX, not render speed.

The four, in one line each

Context API — built-in, 0 KB, but every consumer re-renders on any change. Right for theme/auth/locale; wrong for anything busy or with many subscribers.

Redux Toolkit — ~22 KB, most boilerplate, but RTK Query (caching, dedupe, invalidation), middleware, and time-travel DevTools are best-in-class. Payoff scales with app complexity.

Zustand — ~3 KB, no provider, selectors built in, a full store (state + async + persistence) in ~25 lines. The modern default for most 2026 apps.

Jotai — state is many small atoms, each with its own subscriber list. Smallest blast radius per update; ideal for forms and derived graphs.

Real production migration (same e-commerce app)

Metric	Context-everywhere	Redux Toolkit	Zustand
Initial JS (gzipped)	412 KB	438 KB	390 KB
Add-to-cart INP	180 ms	95 ms	88 ms
Filter-by-category render	290 ms	60 ms	52 ms
Lines of store code	~3,200	~4,100	~1,650
New-dev "first feature shipped"	6 days	11 days	4 days

A separate forms project moving Redux → Jotai dropped re-render counts ~75% thanks to per-atom granularity.

The plot twist most debates miss

In 2026, most of what people call "global state" is actually server state — API data that belongs in TanStack Query (or RTK Query), not any of these four. Query libs handle caching, dedupe, background refresh, retries, optimistic updates. Put server data there and an entire class of cache-invalidation bugs disappears. The four libraries above only fight over the remaining ~20% of true client state.

The rule

Separate server state from client state first. Then: Context for provider-shaped global config, Zustand for most client state, Jotai when it's atomic, Redux Toolkit when you need its ecosystem. Do that and "state architecture" stops being a 3-week debate and becomes a 30-second decision per piece of state.

The full guide has all four cart implementations with real code, the complete comparison matrix, the benchmark methodology, and the decision flow:

https://prepstack.co.in/blog/react-state-management-context-redux-toolkit-zustand-jotai-comparison-guide

Originally published on PrepStack.