DEV Community: kirandeepjassal-crypto

We Replaced REST with Kafka and Cut API Failures 90% — .NET 9 Event-Driven Architecture

kirandeepjassal-crypto — Sun, 14 Jun 2026 13:36:35 +0000

TL;DR — We swapped Mattrx's inter-service REST calls for Kafka topics (multi-tenant marketing analytics SaaS, .NET 9 / ASP.NET Core, Azure SQL, ~3,200 req/sec peak). Over 8 weeks: end-to-end ingestion failures 1.9% → 0.18% (−90%), ingestion p95 180 ms → 8 ms (−96%), events lost on downstream outage tens of thousands → 0, cascading-failure incidents ~3/month → 0, time to add a new consumer ~1 sprint → ~1 day.

🎥 3-minute video walkthrough: https://youtu.be/O21rbuQdM1Y
👉 Full deep-dive (architecture, code, pre-adoption checklist, when NOT to reach for Kafka): https://prepstack.co.in/blog/replaced-rest-with-kafka-cut-failures-90-percent

The one mental shift

The reflex in a .NET shop is: service A needs something to happen in service B, so A calls B's REST endpoint and waits. That's correct for a query ("give me this tenant's plan") — A genuinely needs the answer. It's wrong for an event ("this campaign event occurred") — A doesn't need anything back, yet it's now blocked on B, C, and D being healthy.

Distinguish commands/queries (need an answer → REST) from events (fire-and-forget → log). A synchronous call makes the caller's uptime a function of the callee's uptime. An event published to a durable log decouples them in time — the producer succeeds the instant the event is durably written, consumers process whenever they can.

Once you stop treating "something happened" as a function call and start treating it as a fact appended to a log, cascading failures, retry storms, and burst overload mostly disappear — because nothing downstream is on the request's critical path anymore.

Before — synchronous REST chain (the chain that breaks)

customer site ──► Collector ──► Enrichment ──► Analytics ──► Persister
                  (waits)       (waits)       (waits)      (waits)

// BEFORE — the collector waits on the whole chain. Any failure loses the event.
public async Task<IResult> Collect(CampaignEvent ev, CancellationToken ct)
{
    var enriched = await _enrichClient.EnrichAsync(ev, ct);  // can fail
    await _analyticsClient.RollupAsync(enriched, ct);        // can fail
    await _persistClient.SaveAsync(enriched, ct);            // can fail
    return Results.Ok();                                      // only if ALL three succeed
}

Availability multiplies. Four 99.9%s in series = ~99.6% uptime. Analytics slow at month-end → Collector times out → customer's event is gone → customer retries → MORE load on the struggling service → retry storm.

After — Kafka log decouples the pipeline

customer site ──► Collector ──► [Kafka: events.raw]
                  returns 202        │
                  in ~8ms            ├──► [analytics group]   (independent)
                                     ├──► [persister group]   (independent)
                                     └──► [enrichment group]  (independent)

// AFTER — produce ONE event to Kafka and return. No downstream on the critical path.
public async Task<IResult> Collect(CampaignEvent ev, CancellationToken ct)
{
    var msg = new Message<string, byte[]> {
        Key   = ev.TenantId.ToString(),                  // per-tenant ordering
        Value = JsonSerializer.SerializeToUtf8Bytes(ev),
    };
    await producer.ProduceAsync("events.raw", msg, ct);  // durable, ~ms
    return Results.Accepted();                            // 202 — collector p95: 8 ms
}

The collector succeeds the instant the event is in the log. The customer NEVER waits on a consumer. Analytics down? Its consumer group lags and catches up later. Zero loss, zero customer impact.

The consumer — groups, manual commit, retry, DLQ

