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

Full deep-dive (architecture, code, pre-adoption checklist, when NOT to reach for Kafka) on PrepStack: https://prepstack.co.in/blog/replaced-rest-with-kafka-cut-failures-90-percent

The one mental shift

Distinguish commands and 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. Most "we need a message bus" problems are really "we mislabeled an event as a function call."

The old pipeline — synchronous REST chain

Customer site → Collector → Enrichment → Analytics → Persister. Each service waits on the next. The Collector can't return 200 until all three downstream services succeed. Availability multiplies. Analytics slow at month-end → Collector times out → customer's event is gone → customer retries → MORE load on the struggling service → retry storm.

The new pipeline — Kafka log in the middle

The collector produces a single event to events.raw and returns 202 Accepted in ~8 ms. Three independent consumer groups read the same topic in parallel. The collector's success no longer depends on any consumer being up. Analytics down? Its consumer group lags and catches up. Zero customer impact. Zero data loss.

The consumer pattern

Three things matter. One: a consumer group, so partitions parallelize across instances. Two: manual offset commit — commit only after successful processing (at-least-once delivery). Three: a retry topic and a dead-letter topic. Consumer lag is the one health metric.

The outbox pattern — atomic produce with a DB write

If the same handler writes to Azure SQL and then produces to Kafka, those are two systems — a crash between them loses or duplicates the event. For events tied to a committed DB change, use the outbox: write the event to an outbox table in the same SQL transaction as the business data; a relay reads unsent rows and publishes them.

Idempotent consumers — at-least-once + dedup = effectively-once

Kafka gives at-least-once delivery by default. Consumers must be idempotent. A dedup key with a unique constraint is the simplest tool. At-least-once + idempotent = 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 rollup? Reset that one consumer group's offset and reprocess. The log is the source of truth.

Adding a consumer for free. New consumer group on the same topic. The producer doesn't change. ~1 day instead of ~1 sprint.

When NOT to reach for Kafka

Don't replace request/response with Kafka — queries stay synchronous. Kafka is operational weight; use managed Kafka or weigh Service Bus / Event Hubs on Azure first. Exactly-once is a trap. Ordering is per-partition, not global. You traded synchronous errors for asynchronous lag — watch lag or you've hidden the problem.

The closing mental model

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.

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

Full deep-dive on PrepStack: https://prepstack.co.in/blog/replaced-rest-with-kafka-cut-failures-90-percent

If this saved you a 3 AM page, a 💖 or bookmark helps it reach more backend engineers.

Where the money went (before to after)

• Log / telemetry ingestion: \(3,100 to \)340/mo (a Debug level left on; 95 GB/day to 9 GB/day)

• Compute / autoscale: \(3,400 to \)1,500/mo (scaled out but never in; 8 instances 24/7)

• Orphaned resources: \(1,900 to \)0 (a forgotten load-test env + unattached disks/IPs)

• Egress / bandwidth: \(1,200 to \)280/mo (large files, no CDN)

• SQL + Redis: \(1,600 to \)900/mo (premium tiers + no reservations)

• Storage transactions: \(500 to \)190/mo (millions of tiny blob ops, hot tier)

• AI / LLM tokens: \(400 to \)190/mo (uncached RAG, oversized model)

• Total: ~\(12,100 to ~\)4,700/mo (-60%, below the original baseline)

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 (sampling, autoscale Bicep, blob lifecycle, CDN, LLM caching)

• 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. Cost is a production signal: tag everything, dashboard it, and alert on spend-per-day the way you alert on p95. ~3 days to fix, paid back in ~2.

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

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

• Throughput / instance: +11%

• API p95: 132 ms to 120 ms

• Working set / instance: 415 MB to 380 MB

• Native AOT cold start: 84 ms to 61 ms

• Native AOT image size: 41 MB to 33 MB

• Language: C# 13 to C# 14

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 and container size

• Microsoft.Extensions.AI becoming first-class

• The actual 9 to 10 migration (~1.5 engineer-days for 95k LOC)

.NET 11 previews show another ~6-9% throughput, p95 down 5-7%, and ~10% faster startup, but it is preview (GA Nov 2026).

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 own 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

The win wasn't picking the right library. It was picking the right library for each kind of state.

Full deep-dive (with all 6 code samples, bundle table, re-render benchmarks, decision tree, 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.

1. Local UI state — dropdown open, active tab, current input. Lives in one component. Right answer: signal() in the component.

2. Server cache — current list from the API. Lives in a service, cached, invalidated. Right answer: toSignal(http.get(...)) — or NgRx Entity if mutations are complex.

3. Shared feature state — selected rows, bulk-edit draft. Lives in a service. Right answer: signal in a feature service.

4. App-wide workflow state — multi-step transitions with audit log, retry, time-travel debugging. Right answer: NgRx (SignalStore for new code; classic if you need full Redux pattern with Effects).

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 feature, six ways

Mattrx's /campaigns page (list, debounced search, multi-select, optimistic archive, audit log) implemented in six libraries:

— Pure Signals: 0 KB, 70 LOC, 2 files. Mattrx default — covers 80% of state.

— NgRx SignalStore: ~6 KB, 75 LOC, 2 files. Where new NgRx code goes in 2026. Boilerplate gap with Signals is now 5 LOC, not 140.

— NgRx ComponentStore: ~5 KB. Feature-local heavy workflows.

— NgRx classic Store + Effects + Entity: ~25 KB, 210 LOC, 5 files. Full Redux pattern. Still right when you need airtight Action/Reducer separation.

— NGXS: ~14 KB, 140 LOC. Smaller-boilerplate alternative to classic NgRx. Not adopted at Mattrx — no concrete advantage over SignalStore in 2026.

— Akita: ~10 KB, 100 LOC, 4 files. Deprecated (maintenance mode since 2023).

The surprising re-render result

The big jump in render granularity — 47 re-renders per keystroke down to 3 — does not come from picking NgRx vs Signals. It comes from moving to Signals at all, regardless of library wrapping them.

NgRx classic with store.selectSignal() performs the same as pure Signals. BehaviorSubject + | async still pays the one-per-consumer cost.

If you are already on NgRx classic, you do not need to migrate libraries. You just need to switch your selectors from select() to selectSignal().

The 2026 rule of thumb

In one line:

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

The full deep-dive with all six code samples, the complete bundle table, re-render benchmarks, DevTools comparison, decision tree, and the Mattrx production layout (library per feature) is on PrepStack:

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

If this saved you a code-review argument, a 💖 or bookmark helps it reach more Angular devs.