Three things matter: a consumer group (so partitions parallelize), manual offset commit (commit only after successful processing — at-least-once delivery), and a retry + dead-letter path (so a poison message can't block the partition forever).

protected override async Task ExecuteAsync(CancellationToken ct)
{
    consumer.Subscribe("events.raw");
    while (!ct.IsCancellationRequested)
    {
        var result = consumer.Consume(ct);
        var ev = JsonSerializer.Deserialize<CampaignEvent>(result.Message.Value)!;
        try {
            await rollup.ApplyAsync(ev, ct);                              // do the work
            consumer.Commit(result);                                       // ✅ commit AFTER success
        }
        catch (TransientException) when (Attempts(result) < 5) {
            await producer.ProduceAsync("events.retry", result.Message, ct);
            consumer.Commit(result);
        }
        catch (Exception ex) {
            log.LogError(ex, "Poison → DLQ at offset {Offset}", result.Offset);
            await producer.ProduceAsync("events.dlq", result.Message, ct);
            consumer.Commit(result);                                       // don't block the partition
        }
    }
}

Consumer lag is the one health metric. If lag climbs, the consumer can't keep up. Scale it. The producer is untouched.

The outbox — atomic produce with a DB write

There's one trap. If the same handler writes to Azure SQL and produces to Kafka, those are two systems. A crash between them loses or duplicates the event. For anything tied to a committed DB change, use the outbox pattern: write the event to an outbox table in the same SQL transaction as the business data; a background relay reads unsent rows and publishes them.

// Atomic: the campaign row AND the event commit in ONE SQL transaction.
await using var tx = await db.Database.BeginTransactionAsync(ct);
db.Campaigns.Add(campaign);
db.Outbox.Add(new OutboxMessage(
    Topic: "events.raw",
    Payload: JsonSerializer.Serialize(ev)));
await db.SaveChangesAsync(ct);
await tx.CommitAsync(ct);
// Background relay reads unsent outbox rows, produces to Kafka, marks them sent.

Dual-write inconsistencies (the "DB says published, no event fired" bug class) → 0.

Idempotent consumers — because delivery is at-least-once

Kafka gives you at-least-once delivery. A consumer can crash after processing but before committing and reprocess on restart. So consumers must be idempotent. The simplest tool is a dedup key with a unique constraint.

public async Task ApplyAsync(CampaignEvent ev, CancellationToken ct)
{
    var firstTime = await _db.ProcessedEvents
        .ExecuteInsertIfAbsentAsync(ev.Id, ct);                 // unique index on EventId
    if (!firstTime) return;                                     // duplicate → no-op, safe

    await _db.Aggregates.IncrementAsync(ev.CampaignId, ev.Type, ct);
}

At-least-once delivery + idempotent processing = effectively-once, and it's far simpler than chasing true exactly-once.

The two superpowers REST never gave us

Replay. A bug corrupted yesterday's analytics rollup? Reset that one consumer group's offset and reprocess. The other groups are untouched. The raw events are still in the log — the log is the source of truth.

kafka-consumer-groups --bootstrap-server $BROKERS --group analytics \
  --reset-offsets --to-datetime 2026-06-10T00:00:00.000 --topic events.raw --execute

Adding a consumer for free. When we shipped fraud scoring, we created a new consumer group on the same events.raw topic. The producer didn't change. ~1 day instead of ~1 sprint.

Aggregate metrics

Metric	Before (REST)	After (Kafka)	Delta
Ingestion failures (incident windows)	1.9%	0.18%	−90%
Events lost on downstream outage	tens of thousands	0	eliminated
Ingestion p95	180 ms	8 ms	−96%
Cascading-failure incidents / mo	~3	0	eliminated
Retry-storm load during incidents	severe	none (202 + walk away)	eliminated
Time to add a new consumer	~1 sprint	~1 day	−80%+
Replay a bad day of processing	impossible	one command	new
Dual-write inconsistencies (outbox)	recurring	0	eliminated

Most of the win isn't throughput — it's failure isolation. The producer succeeds against a log that's almost always up, and every downstream problem became "a consumer is lagging" instead of "the pipeline is down and we're losing data."

When NOT to reach for Kafka (honest section)

Don't replace request/response with Kafka. If the caller needs the answer, that's a query — REST/gRPC is correct.
Kafka is operational weight. Brokers, partitions, schema registry, lag monitoring. For modest volume, Azure Service Bus or a DB-backed queue gives most of the decoupling with far less to operate. We used managed Kafka (Confluent Cloud) precisely because a 5-person team doesn't run brokers.
"Exactly-once" is a trap. Plan for at-least-once + idempotent consumers.
Ordering is per-partition, not global. Design your key around the ordering you actually need.
You traded synchronous errors for asynchronous lag. Watch lag, or you've hidden the problem.
On Azure, weigh Service Bus / Event Hubs first. Kafka was a deliberate choice (replay + ecosystem), not a default.

The mental model in one line

A synchronous call couples you to the callee being up; an event in a log couples you to the log being up. For anything that's "this happened" rather than "tell me this," publishing to a durable log decouples producers from consumers in time — and most of resilience, burst absorption, and extensibility falls out of that one change.

3-minute video walkthrough on YouTube: https://youtu.be/O21rbuQdM1Y

Full deep-dive with architecture diagrams, the complete outbox teardown, idempotency patterns, replay commands, and the honest list of when NOT to reach for Kafka:

👉 https://prepstack.co.in/blog/replaced-rest-with-kafka-cut-failures-90-percent

If this saved you from a "the pipeline went down at 3 AM" page, a ❤️ or 🦄 helps it reach more backend engineers.

What's the worst cascading-failure incident you've inherited because someone Kafka-ed a query — or REST-ed an event?

Our Azure Bill Spiked Overnight — Here's Exactly How We Cut It 60% (7 Real Fixes)

kirandeepjassal-crypto — Sat, 13 Jun 2026 12:12:05 +0000

Originally published on PrepStack. Cross-posting the TL;DR here.

Finance pinged us on a Monday: our Azure bill was up ~150% month-over-month and still climbing — and nobody had shipped a "big" feature. This is the investigation on a real production SaaS (.NET 9 / ASP.NET Core, Angular 19, ~110k MAU, ~3,200 req/sec on Azure): the seven causes, and the fixes that cut the bill 60%.

Where the money went (before -> after)

Cost driver	Spiked	After fix	What it was
Log / telemetry ingestion	$3,100/mo	$340/mo	A Debug log level left on -> GBs/day to App Insights
Compute (autoscale)	$3,400/mo	$1,500/mo	Scale-out rule, no scale-in
Orphaned resources	$1,900/mo	$0	Load-test env + unattached disks/IPs
Egress / bandwidth	$1,200/mo	$280/mo	Large files, no CDN
SQL + Redis	$1,600/mo	$900/mo	Premium tiers + no reservations
Storage transactions	$500/mo	$190/mo	Millions of tiny blob ops, hot tier
AI / LLM tokens	$400/mo	$190/mo	Uncached RAG, oversized model
Total	~$12,100/mo	~$4,700/mo	-60%

What it covers

Turning the lights on first: tagging, a cost dashboard, anomaly alerts
The diagnostic queries (az consumption, KQL log-ingestion-by-source)
Before/after config for each fix (adaptive sampling, autoscale Bicep, blob lifecycle, CDN + compression, LLM caching + model routing)
A FinOps checklist so it doesn't recur
The honest limits of cost optimization

The lesson: most runaway bills are a visibility problem, not an architecture one — two config mistakes and some deleted waste did most of the work. ~3 days to fix, paid back in ~2.

Full post with real Azure config, queries, and dollar figures: https://prepstack.co.in/blog/azure-bill-spiked-how-we-cut-it-60-percent

.NET 11 vs .NET 10: We Benchmarked Both on a Real Production App (Should You Upgrade?)

kirandeepjassal-crypto — Fri, 12 Jun 2026 19:35:58 +0000

Originally published on PrepStack. Cross-posting the TL;DR here.

We run a multi-tenant analytics SaaS on ASP.NET Core (~110k MAU, ~3,200 req/sec peak, ~95k LOC) and benchmarked .NET 9, .NET 10 (current LTS), and .NET 11 previews on the same harness and the same production workload — not synthetic microbenchmarks.

The numbers (9 -> 10, GA, near-zero code changes)

Metric	.NET 9	.NET 10 (GA)	.NET 11 (preview)
Throughput / instance	baseline	+11%	+6-9% (early)
API p95	132 ms	120 ms	-5-7% (early)
Working set / instance	415 MB	380 MB	a few MB less
AOT cold start	84 ms	61 ms	~55 ms (early)
AOT image size	41 MB	33 MB	~30 MB (early)
Language	C# 13	C# 14	C# 15 (preview)

What it covers

Runtime/JIT free wins (AVX10.2, devirtualization, loop opts)
GC/memory (DATAS right-sizing the heap)
ASP.NET Core built-in OpenAPI + minimal-API validation
C# 14: the field keyword + extension members (~700 LOC deleted)
Native AOT startup & container size
Microsoft.Extensions.AI becoming first-class
The actual 9 -> 10 migration (~1.5 engineer-days for 95k LOC)

Verdict: upgrade to the LTS for the free, measured wins; pilot the .NET 11 preview in CI, ship after GA (Nov 2026). And benchmark your hot paths — generic benchmarks don't reflect your workload.

Full post with before/after code and the decision checklist: https://prepstack.co.in/blog/dotnet-11-vs-dotnet-10-benchmarked-production

Angular State Management in 2026 — NgRx, Signals, NGXS, Akita Compared (with Bundle + LOC Numbers)

kirandeepjassal-crypto — Thu, 11 Jun 2026 16:05:37 +0000

TL;DR — We rebuilt Mattrx's state layer (Angular 19, 22k LOC TS, marketing analytics SaaS) over 8 months: state-management LOC 8,400 → 3,100 (-63%), state-related bundle 38 KB → 18 KB, /campaigns re-renders per keystroke 47 → 3. The win wasn't picking the "right" library. It was picking the right library for each kind of state.

👉 Full deep-dive (same /campaigns feature implemented six ways with code, bundle table, LOC counts, re-render measurements, and the Mattrx production layout): https://prepstack.co.in/blog/angular-state-management-comparison-ngrx-signals-ngxs-akita-guide

The mental model first

Most teams treat state as one thing. There are four kinds, and each has a different right answer:

Local UI state — dropdown open, active tab, current input → Signal in the component
Server cache — list of campaigns from the API → toSignal(http.get(...)) or NgRx Entity
Shared feature state — selected rows, bulk-edit draft → Signal in a feature service
App-wide workflow — multi-step state with audit log, time-travel, DevTools → NgRx (SignalStore or classic)

Trying to use one library for all four — which everyone tried with NgRx around 2019 — is what generated the "NgRx is too much boilerplate" backlash. The library wasn't wrong; the scope it was applied to was.

The same /campaigns feature, 6 ways

Approach	Bundle (gzip)	LOC	Files	Mattrx verdict
Pure Signals	0 KB	70	2	Default — covers 80% of state in Mattrx
NgRx SignalStore	~6 KB	75	2	Where new NgRx code goes in 2026
Akita	~10 KB	100	4	Deprecated (maintenance mode since 2023)
NGXS	~14 KB	140	2	Not adopted — no concrete win over SignalStore
NgRx ComponentStore	~5 KB	—	—	Feature-local heavy workflows
NgRx classic	~25 KB (+Effects+Entity)	210	5	Audit-trailed mutations, classic Redux pattern

Re-render granularity (the surprising win)

The big jump isn't picking NgRx vs Signals — it's moving to Signals at all, regardless of library wrapping them:

Approach	Re-renders / keystroke
`BehaviorSubject` + `	async`
NgRx classic + `select` Observable	47 (one per consumer)
NgRx classic + `store.selectSignal()`	3
NgRx SignalStore	3
Pure Signals	3

store.selectSignal() on classic NgRx gives you the same re-render granularity as pure Signals. So if you're already on NgRx classic, you don't need to migrate — just switch your selectors.

Pure Signals — the 2026 default

The whole /campaigns service in 70 lines:

@Injectable({ providedIn: 'root' })
export class CampaignsService {
  private http = inject(HttpClient);

  // Box 1 — local UI state
  readonly query    = signal('');
  readonly selected = signal<Set<string>>(new Set());

  // Box 2 — server cache (debounced via RxJS at boundary)
  readonly campaigns = toSignal(
    toObservable(this.query).pipe(
      debounceTime(200),
      distinctUntilChanged(),
      switchMap(q => this.http.get<Campaign[]>(`/api/campaigns?q=${encodeURIComponent(q)}`)),
    ),
    { initialValue: [] as Campaign[] },
  );

  readonly filtered      = computed(() => this.campaigns());
  readonly selectedCount = computed(() => this.selected().size);
  readonly canBulkAct    = computed(() => this.selectedCount() > 0);

  archive(id: string) {
    // optimistic — http.post + roll back on error
    this.http.post(`/api/campaigns/${id}/archive`, {}).subscribe({ error: () => {} });
  }

  toggleSelect(id: string) {
    this.selected.update(s => {
      const next = new Set(s);
      next.has(id) ? next.delete(id) : next.add(id);
      return next;
    });
  }
}

That's the whole shared state layer. No actions, no reducers, no selectors, no effects, no entity adapter.

When NgRx still wins

For the /campaigns workflow (queue, retry, audit log surfaced in /inbox), Mattrx kept NgRx — specifically the SignalStore flavor:

export const CampaignsStore = signalStore(
  { providedIn: 'root' },
  withState({ items: [] as Campaign[], selected: new Set<string>() }),
  withMethods((store, api = inject(CampaignsApi)) => ({
    async archive(id: string) {
      const before = store.items();
      patchState(store, { items: before.filter(c => c.id !== id) });
      try { await api.archive(id); }
      catch { patchState(store, { items: before }); }
    },
  })),
  withHooks({ onInit: store => /* load + websocket subscribe */ }),
);

Same DevTools (withDevtools()), same time-travel, but the boilerplate gap with pure Signals is now 5 LOC, not 140.

The decision tree

START — "where does this state belong?"
  │
  ▼
Is the state local to ONE component and dies with it?
  ├── YES → SIGNAL in the component
  │
  └── NO → Is it server data (fetched, cached, invalidated)?
            ├── YES → toSignal(http.get(...)) — or NgRx Entity if complex
            │
            └── NO → Is it shared across components in one feature?
                      ├── YES, simple → SIGNAL in a feature service
                      ├── YES, complex workflow → NgRx ComponentStore
                      │
                      └── NO → Shared ACROSS features with audit / DevTools / time-travel?
                                ├── YES, new code     → NgRx SignalStore
                                ├── YES, legacy code  → NgRx classic
                                └── YES, on NGXS today → stay on NGXS
                                NO?                    → you may not need a store

The Mattrx production layout (after the cleanup)

apps/customer/
├── core/auth                       → Signal<User>  (pure Signal)
├── core/config                     → Signal<Config> (pure Signal)
├── features/dashboard              → Signals + computed (no library)
├── features/campaigns              → NgRx SignalStore (workflow + DevTools needed)
├── features/inbox                  → Signals + RxJS (WebSocket via toSignal)
├── features/inbox/archive-search   → Akita (LEGACY — migrating to SignalStore)
├── features/reports                → NgRx ComponentStore (heavy local workflow)
├── features/settings-team          → Signals (simple forms)
├── features/settings-billing       → NgRx classic (audit log + cross-feature notifications)
└── shared/data-access              → toSignal(http.get(...)) wrappers

Three NgRx flavors + Signals + one legacy Akita feature. That's fine. The lesson isn't to standardize on one library — it's to pick the minimum viable abstraction per kind of state.

The 2026 mental rule of thumb

Signals for state. RxJS for streams. NgRx SignalStore when the state is shared, workflow-heavy, and benefits from DevTools / time-travel.

Full writeup with all 6 code samples (classic NgRx with Actions+Reducers+Effects, NGXS with @State decorator, Akita query API, ComponentStore for feature-local), the complete bundle table, re-render benchmarks, DevTools comparison, and the Mattrx state-cleanup numbers:

👉 https://prepstack.co.in/blog/angular-state-management-comparison-ngrx-signals-ngxs-akita-guide

If this saved you an argument in a code review, a ❤️ or 🦄 helps it reach more Angular devs.

What state library does your Angular app use today, and would you pick the same in 2026?

10 Async/Await Mistakes That Kill ASP.NET Core API Performance (2026 Production Audit)

kirandeepjassal-crypto — Tue, 09 Jun 2026 16:34:13 +0000

TL;DR — We took Mattrx (multi-tenant marketing analytics SaaS, Angular 19 + .NET 9, 6 Azure App Service instances, 110k MAU) from 1,200 RPS → 4,500 RPS per instance in a 2-week async audit. Same code. Same SQL. Same Azure tier. The fix was 10 async/await mistakes that the compiler doesn't catch.

👉 Full deep-dive (with before/after code for all 10, the symptom in Application Insights, and the exact dotnet-counters reading that exposes each one): https://prepstack.co.in/blog/async-await-mistakes-that-kill-aspnet-core-api-performance-guide

The mental model first

async/await doesn't make code faster. It makes threads available.

ASP.NET Core's threadpool has ~30 worker threads by default. If you block one (with .Result, .Wait(), lock across await), the 31st request queues. At 200 concurrent requests, you're starving. CPU sits at 30% while latency climbs to 4 seconds.

Every mistake below is one of:

Blocking a thread instead of releasing it.
Doing sequential I/O when parallel I/O is possible.
Allocating a state machine you don't need.
Letting work leak outside its scope.

The 10 mistakes (ranked by what they cost us)

#	Mistake	Symptom	Mattrx win
1	`.Result` / `.Wait()` (sync-over-async)	Thread-pool starvation, random deadlocks	1,200 → 4,500 RPS
2	`async void`	Unhandled exceptions crash the process	3 weekly crashes → 0
3	Sequential awaits where parallel works	`/api/import` 8.2s when 1.4s was possible	p95 8.2s → 1.4s
4	`Task.Run` on a request thread	Wastes a slot to "offload" already-async work	12% CPU at peak → 4%
5	Missing `CancellationToken`	Orphaned requests run after client gave up	240 weekly TaskCanceled → 6
6	`async` keyword on methods that don't `await`	Pure state-machine allocation	-40% allocations on hot paths
7	Fire-and-forget without error capture	Silent failures, data corruption later	18 weekly "phantom errors" → 0
8	Awaiting in tight loops instead of batching	N round-trips when 1 would do	`/api/webhook/replay` 9.4s → 720ms
9	Holding `lock` across `await`	Doesn't span awaits → race conditions	4 prod incidents → 0
10	`ValueTask<T>` misuse (or absence in hot paths)	UB if awaited twice; missed alloc savings	-28% allocations in hot path

Mistake #1 in detail (the one that delivered ~70% of the win)

The pattern that compiles cleanly and starves your threadpool:

// ❌ Inside a synchronous method that "needs" an async result
public Campaign LoadCampaign(Guid id)
{
    return _db.Campaigns.FirstAsync(c => c.Id == id).Result;
}

// ❌ The "I'll just wait here" anti-pattern
public IActionResult Get(Guid id)
{
    var task = _campaigns.LoadAsync(id);
    task.Wait();
    return Ok(task.Result);
}

What this does at 100 concurrent requests:

Thread 1: blocked on DB roundtrip (200ms)
Thread 2: blocked on DB roundtrip (200ms)
...
Thread 28: blocked on DB roundtrip (200ms)
Thread 29: not yet allocated by ThreadPool
Request 30+ — queued. Latency climbs from 200ms → 4 seconds.

The fix is the boring one: async all the way.

// ✅ The whole chain is async
public async Task<Campaign> LoadCampaignAsync(Guid id, CancellationToken ct)
{
    return await _db.Campaigns.FirstAsync(c => c.Id == id, ct);
}

public async Task<IActionResult> Get(Guid id, CancellationToken ct)
{
    return Ok(await _campaigns.LoadAsync(id, ct));
}

We had 11 sync-over-async call sites in the codebase. Fixing all 11 was ~70% of the throughput win.

The detection arsenal

The first hour of any async investigation is the same five commands:

# Step 1 — confirm it's an async/threadpool issue
dotnet-counters monitor -p <pid> System.Runtime
# Watch:
#   threadpool-queue-length > 0 sustained          → starvation
#   threadpool-thread-count climbing > 50          → reactive growth (.Result somewhere)
#   monitor-lock-contention-count > 1k/sec         → lock across await

# Step 2 — find the BLOCKER
dotnet-stack report -p <pid>
# Look for "Task.GetAwaiter().GetResult()" in stacks

# Step 3 — find the LEAK
# In Application Insights, search TaskCanceledException
# >100/min = orphaned requests (Mistake #5)

# Step 4 — find sequential awaits that should be parallel
# In App Insights end-to-end view, find handlers with >3 sequential awaits

# Step 5 — find async void / fire-and-forget
grep -nE '(public|private|internal)\s+async\s+void' src/
grep -nE '_ = \w+Async|Task\.Run\(' src/

The mental checklist (before merging any non-trivial async code)

[ ] No .Result, .Wait(), or .GetAwaiter().GetResult() anywhere in the call chain?
[ ] Every async method returns Task or Task<T> — never async void?
[ ] Are sequential awaits actually dependent on each other? If not, Task.WhenAll?
[ ] No Task.Run wrapping already-async work?
[ ] Every public async method has a CancellationToken parameter, propagated to every inner await?
[ ] Methods with no await don't have the async keyword?
[ ] All fire-and-forget paths log exceptions OR go through a queue?
[ ] Tight loops with awaits use Parallel.ForEachAsync or SemaphoreSlim-bounded concurrency?
[ ] No lock / Monitor.Enter patterns spanning await?
[ ] ValueTask<T> only on hot paths where the await-once contract is documented?

If any answer is "I'm not sure" — dotnet-counters it before shipping.

The full writeup with before/after code for all 10 mistakes, the symptoms in Application Insights, and the production metrics from the Mattrx audit:

👉 https://prepstack.co.in/blog/async-await-mistakes-that-kill-aspnet-core-api-performance-guide

If this saved you an outage, a ❤️ or 🦄 helps it reach more .NET devs.

What's the worst async footgun you've found in code review?

We Replaced Redis with MySQL SKIP LOCKED for Inventory Reservation — Oversells Went to Zero

kirandeepjassal-crypto — Sun, 07 Jun 2026 09:19:06 +0000

For two years, our Sponsored Placements service booked limited ad inventory through Redis: a counter in Redis, a Redlock around the decrement, and a TTL key per hold.

It oversold. Not catastrophically — consistently. 40–60 double-booked placements a month, each one a manual refund and an apology email to an advertiser.

The root cause was never one bug. It was the architecture: two sources of truth that could not be made atomic with each other. The count lived in Redis; the ownership lived in SQL. No transaction spans both. The Redlock only ever protected the Redis half.

The one mental shift

SKIP LOCKED turns a contended table into a concurrent work queue. Instead of every request fighting over one counter, each request grabs different rows and ignores the ones someone else is holding.

FOR UPDATE alone serializes — that's the experience that scares people off SQL locking. FOR UPDATE SKIP LOCKED is the opposite: a transaction that would have blocked instead skips the locked row and takes the next free one.

One row per reservable unit, then:

START TRANSACTION;

SELECT id
FROM inventory_unit
WHERE placement_id = 42
  AND (status = 'available'
       OR (status = 'held' AND hold_expires_at < NOW(3)))  -- self-healing expiry
ORDER BY id
LIMIT 2
FOR UPDATE SKIP LOCKED;   -- the whole trick

UPDATE inventory_unit
SET status = 'held', reservation_id = 'uuid', hold_expires_at = NOW(3) + INTERVAL 10 MINUTE
WHERE id IN (1107, 1108);

INSERT INTO reservation (...) VALUES (...);

COMMIT;

Two concurrent requests for the same pool lock different rows. Neither waits. The claim, the hold, and the reservation are one transaction — there is nothing to reconcile because there is nothing else.

The numbers (8 weeks before vs 8 weeks after)

Metric	Redis + Redlock	MySQL SKIP LOCKED
Oversells / month	40–60	0
Reservation p95	210 ms	34 ms
Reservation p99	540 ms	61 ms
Throughput / instance	~600 RPS	1,400 RPS
Lock-wait timeouts / day	~900	<5
Nightly reconciliation	9–14 min	deleted
Redis cluster	3 nodes	decommissioned

What made it work (the short version)

One row per unit, not a counter. A single counter row + FOR UPDATE is correct but serial — we measured the cliff at ~600 RPS.
Self-healing expiry. The claim query also picks up held rows past hold_expires_at, so correctness never depends on a sweeper running on time. (Redis TTL loses holds on failover — async replication.)
ORDER BY id + retry on 1213/1205. Deterministic lock order nearly closes the deadlock window; a 3-attempt retry handles the rest. <2 deadlocks/day, all invisible to users.
READ COMMITTED, not REPEATABLE READ. Gap locks under the MySQL default widened contention — switching cut deadlocks ~70% on its own.
A unique index as the backstop. Even if app logic is wrong, the database refuses to record the same unit sold twice.

When NOT to do this

Row-per-unit explodes for fungible, high-cardinality stock (5M identical SKUs → use a guarded UPDATE ... WHERE available >= qty instead). Flash-sale "1 item, 100k people" still wants a queue in front. And we kept Redis — for caching browse-page counts, where it belongs. Redis for speed, MySQL for truth, never the two confused.

The full write-up has the complete before/after C# handlers, the failover timeline that used to oversell, the index/EXPLAIN work, pool sizing, and a pre-merge checklist:

👉 How We Replaced Redis with MySQL SKIP LOCKED for Inventory Reservation at Scale

10 Hidden Memory Leaks in ASP.NET Core — From 2.1 GB to 380 MB (Real Production

kirandeepjassal-crypto — Fri, 05 Jun 2026 09:26:52 +0000

10 Hidden Memory Leaks in ASP.NET Core — From 2.1 GB to 380 MB (Real Production Metrics)

🎥 Prefer to watch? I cover this end-to-end in a 2-3 min video here: https://youtu.be/05UAzS9LCQQ

2.1 GB to 380 MB Without Changing Architecture

Mattrx — six ASP.NET Core 9 instances, no architectural changes — went from 2.1 gigabytes of working set per instance down to 380 megabytes. Eight OOM-driven restarts per week became zero. Tail latency p99 dropped from 820 milliseconds to 180. The cause: ten boring leaks.

Mattrx production — same code, same SQL:
  Working set      2.1 GB → 380 MB    (−82%)
  OOM restarts     8 / week → 0       (90 days)
  GC Gen2 p99      240 ms → 35 ms
  % Time in GC     18% → 4%
  p99 latency      820 ms → 180 ms
  Cost saved       ~$420 / month  (P2v3 → P1v3)

The Mental Model — Leaks Are References You Forgot

A leak in .NET is not a runtime myth. The garbage collector cannot free an object as long as something reachable still references it. A leak is a reference you forgot — a singleton holding a scope, a static event, a cache without a limit. Find the root. Cut it. Memory recovers.

// "Leak" in .NET = unreachable from your intent,
// but still reachable from a GC ROOT.
//
// GC roots: static fields, running threads,
//           strong-rooted handles, the singleton graph.
//
// Fix the rooting. Memory follows.

Leak #1 — Singleton Captures a Scoped DbContext

A singleton constructor takes a DbContext. DI compiles, the app boots, and the first DbContext lives forever — pinned by the singleton. Three hundred and forty megabytes per instance, gone. The fix: inject IServiceScopeFactory and create a fresh scope per call.

// LEAK — singleton captures a scoped DbContext
class CampaignCache(AppDb db) { /* singleton */ }

// FIX — resolve a fresh scope per call
class CampaignCache(IServiceScopeFactory scopes)
{
  public async Task RefreshAsync()
  {
    using var s = scopes.CreateScope();
    var db = s.ServiceProvider.GetRequiredService<AppDb>();
    /* use db here, then dispose with the scope */
  }
}
// −340 MB / instance.

Leak #4 — EF Core Change-Tracker Bloat

A long-lived DbContext loads twenty thousand entities a day for a dashboard query. The change tracker hangs on to every one — three hundred and ten megabytes per instance. The fix is two words: AsNoTracking on read paths. Or just keep the DbContext scoped per request, the way ASP.NET Core wires it by default.

// LEAK — long-lived ctx, no AsNoTracking
var rows = await db.Campaigns
    .Include(c => c.Reports)
    .ToListAsync();   // 20k entities pinned

// FIX — read-only path stays read-only
var rows = await db.Campaigns.AsNoTracking()
    .Include(c => c.Reports)
    .ToListAsync();
// −310 MB / instance.

Watch the walkthrough

Go deeper

The full written guide has every code sample and the production checklist:

https://prepstack.co.in/blog/hidden-memory-leaks-aspnet-core-applications-causes-fixes-production-metrics

Which part have you actually hit in production? Drop a war story in the comments — I read every one.

If this saved you time, hit the ❤️ and the bookmark — that's what tells DEV's algorithm to show it to more devs.

Top 10 Mistakes React Developers Make in 2026 — With Before/After Code, Production Metrics, and Real Fixes

kirandeepjassal-crypto — Thu, 04 Jun 2026 10:27:38 +0000

Every React codebase I've audited over the last three years had the same 10 problems. Not different problems on different teams — the same 10. They cost real money: extra renders that drain mobile batteries, useEffect bombs that race and double-fetch, bundle bloat that adds full seconds to Largest Contentful Paint, accidental O(n²) updates that freeze typing inputs.

This is not "the 10 most clever React patterns." It's the 10 mistakes that show up over and over, with the exact before/after code, the production metrics from a real SaaS dashboard (a multi-tenant analytics platform with 800+ components, 18,000 LOC of TSX, 240k monthly active users), and the diagram for why each one matters.

This is a condensed cross-post. The full version — with every diagram, the diagnostic checklist, and the complete code — lives on my blog: Top 10 Mistakes React Developers Make in 2026.

TL;DR

#	Mistake	Cost when wrong	Cost when fixed
1	Storing derived state with `useState` + `useEffect`	Double renders, bugs on every dep change	0 extra renders
2	Fetching inside `useEffect` (waterfalls)	LCP 4.2s	LCP 1.4s
3	Stale closures + missing `useEffect` deps	Random heisenbugs in prod	Predictable behaviour
4	Index as `key` in dynamic lists	Wrong rows highlighted; lost input state	Stable rows
5	Context for high-frequency state	Whole tree re-renders / keystroke	One subscriber re-renders
6	Premature `useMemo` / `useCallback`	Slower, harder to read	No churn
7	State updates fired during render	Infinite render loop in prod	Clean control flow
8	Direct DOM mutation that fights React	Reconciler resets your DOM	Refs + state in sync
9	Giant components that re-render on every keystroke	INP 380ms; typing visibly lags	INP 80ms
10	Barrel imports + no code splitting	JS bundle 720 KB	JS 230 KB

Real production aggregate after fixing all 10:

LCP 4.2s → 1.4s (mobile, p75)
INP 380ms → 80ms (the biggest UX win)
JS bundle 720 KB → 230 KB
Re-renders per keystroke in main view: 47 → 3
Sentry React errors / week: 84 → 11
"App feels slow" support tickets: 31/month → 4/month

The fixes were not exotic. They were 10 boring habits applied consistently.

Mistake #1 — Storing derived state with `useState` + `useEffect`

This is the #1 mistake in every React codebase, full stop.

// ❌ store, then sync via effect
function CampaignsList({ campaigns, search }) {
  const [filtered, setFiltered] = useState([]);
  useEffect(() => {
    setFiltered(campaigns.filter(c => c.name.toLowerCase().includes(search.toLowerCase())));
  }, [campaigns, search]);
  return <Table rows={filtered} />;
}

This renders twice on every prop change, shows a stale filter on first paint, and gives you two sources of truth.

// ✅ derive, don't store
const filtered = useMemo(
  () => campaigns.filter(c => c.name.toLowerCase().includes(search.toLowerCase())),
  [campaigns, search],
);

Metric: /campaigns re-renders per keystroke: 6 → 2. INP on filtering: 220ms → 90ms.

The rule: If you can compute it from props/state during render, do that. State is for things React can't derive.

Mistake #2 — Fetching inside `useEffect` (the waterfall trap)

// ❌ fetch on mount in every component → sequential waterfall
useEffect(() => { fetch('/api/me').then(r => r.json()).then(setUser); }, []);

Each fetch waits for the previous one and a render before it can even start.

// ✅ Server Component, parallel fetches
export default async function DashboardPage() {
  const user = await getUser();
  const [kpis, events, revenue] = await Promise.all([
    getKpis(user.id), getRecentEvents(user.id), getRevenue(user.id),
  ]);
  return <><KpiCards data={kpis} /><RecentEvents data={events} /><RevenueChart data={revenue} /></>;
}

On a SPA, use TanStack Query with useQueries for parallel requests.

Metric: /dashboard LCP on 3G: 4,200ms → 1,400ms.

The rule: Don't fetch in components if you can fetch on the server. Don't fetch sequentially if you can fetch in parallel.

Mistake #3 — Stale closures and missing `useEffect` deps

// ❌ counter that "freezes"
useEffect(() => {
  const ws = new WebSocket(wsUrl);
  ws.onmessage = () => setCount(count + 1); // ← stale `count`
  return () => ws.close();
}, []); // ← missing dep

// ✅ functional setState — always sees the latest value
ws.onmessage = () => setCount(c => c + 1);

Turn react-hooks/exhaustive-deps to error, not warn.

Metric: "X stopped updating after Y action" bugs in Sentry: 23 → 1.

Mistake #4 — Index as `key` in dynamic lists

{campaigns.map((c, i) => <CampaignRow key={i} campaign={c} />)} // ❌
{campaigns.map(c => <CampaignRow key={c.id} campaign={c} />)}   // ✅

When you delete a row, index keys make React reuse the wrong DOM nodes — inputs jump, focus lands wrong, animations replay. Index keys are safe only when the list never reorders, never has middle inserts/removes, and items hold no internal state.

Metric: row-state bugs ("wrong toggle flipped after sort"): 9 → 0.

Mistake #5 — Context for high-frequency state

Context re-renders all consumers on any value change. Put mousePos (60×/sec) in a shared context and your whole app re-renders 60 times a second.

// ✅ for many high-frequency values, use a subscribable store
const useStore = create((set) => ({
  cart: { items: [] },
  setMousePos: (pos) => set({ mousePos: pos }),
}));
function CartBadge() {
  const itemCount = useStore(s => s.cart.items.length); // re-renders only when count changes
  return <Badge>{itemCount}</Badge>;
}

Metric: /inbox re-renders per second: 62 → 4 after moving to Zustand slices.

The rule: Context for low-frequency global values (theme, user, locale). Subscribable store for anything that updates more than once a second.

Mistake #6 — Premature `useMemo` and `useCallback`

useMemo has overhead. For a cheap string concat, the memo is slower than just computing it. Memoize only when (1) the computation is genuinely expensive, (2) the value is a dep of another hook, or (3) you're passing it to a React.memo'd child.

Metric: removed 84 useMemo + 67 useCallback calls → dashboard render time down 11%.

The rule: Default to no memo. Add it only when a profile shows the cost is real.

Mistake #7 — Updating state during render

// ❌ setState in the component body → second render / infinite loop
if (team && !name) setName(team.name);

// ✅ derive a default; let the user override
const [draft, setDraft] = useState(null);
const name = draft ?? team?.name ?? '';
return <input value={name} onChange={e => setDraft(e.target.value)} />;

The rule: Render must be pure. Never mutate state from the component body.

Mistake #8 — Fighting React with direct DOM manipulation

// ❌ querySelector + style mutation gets undone on re-render
const el = document.querySelector('.message-list');
if (el) el.scrollTop = el.scrollHeight;

// ✅ ref-based, scoped, robust
const ref = useRef(null);
useEffect(() => {
  ref.current?.scrollTo({ top: ref.current.scrollHeight, behavior: 'smooth' });
}, [messages]);

Direct DOM is fine for reading layout (getBoundingClientRect from a ref), focus management, and animation libs. Never for toggling classes/text React also manages.

Metric: /inbox scroll glitches: 5 reports/week → 0.

Mistake #9 — Giant components that re-render on every keystroke

When a search input lives in the same component as a 5,000-row table, every keystroke re-renders the table, the filters, and the pagination.

Three layered fixes: (a) isolate the input's state in a small component, (b) useDeferredValue for the expensive consumer, (c) virtualize the table.

const deferredSearch = useDeferredValue(search); // input updates now; table catches up
const filtered = useMemo(() => campaigns.filter(c => c.name.includes(deferredSearch)), [campaigns, deferredSearch]);

Metric: /campaigns INP: 380ms → 80ms. Re-renders per keystroke: 47 → 3.

Mistake #10 — Barrel imports + no code splitting

import { Button, Card } from '@/components'; // ❌ may pull the entire UI library
import { Button } from '@/components/button'; // ✅ leaf import

Diagnose with npx @next/bundle-analyzer. Leaf-import; dynamically import heavy below-the-fold components; swap heavy libs (moment → date-fns, lazy-load chart.js/mapbox-gl).

Metric: home route JS 720 KB → 230 KB, LCP 4.0s → 1.6s.

The aggregate (after fixing all 10)

Metric	Before	After	Improvement
LCP (mobile p75)	4.2s	1.4s	−67%
INP (overall p75)	380ms	80ms	−79%
Home route JS	720KB	230KB	−68%
Re-renders per keystroke	47	3	−94%
Sentry React errors / week	84	11	−87%
CrUX "Core Web Vitals: Good"	41%	89%	+117%

Three weeks of work. No new features. Trial-signup conversion rose 14%. Speed converts.

Three habits that prevent 90% of the pain:

Default to derivation over state. Store the minimum; derive the rest.
Profile before you optimize. React DevTools Profiler, Lighthouse, bundle analyzer — not vibes.
Make linting strict. react-hooks/exhaustive-deps: 'error'.

Read the full version with every diagram and the complete diagnostic checklist on PrepStack. Auditing a React codebase that's slowing down? Drop the page URL in the comments — happy to point at which of these 10 is likely the culprit.

Angular 19 + .NET 9 Enterprise Architecture — Clean, CQRS, SignalR (with Production Metrics)

kirandeepjassal-crypto — Tue, 02 Jun 2026 09:17:04 +0000

⚠️ Heads up: This is a short preview. The full 24-min deep dive lives on my blog — read it here →

Every "enterprise architecture" tutorial I've read had the same problem: clean diagrams, zero numbers.

So I wrote the one I wish I had when I shipped my last full-stack project — built around a real production system, with the actual P95 latencies, the EF Core changes that moved them, and the trade-offs I'd defend in a code review.

What's inside the full guide

Clean Architecture layout that holds up after 3 years of feature creep
CQRS + MediatR — where it earns its keep, where it's pure ceremony
JWT auth done right — refresh-token rotation, the parts most tutorials skip
SignalR at scale — Redis backplane, sticky sessions, the gotchas nobody warns you about
EF Core perf wins — tracking, projection, compiled queries — P95 480ms → 90ms
Angular ↔ .NET contract patterns that kill "works on my machine"
Production metrics from a live system, not benchmarks on a laptop

A taste — the EF Core perf table from the article

Change	P95 before	P95 after
Default tracking on read queries	480 ms	—
`AsNoTracking()` everywhere reads	480 ms	310 ms
Project to DTO instead of entities	310 ms	140 ms
Compiled queries on hot paths	140 ms	90 ms

One endpoint. Four targeted changes. ~5× improvement. The article shows you the exact code for each.

Why I'm not republishing the full thing here

I want Dev.to readers to land on the original blog because the article keeps getting updated as I learn more. Bookmark the canonical URL — that's the source of truth.

👉 Read the full playbook on PrepStack →

If you're architecting (or rescuing) a full-stack .NET + Angular app in 2026, this is for you. Would love your feedback in the comments — especially from anyone running SignalR + Redis at scale. What patterns worked? What burned you?

EF Core, LINQ & Dapper in .NET — Make Your Data Layer 4 Faster (Real Benchmarks)

kirandeepjassal-crypto — Fri, 29 May 2026 20:28:07 +0000

Data access is where most .NET apps win or lose their performance budget. EF Core isn't slow — three default behaviours are.

I took a 1,000-row product list endpoint and pulled it down from 38 ms to 8 ms using real production benchmarks, one perf lever at a time.

The benchmark ladder

Approach	Mean	Allocated
Tracked entity (default)	38.2 ms	4.1 MB
`AsNoTracking()`	24.7 ms	1.8 MB
Projection to DTO	12.1 ms	0.6 MB
`EF.CompileAsyncQuery`	9.8 ms	0.4 MB
Dapper hand-tuned SQL	8.4 ms	0.3 MB
Raw `SqlDataReader`	7.9 ms	0.2 MB

The single biggest win — projection

Stop returning entities. Project to DTOs that contain only the columns your endpoint actually uses.

public record ProductListDto(
    Guid Id, string Name, decimal Price,
    string CategoryName, int ReviewCount);

var products = await db.Products
    .Select(p => new ProductListDto(
        p.Id, p.Name, p.Price,
        p.Category.Name,
        p.Reviews.Count()))
    .ToListAsync();

EF generates SELECT for the four columns you asked for instead of forty. One rewrite — 85% fewer allocations and 50% faster.

The hybrid pattern

In 2026 you don't have to pick EF Core or Dapper. They share the same DbConnection:

public class OrderService(AppDbContext db)
{
    // Write: EF Core — tracking, validation, audit.
    public Task<Guid> CreateAsync(CreateOrder cmd) { /* ... */ }

    // Hot read: Dapper, on EF's connection.
    public async Task<IReadOnlyList<SalesRow>> DailyAsync()
    {
        var conn = db.Database.GetDbConnection();
        return (await conn.QueryAsync<SalesRow>("SELECT ...")).ToList();
    }
}

EF for writes and most reads. Dapper for the 10% of queries where every millisecond counts. Same project, same connection, no architectural cost.

Watch the 3-min walkthrough

Go deeper

The full written guide has the production benchmarks, the decision matrix, the pull-request checklist, ExecuteUpdateAsync, AsSplitQuery, cursor pagination, multi-result-set queries, and the full EF + Dapper hybrid pattern with code:

https://prepstack.co.in/blog/dotnet-data-access-ef-core-linq-dapper-performance-guide

Which single perf lever in your .NET data layer gave you the biggest production speedup? Share your war story in the comments.

SOLID Principles in C# — I Refactored 60 Ugly Lines, One Rule at a Time

kirandeepjassal-crypto — Thu, 28 May 2026 20:00:08 +0000

SOLID is a default, not a religion.

Most articles teach the five principles with toy examples — a Square that violates LSP, a Logger that violates SRP. You finish having memorised five acronyms with no idea what to do on Monday morning when your real order service has 11 reasons to change and a switch statement on payment type.

So I took a real, ugly 60-line order-processing service that breaks every SOLID rule, and refactored it one principle at a time.

The starting point

public class OrderService
{
    public void PlaceOrder(Order order)
    {
        // validate, apply discount, charge Stripe,
        // open SqlConnection, send SMTP email,
        // append to a log file
        // 60 lines. 6 jobs. 3 hard-coded providers.
    }
}

Untestable without a real Stripe key, a real database, and an SMTP server. Every change touches the same file.

One principle at a time

S — Single Responsibility: 6 jobs in one method → 6 collaborators, each with one stakeholder (finance owns payments, marketing owns email, DBA owns schema).
O — Open / Closed: a switch statement on payment type → strategy interface. Adding Apple Pay is one new class, zero edits to existing code.
L — Liskov Substitution: cash-on-delivery silently returning success from ChargeAsync → honest PaymentResult with a DeferredToDelivery status. The type system tells the truth.
I — Interface Segregation: a god IPaymentMethod interface forcing COD to throw NotSupportedException from three methods → split into capabilities (IRefundable, IRecurringCapable, IDisputable).
D — Dependency Inversion: hard-coded Stripe + SQL + SMTP inside the service → injected abstractions. Now I can write a unit test that runs in 5 ms with zero infrastructure.

The honest disadvantages

SOLID has real costs:

More files (6 classes instead of 1)
More constructor parameters
Harder for new devs to follow the flow (interface → implementation jumping)
Premature abstraction is worse than no abstraction

Apply by default, break with a reason. Document the reason. That's the whole game.

Watch the 2-min walkthrough

Go deeper

The full guide has the complete side-by-side refactor, a 5-question pull-request checklist you can paste into your PR template, and the 6 honest disadvantages each principle costs you:

https://prepstack.co.in/blog/solid-principles-csharp-real-project-deep-dive

Which principle do you find yourself bending most often in real code? Drop your honest answer in the comments.

React vs Angular in 2026 — Architecture, Performance & a Decision Matrix

kirandeepjassal-crypto — Wed, 27 May 2026 18:48:17 +0000

React or Angular in 2026? The honest answer has nothing to do with syntax.

Both frameworks rebuilt their reactivity, and when written well, raw performance is basically a tie. What still differs is the architectural bet each one makes about how the UI updates.

Two different bets

React is a rendering library plus an ecosystem you assemble yourself. React 19 adds a compiler that auto-memoises, so you stop hand-writing useMemo and useCallback — but the component function still re-runs, then React diffs the virtual DOM and patches what changed.
Angular is a full framework, batteries included. Angular 19 makes Signals the default: every signal tracks which views read it, so a change updates only those nodes — no virtual DOM, no parent-tree re-render.

A benchmark that makes it concrete

Toggle one row's selection in a 10,000-row table:

React: the .map() re-runs, rows are memoised → ~12ms on a mid-range phone
Angular: flips two class bindings, no diff → ~0.8ms

Fine-grained reactivity wins when you have many leaves. But remember: the framework rarely decides whether your app is fast — data flow, bundle size, and render boundaries do.

How to actually pick

Reach for React for the bigger hiring pool, Server Components, the smallest bundle, edge streaming, and React Native for mobile.
Reach for Angular for fine-grained Signals, typed templates, enterprise governance, and complex forms.

Watch the 2-minute visual breakdown

Go deeper

The full written guide has real Lighthouse numbers, the performance toolbox for each framework, and an honest decision matrix you can defend in a design review:

https://prepstack.co.in/blog/react-vs-angular-2026-architecture-performance-guide

Which bet are you making in 2026? Drop your stack in the comments.

DEV Community: kirandeepjassal-crypto

We Replaced REST with Kafka and Cut API Failures 90% — .NET 9 Event-Driven Architecture

The one mental shift

Before — synchronous REST chain (the chain that breaks)

After — Kafka log decouples the pipeline

The consumer — groups, manual commit, retry, DLQ

The outbox — atomic produce with a DB write

Idempotent consumers — because delivery is at-least-once

The two superpowers REST never gave us

Aggregate metrics

When NOT to reach for Kafka (honest section)

The mental model in one line

Our Azure Bill Spiked Overnight — Here's Exactly How We Cut It 60% (7 Real Fixes)

Originally published on PrepStack. Cross-posting the TL;DR here.

Where the money went (before -> after)

What it covers

.NET 11 vs .NET 10: We Benchmarked Both on a Real Production App (Should You Upgrade?)

The numbers (9 -> 10, GA, near-zero code changes)

What it covers

Angular State Management in 2026 — NgRx, Signals, NGXS, Akita Compared (with Bundle + LOC Numbers)

The mental model first

The same /campaigns feature, 6 ways

Re-render granularity (the surprising win)

Pure Signals — the 2026 default

When NgRx still wins

The decision tree

The Mattrx production layout (after the cleanup)

The 2026 mental rule of thumb

10 Async/Await Mistakes That Kill ASP.NET Core API Performance (2026 Production Audit)

The mental model first

The 10 mistakes (ranked by what they cost us)

Mistake #1 in detail (the one that delivered ~70% of the win)

The detection arsenal

The mental checklist (before merging any non-trivial async code)

We Replaced Redis with MySQL SKIP LOCKED for Inventory Reservation — Oversells Went to Zero

The one mental shift

The numbers (8 weeks before vs 8 weeks after)

What made it work (the short version)

When NOT to do this

10 Hidden Memory Leaks in ASP.NET Core — From 2.1 GB to 380 MB (Real Production

2.1 GB to 380 MB Without Changing Architecture

The Mental Model — Leaks Are References You Forgot

Leak #1 — Singleton Captures a Scoped DbContext

Leak #4 — EF Core Change-Tracker Bloat

Watch the walkthrough

Go deeper

Top 10 Mistakes React Developers Make in 2026 — With Before/After Code, Production Metrics, and Real Fixes

TL;DR

Mistake #1 — Storing derived state with useState + useEffect

Mistake #2 — Fetching inside useEffect (the waterfall trap)

Mistake #3 — Stale closures and missing useEffect deps

Mistake #4 — Index as key in dynamic lists

Mistake #5 — Context for high-frequency state

Mistake #6 — Premature useMemo and useCallback

Mistake #7 — Updating state during render

Mistake #8 — Fighting React with direct DOM manipulation

Mistake #9 — Giant components that re-render on every keystroke

Mistake #10 — Barrel imports + no code splitting

The aggregate (after fixing all 10)

Angular 19 + .NET 9 Enterprise Architecture — Clean, CQRS, SignalR (with Production Metrics)

What's inside the full guide

A taste — the EF Core perf table from the article

Why I'm not republishing the full thing here

EF Core, LINQ & Dapper in .NET — Make Your Data Layer 4 Faster (Real Benchmarks)

The benchmark ladder

The single biggest win — projection

The hybrid pattern

Watch the 3-min walkthrough

Go deeper

SOLID Principles in C# — I Refactored 60 Ugly Lines, One Rule at a Time

The starting point

One principle at a time

The honest disadvantages

Watch the 2-min walkthrough

Go deeper

React vs Angular in 2026 — Architecture, Performance & a Decision Matrix

Two different bets

A benchmark that makes it concrete

How to actually pick

Watch the 2-minute visual breakdown

Mistake #1 — Storing derived state with `useState` + `useEffect`

Mistake #2 — Fetching inside `useEffect` (the waterfall trap)

Mistake #3 — Stale closures and missing `useEffect` deps

Mistake #4 — Index as `key` in dynamic lists

Mistake #6 — Premature `useMemo` and `useCallback`