DEV Community: kirandeepjassal-crypto

Angular Performance Optimization in 2026 — OnPush, trackBy, Lazy Loading, Signals, Standalone (Real Code, Production Metrics)

kirandeepjassal-crypto — Wed, 30 Sep 2026 17:34:20 +0000

Angular apps don't go slow because Angular is slow. They go slow because the defaults — Default change detection, NgModules with eager imports, no trackBy, BehaviorSubject everywhere, no lazy loading — were designed for a world where bundle size and per-keystroke render cost weren't the user-facing scoreboard. In 2026 they are: Core Web Vitals (LCP, INP) are part of the Google ranking signal and the conversion funnel.

This is the production playbook for Angular 19+. Five techniques compose into the biggest wins, each with before/after code and real metrics from Mattrx — a multi-tenant marketing-analytics SaaS (Angular 16 → 19, 540+ components, 22k LOC, 110k MAU).

TL;DR — the five, ranked by impact

#	Technique	Before	After	Win
1	Lazy loading (routes + `@defer`)	Initial JS 1.2 MB	290 KB	LCP −67%
2	OnPush change detection	60 CD cycles/sec	3/sec on dashboard	INP −78%
3	Signals (replace BehaviorSubject)	manual `markForCheck`	auto-react on read	fewer bugs
4	Standalone components	NgModule barrels	direct imports, tree-shake	bundle −18%
5	`trackBy` / `track`	4,000 nodes recreated	only changed rows	filter 280ms → 35ms

Aggregate (Angular 16 → 19 + the 5 techniques, 4 weeks, no new features): LCP 4.6s → 1.5s, INP 420ms → 80ms, initial JS 1.2 MB → 290 KB, CrUX "Good" CWV 38% → 91%, trial signup conversion +12%.

The model you need: change detection

Every time Zone.js patches an async API (click, XHR, setTimeout), Angular schedules a CD pass and walks the tree top-down. Default CD re-checks every binding on every component on every pass — even if nothing changed. A setInterval(fn, 100) triggers a full-app CD pass every 100ms. OnPush prunes the tree: a component is checked only when an @Input reference changes, an event fires in it, an async pipe emits, a signal it reads changes, or markForCheck() is called.

1. Lazy loading — the biggest LCP win

export const routes: Routes = [
  { path: '', loadComponent: () => import('./pages/login.component').then(m => m.LoginComponent) },
  { path: 'dashboard', loadComponent: () => import('./pages/dashboard.component').then(m => m.DashboardComponent), canMatch: [authGuard] },
  { path: 'reports', loadChildren: () => import('./pages/reports/reports.routes').then(m => m.REPORTS_ROUTES), canMatch: [authGuard] },
];

Add background prefetch so subsequent navigation is instant too:

provideRouter(routes, withPreloading(PreloadAllModules))

Then @defer for anything heavy that isn't above-the-fold:

@defer (on viewport) {
  <mx-revenue-chart [data]="revenue()" />
} @placeholder {
  <div class="chart-skeleton h-64"></div>
} @loading (minimum 200ms) {
  <mx-spinner />
} @error {
  <mx-chart-load-error />
}

@defer downloads the component and its transitive imports as a separate chunk automatically — no webpack config. Triggers: on idle, on viewport, on interaction, on hover, on timer(2s), when condition. Result: initial bundle 1.2 MB → 290 KB, LCP 4.6s → 1.5s.

2. OnPush — the biggest CPU win

@Component({
  selector: 'mx-kpi-card',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: \`...\`,
})
export class KpiCardComponent {
  @Input() label!: string;
  @Input() value!: number;
}

The Mattrx dashboard did ~13,000 binding evaluations/sec at idle. Blanket OnPush on leaf components: 540/sec. The contract: never mutate input objects in place — create new references (this.user = {...this.user, name}), or use Signals to enforce it structurally. Convert leaf components first (cards, rows, badges) — highest fan-out.

3. Signals — replace BehaviorSubject for state

@Injectable({ providedIn: 'root' })
export class KpiService {
  readonly kpis = signal<Kpis | null>(null);
  readonly revenuePerCampaign = computed(() => {
    const k = this.kpis();
    return k && k.campaigns > 0 ? k.revenue / k.campaigns : 0;
  });
  load(id: string) { this.http.get<Kpis>(\`/api/kpis?u=\${id}\`).subscribe(v => this.kpis.set(v)); }
}

Reading kpis() in a template auto-subscribes the component; kpis.set(...) marks only readers for check. No async pipe, no markForCheck, no takeUntilDestroyed. Use Signals for component/service state; keep RxJS for genuine async pipelines (HTTP, WebSocket, debounced search) and bridge with toSignal / toObservable. /inbox: re-renders per WebSocket message 23 → 2, 62 takeUntilDestroyed removed. Once everything reads signals, you're on the path to zoneless (−28 KB bundle).

4. Standalone components — tree-shaking + lazy loading

Standalone (default in Angular 19) drops the NgModule ceremony and lets the bundler see the exact import graph — no barrel of unrelated junk. Run the schematic in chunks:

ng generate @angular/core:standalone

For Mattrx: 540 components in ~3 days, ~8% needed manual tweaks (mostly forwardRef cycles). Bundle −18% on top of lazy; compile time 42s → 28s.

5. trackBy / @for track — the afternoon fix

@for (campaign of filteredCampaigns(); track campaign.id) {
  <tr><td>{{ campaign.name }}</td><td>{{ campaign.spend | currency }}</td></tr>
} @empty {
  <tr><td colspan="2">No campaigns match.</td></tr>
}

Without a stable track, filtering a 4,000-row table (new array of references) destroys and recreates all 4,000 DOM nodes — and silently unchecks checkboxes. With track campaign.id: only changed rows. Use a stable id, never $index for dynamic lists. Filter latency 280ms → 35ms.

Bonus: block control flow

@if / @for / @switch (Angular 17+) compile smaller and faster than *ngIf / *ngFor, support @else if and @empty. Use for all new code.

The right mental model

Do less work, and do it later. Lazy loading = do it later. OnPush = do less. track = don't recreate what didn't change. Signals = do less, more precisely. Standalone = ship only what you use.

Three habits: OnPush + standalone on every new component by default; lazy-load before you optimize; profile before you tune (Chrome Performance, ng build --stats-json, Lighthouse).

The full guide has every before/after, the Default-vs-OnPush tree-walk diagrams, the bundle-split diagram, the full @defer trigger list, the Signals interop table, and the step-by-step diagnostic checklist for inheriting a slow app:

https://prepstack.co.in/blog/angular-performance-optimization-guide-onpush-trackby-lazy-loading-signals-standalone-components

Originally published on PrepStack.

Angular Micro Frontends in 2026 — Webpack Module Federation vs Native Federation, Independent Deployments (Real Project, Production Metrics)

kirandeepjassal-crypto — Mon, 28 Sep 2026 18:06:26 +0000

Micro frontends sound like an architecture pattern. They're actually a deployment pattern that happens to have UI consequences. The question they answer isn't "how do we structure code?" — it's "can team A ship without waiting for team B, even though both teams' code runs in the same browser tab?"

The wrong reason to adopt them: "our app is big." (Big apps want an Nx monorepo with feature libraries.) The right reason: independent deployments, different release cadences, separate teams that don't want to coordinate every push to production.

This is the production playbook, built on the same real app throughout: Mattrx, a multi-tenant marketing-analytics SaaS on Angular 19, where the partner-widgets team carved out into a separate remote in early 2026. Real numbers from that split are throughout.

The one idea

Independent deployment is the whole point. The shell's HTML never re-bundles the remote — it fetches it fresh at runtime (or from cache), evaluates it in place, and reuses the singleton shared deps. Update the remote on its CDN → the next navigation picks it up. The shell does not redeploy when the remote ships.

Three concepts:

Host (shell) — loads first. Owns routing, auth, layout, in-host features. Knows the URLs of its remotes, not their code.
Remote — a separately-built, separately-deployed Angular sub-app that exposes lazy-loadable components/routes via a manifest.
Contract — the named exports each remote exposes. The host imports them by name; the remote promises to keep them stable.

Two paths: Webpack MF vs Native Federation

	Webpack MF	Native Federation
Basis	Webpack 5 ModuleFederationPlugin	Import Maps + ESM
Build	webpack (slower)	esbuild (faster)
Config	custom webpack	default Angular builder
New Angular 19 project	only with webpack expertise	Recommended
Already on webpack	stay	migrate later if convenient

For Mattrx we chose Native Federation for the two new remotes. Honest reason: it didn't require swapping our build system back to webpack.

Native Federation — the modern setup

npm i -D @angular-architects/native-federation
ng add @angular-architects/native-federation --project shell --type host --port 4200
ng add @angular-architects/native-federation --project partner-widgets --type remote --port 4201

The shell points at remotes via a small JSON manifest (.json, not .js):

// apps/shell/src/assets/manifest.json
{
  "partner-widgets": "https://partners.mattrx.io/remoteEntry.json",
  "labs":            "https://labs.mattrx.io/remoteEntry.json"
}

A lazy route pulls the remote:

import { loadRemoteModule } from '@angular-architects/native-federation';

export const APP_ROUTES: Routes = [
  { path: 'dashboard', loadChildren: () => import('@mattrx/features/dashboard').then(m => m.DASHBOARD_ROUTES) },
  { path: 'partners',  loadChildren: () => loadRemoteModule('partner-widgets', './Module').then(m => m.PARTNER_ROUTES) },
];

The remote declares what it exposes:

// apps/partner-widgets/federation.config.js
module.exports = withNativeFederation({
  name: 'partner-widgets',
  exposes: {
    './Module':                 './apps/partner-widgets/src/app/partner.routes.ts',
    './PartnerCampaignsWidget': './apps/partner-widgets/src/app/widgets/partner-campaigns.component.ts',
  },
  shared: { ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }) },
});

The day-2 reality (where the real engineering lives)

Immutable chunks, mutable manifest. remoteEntry.json changes every deploy → Cache-Control: no-cache. The content-hashed chunks it references → cache forever. Get this wrong and a user loads yesterday's manifest pointing at today's missing chunks.

Atomic deploys. Upload chunks first, verify they return 200 from the CDN, then flip the manifest pointer. If the manifest goes live before the chunks exist, anyone loading in that window crashes. We learned this the hard way — two broken minutes in production.

Shared dependency version drift — the #1 source of pain. If the shell is on @angular/core@19.1.3 and the remote was built against 19.0.7:

singleton: true, strictVersion: true — boot-time error. Loud, deterministic, right. Use this for Angular packages.
strictVersion: false — uses whichever loaded first. Silent breakage if APIs drift. OK only for a backwards-compatible design system.
singleton: false — two Angulars. Don't.

When the shell bumps an Angular minor, every remote bumps the same week — a "version-bump-only" PR per remote.

The exposes contract is a SemVer surface. The host imports './PartnerCampaignsWidget' by name — that string is a public contract. Add freely, coordinate on signature changes, deprecate-for-one-release before removing. Keep a literal EXPOSES.md per remote. Contract-test it in CI against the remote's staging URL, on every shell PR and every remote PR.

Rollback is flipping the manifest back:

aws s3 cp s3://mattrx-partners/remoteEntry.PREVIOUS.json s3://mattrx-partners/remoteEntry.json
aws cloudfront create-invalidation --distribution-id ABC --paths "/remoteEntry.json"
# Live within ~30s. No build, no redeploy.

The production numbers (after carving out 2 remotes)

Metric	Before	After
Partner team deploys/week	1	15–40 (3–8/day)
Time to ship a partner hotfix	25 min	4 min
Cross-team coordination tickets/sprint	9	1
Prod incidents from cross-team merges/mo	12	3
Shell bundle (gzipped)	290 KB	290 KB (unchanged)
Cold-start LCP (first remote hit)	1.5s	1.7s (+200ms — honest cost)
Warm-start LCP (cached remote)	1.5s	1.4s
Rollback on a remote regression	25 min	45 seconds

The LCP cost is real and we own it. Idle-prefetch the manifest after the shell loads and cold-start drops back to ~+40ms:

provideAppInitializer(async () => {
  await new Promise<void>(r => requestIdleCallback(() => r()));
  await prefetchRemote('partner-widgets');
}),

When NOT to use micro frontends

The most-skipped section of every MFE article. Most teams shouldn't. Don't reach for MFEs if you're under ~25 frontend engineers in 1–2 teams, if you want smaller bundles (that's lazy loading), if you want faster CI (nx affected is cheaper), or if your teams ship together anyway.

Do consider them if a team ships to a different surface (partner CDN, extension), needs a conflicting deploy cadence, embeds the same code in third-party hosts, or is an acquired team merging in without a rewrite. For Mattrx, exactly one of those was true — so we carved out one remote, not ten.

The right mental model

Micro frontends are an operational tool dressed in architecture clothes. The architecture exists so that the deployment property (independent ship) becomes possible. Without the deployment property, the architecture is overhead with no upside.

Three habits: adopt one remote at a time for one reason at a time; treat the exposes contract as a SemVer surface (document + test in CI); coordinate the boring stuff (Angular minor bumps, design-system versions, CDN caching).

The full guide has the complete Webpack MF setup too, the request-flow and deploy-flow diagrams, the embeddable-widget use case, the 8-week adoption path, and the honest "what we'd do again / what we'd skip":

https://prepstack.co.in/blog/angular-micro-frontends-module-federation-webpack-native-federation-independent-deployments-guide

Originally published on PrepStack.

Angular Signals vs RxJS in 2026 — When to Use Each, Performance Benchmarks, and the Interop Pattern (Real Code)

kirandeepjassal-crypto — Sat, 26 Sep 2026 17:51:32 +0000

"Should I use Signals or RxJS for this?" is the most-asked question in modern Angular code review. The bad answer — "use Signals everywhere, RxJS is legacy" — produces fragile WebSocket handling and re-invented switchMap. The other bad answer — "stick with RxJS, Signals are toys" — produces 30 lines of BehaviorSubject + takeUntilDestroyed to track which tab is active.

The right answer is mechanical, not philosophical: Signals are pull-based, synchronous, fine-grained reactive values; RxJS is push-based, asynchronous, time-aware event composition. Each is excellent at exactly one half of the problem. Real code, benchmarks, and production numbers from migrating Mattrx — a multi-tenant marketing-analytics SaaS (540 components, 22k LOC, 110k MAU).

The mental model (the one chart you need)

                        SIGNALS                  RxJS
Direction              PULL (read latest)       PUSH (subscribe, get next)
Time                   SYNCHRONOUS              ASYNCHRONOUS
Granularity            Per-value, fine-grained  Per-stream, coarse-grained
Cancellation           N/A (no async)           takeUntil / abort
Memoization            Built-in (computed)      Manual (shareReplay)
OnPush integration     Auto-marks for check     Needs async pipe / markForCheck
Conceptual fit         "the current value of X" "the stream of X events over time"

Ask one question:

"I need to know the latest X" -> Signal
"I need to react to every event of X over time" -> RxJS

That resolves 90% of the real ambiguity.

When Signals win (state)

Local UI state, derived values, service-level shared state, side effects — all Signal territory. The service-level case is where the code shrinks most:

// BEFORE - BehaviorSubject ceremony (29 lines)
private dateRange$ = new BehaviorSubject<DateRange>(...);
private status$    = new BehaviorSubject<Status[]>(['active']);
// ...asObservable(), setters, combineLatest, shareReplay...

// AFTER - Signals (9 lines)
readonly dateRange = signal<DateRange>({ from: lastWeek(), to: today() });
readonly status    = signal<Status[]>(['active']);
readonly filters   = computed(() => ({ dateRange: this.dateRange(), status: this.status() }));

computed() is the multicast — lazy, memoized, O(1) cached reads. No shareReplay, no combineLatest, no next(). Mattrx had 240 BehaviorSubjects; the cleanup deleted ~1,400 lines of state code.

When RxJS wins (events over time) — and Signals genuinely can't

Debounced search with race cancellation is the canonical example:

results$ = this.query.valueChanges.pipe(
  debounceTime(250),
  distinctUntilChanged(),
  switchMap(q => this.http.get(`/api/search?q=${q}`).pipe(catchError(() => of([])))),
  shareReplay(1),
  takeUntilDestroyed(),
);

To replicate this in pure Signals you'd hand-roll a setTimeout debounce, an AbortController you abort per keystroke, try/catch, and a loading flag — ~40 lines re-inventing switchMap. Same story for WebSocket streams (webSocket() + retry({delay}) + share()), drag-to-resize (mousedown -> switchMap(mousemove) -> takeUntil(mouseup)), and multi-source merge (combineLatest + throttleTime). Anything with debounce / throttle / retry / timeout / switchMap / scan in its description belongs in RxJS. Signals do not model time.

Performance (numbers, not vibes)

Operation	Time
`signal()` read	~12 ns
`signal.set(v)` write (no listeners)	~50 ns
`BehaviorSubject.next(v)` (one sync sub)	~700 ns
`computed()` read (warm cache)	~15 ns
Observable `pipe(map).subscribe()`	~3.4 us

Signals are ~14x faster than BehaviorSubject for "publish a value, one sync reader." But the real win is structural, not micro: on Mattrx's /inbox, re-renders per WebSocket message went 23 -> 2 — because fine-grained dependency tracking re-renders only the specific slice that changed, not 23 components subscribed via | async. And with zoneless + Signals, idle change-detection passes on /dashboard dropped to 0 (only run when a signal changes).

The honest caveat: Signals don't make a slow app fast on their own — they make change-detection precise. The big wins come combined with OnPush + standalone + @for track.

Interop — you don't have to pick

Bridge at the boundary and keep each half native:

// stream -> state (HTTP as an OnPush-aware Signal)
campaigns = toSignal(this.http.get<Campaign[]>('/api/campaigns'), { initialValue: [] });

// state -> stream (debounce a Signal-driven input through RxJS, back to a Signal)
results = toSignal(
  toObservable(this.query).pipe(debounceTime(250), distinctUntilChanged(),
    switchMap(q => this.http.get(`/api/search?q=${q}`))),
  { initialValue: [] },
);

toSignal() and toObservable() aren't workarounds — they're the design. (One gotcha: toSignal without initialValue returns Signal<T | undefined> — always supply initialValue for HTTP.)

The decision tree

Is this "the current value of X" (state)? -> SIGNAL
  ├── Local to a component -> signal()
  ├── Shared across the app -> signal() in a service
  └── Derived from other signals -> computed()
Otherwise it's an event stream / time-based / async:
  ├── HTTP -> HttpClient Observable; toSignal() if read as state
  ├── debounce/throttle/switchMap input -> RxJS
  ├── WebSocket / SSE -> RxJS (webSocket + retry + share)
  └── composing DOM events (drag, gesture) -> RxJS (fromEvent + operators)

The right mental model

In one line: Signals are nouns. RxJS is verbs. "What is the current set of selected campaigns?" -> Signal. "What's happening when the user types?" -> RxJS. Three habits: default to Signals for state, default to RxJS for streams, bridge with interop instead of fighting it.

The full guide has all 10 code examples each way, the full benchmark tables, the end-to-end /campaigns component using both, and the 4-week Mattrx migration path (including the bugs that bit us):

https://prepstack.co.in/blog/angular-signals-vs-rxjs-when-to-use-which-performance-comparison-guide

Originally published on PrepStack.

Enterprise Angular Architecture in 2026 — Core, Shared, Feature + Nx Monorepo (Real Project Layout, Production Metrics)

kirandeepjassal-crypto — Wed, 23 Sep 2026 18:44:42 +0000

Most Angular apps don't fail because the framework runs out of steam. They fail around the 18-month mark, when the directory tree turns into a swamp: shared/utils/helpers/index.ts re-exports everything, three teams import each other's internals through it, CI takes 14 minutes because one test change rebuilds the world, and nobody can ship a feature without breaking two others.

The four patterns here — Feature, Core, Shared, and an Nx monorepo with enforced library boundaries — are what stops that. Not 2017 NgModule dogma; the directory-and-dependency-graph discipline underneath, which works just as cleanly with Angular 19 standalone components.

Every section uses the same real app: Mattrx, a multi-tenant marketing-analytics SaaS — Angular 19 standalone, 4 apps in one repo, 540+ components, 22k LOC, 5 product teams sharing a design system and data-access layer.

The mental model: the dependency graph IS the architecture

The single biggest decision in a large Angular app is what's allowed to import what. The arrows go ONE way:

Apps (shells) -> Features (lazy) -> Shared (ui, util)
                     |
                     v
                   Core (imported only by the app shell)

Never:
  Shared -> Features    (shared can't know about features)
  Features -> Features  (features can't reach across each other)
  Anything -> Core, except the app shell

Layer	Owns	Imported by
Core	auth, interceptors, error handler, config, logger	only main.ts, once
Shared	buttons, tables, pipes, DTOs - no business logic	any feature
Feature	routes, components, services, state for one capability	the app router (lazy)
Nx libs	tagged boundaries, ESLint enforcement, nx affected	the whole repo

Core — the app-singleton layer (modern, no NgModule)

export function provideCore(): EnvironmentProviders {
  return makeEnvironmentProviders([
    AuthService, ConfigService, LoggerService,
    { provide: ErrorHandler, useClass: GlobalErrorHandler },
    provideHttpClient(withInterceptors([authInterceptor, errorInterceptor])),
    provideAppInitializer(() => inject(ConfigService).load()),
  ]);
}

// apps/customer/src/main.ts — called exactly once
bootstrapApplication(AppComponent, {
  providers: [provideCore(), provideRouter(routes), provideAnimationsAsync()],
});

makeEnvironmentProviders is the modern equivalent of the "Core module can only be imported once" guard.

Shared — the cardinal rule

Shared cannot import from Features. Ever. If a "shared" component needs to know about campaigns, it isn't shared — it's a campaigns component.

Each Shared component is its own Nx library, imported at the leaf — no barrel @mattrx/shared/ui that re-exports everything (so the bundler tree-shakes per-library, not per-monolith):

import { MxButton } from '@mattrx/shared/ui/button';import { MxTable } from '@mattrx/shared/ui/table';```

Don't ship a `SharedModule` in 2026 — importing it to use `<mx-button>` drags in `<mx-modal>`, `<mx-toast>`, `<mx-table>`, and everything else. Use standalone leaves.

## Feature — one bounded business capability, lazy-loaded



```ts
// app.routes.ts — the app router doesn't know the feature's internal structure
{ path: 'campaigns', canMatch: [authGuard],
  loadChildren: () => import('@mattrx/features/campaigns').then(m => m.CAMPAIGNS_ROUTES) },

The bundler emits one chunk per feature. Landing on /dashboard downloads main.js (~280 KB) + dashboard.chunk.js (~140 KB) — not campaigns, inbox, reports. Feature state is Signals-first (toSignal at the HTTP boundary, computed for derived).

Nx — the structural firewall

Tags declare what each library is and belongs to, and ESLint enforces the arrows:

"@nx/enforce-module-boundaries": ["error", { "depConstraints": [
  { "sourceTag": "type:feature",     "onlyDependOnLibsWithTags": ["type:ui","type:data-access","type:util"] },
  { "sourceTag": "type:ui",          "onlyDependOnLibsWithTags": ["type:ui","type:util"] },
  { "sourceTag": "type:util",        "onlyDependOnLibsWithTags": ["type:util"] },
  { "sourceTag": "scope:customer",   "onlyDependOnLibsWithTags": ["scope:customer","scope:shared"] }
]}]

A type:ui library that imports a type:feature library is an ESLint error in CI. That's the difference between "we have a convention" and "the codebase enforces the convention."

And nx affected runs CI only for what the PR touched:

- run: npx nx affected --target=build --base=origin/main   # 2.5 min, not 12

The before/after (after the structure landed, 4 weeks)

Metric	Before	After
CI on a typical PR	22 min	6 min
affected:build	12 min	2.5 min
affected:test	8 min	90 s
Initial JS (gzipped)	1.2 MB	290 KB
Cross-team merge conflicts/wk	~6	~1
Scaffold a new feature	~3 days	~4 hours
"Where does this go?" PR comments/wk	~12	~1
Velocity (features/sprint)	9	14

The migration path (4 weeks, not one big PR)

Week 1 — tease apart Core (move Auth, interceptors, error handler, logger, config; replace CoreModule with provideCore()). Week 2 — tease apart Shared (one lib per component, tag everything, turn on @nx/enforce-module-boundaries, fix violations). Week 3 — extract Features one at a time, most isolated first, ~1-2/day. Week 4 — enable nx affected in CI + add any second frontend as a new app that reuses your shared libs.

The right mental model

Enterprise Angular at scale isn't NgModules vs standalone — it's the dependency graph being a layered DAG, and the codebase enforcing that picture so humans don't have to. Core = app-singletons imported once. Shared = presentation + utilities that know no business concepts. Features = lazy-loaded leaves that can't reach each other. Nx = makes the graph visible, enforces it, makes CI fast.

Three habits: generate every library (nx g) with tags from day one; treat boundary violations as test failures; keep apps as thin shells.

The full guide has the real Mattrx layout with file counts, the classic-vs-standalone code for every layer, the nx graph, the full ESLint config, the decision tree for "where does this go?", and the week-by-week migration path:

https://prepstack.co.in/blog/enterprise-angular-architecture-feature-core-shared-modules-nx-monorepo-guide

Originally published on PrepStack.

LLMs & Transformers from First Principles (2026) — Tokenization, Attention, LoRA, and a Tiny GPT You Can Train (with PyTorch Code)

kirandeepjassal-crypto — Mon, 21 Sep 2026 18:18:08 +0000

Everyone uses LLMs in 2026. Far fewer can explain what happens between text in and text out. The gap matters because every LLM problem — bad outputs, high latency, wrong answers, costly fine-tunes — is solved by knowing which mechanism inside the model is responsible.

This rebuilds the LLM stack piece by piece with real PyTorch and Hugging Face code: tokenization, embeddings, self-attention, the transformer block, a tiny GPT you can train on your laptop, pretraining vs fine-tuning vs LoRA vs DPO, and decoding.

The one idea

An LLM is a function from token sequences to a next-token probability distribution. That's it.

sequence = [<bos>, "The", " sky", " is"]
while not done:
    probs = LLM(sequence)
    next_token = sample(probs)
    sequence.append(next_token)

Every chat API, code assistant, agent, and RAG system is a sampling loop around "predict the next token."

Tokenization — text becomes integers first

A model can't read characters. Modern LLMs use subword tokenization (BPE for GPT/Llama/Mistral, WordPiece for BERT, SentencePiece for T5).

from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("gpt2")
tok.convert_ids_to_tokens(tok.encode("Mumbai and Indore are cities in India."))
# ['Mumbai', 'and', 'Ind', 'ore', 'are', 'cities', 'in', 'India', '.']

"Mumbai" is 1 token; "Indore" is 2. Token counts drive API cost, context window, and latency — French text costs 2-3x more tokens than English. Tokenization is the source of most "why does the model do X?" bugs. And always use apply_chat_template — hand-concatenating "user: ... assistant: ..." is a classic bug.

Self-attention — the one idea that changed everything

For each token, compute a weighted sum of every other token's value, where the weights depend on relevance. Every token gets three roles: Query ("what am I looking for?"), Key ("what do I represent?"), Value ("what do I contribute?").

Attention(Q, K, V) = softmax(Q @ K.T / sqrt(d)) @ V

The whole revolution is one matrix multiply + a softmax:

scores = Q @ K.transpose(-2, -1) / math.sqrt(self.d_k)
if mask is not None:
    scores = scores.masked_fill(mask == 0, float("-inf"))
weights = F.softmax(scores, dim=-1)
return weights @ V

The causal mask (lower-triangular) is why GPT can't see the future. Multi-head attention runs several of these in parallel. In production, use Flash Attention via F.scaled_dot_product_attention.

The transformer block

x -> LayerNorm -> MultiHeadAttention -> +residual ->
  -> LayerNorm -> FeedForward -> +residual -> output

Residuals are the gradient highway — without them, deep transformers don't train.
LayerNorm (Pre-LN) stabilizes training.
Feed-forward is a 2-layer MLP per token, usually d_ff = 4 x d_model.

Stack 6-96 of these and you have a model. Llama-3-8B is 32 blocks; GPT-3 is 96. The guide has a full runnable ~200-line GPT you can train on Shakespeare on a laptop — that's the entire architecture of GPT-3, just bigger and on more data.

Training, decoded

Pretraining = predict the next token on 5-15 trillion tokens. The intelligence emerges from that one boring objective at scale ($10M-$100M for a frontier model).
Fine-tuning — start with prompting/few-shot; if that's not enough, LoRA trains ~0.1% of params at ~1000x less memory:

lora_config = LoraConfig(r=16, lora_alpha=32,
    target_modules=["q_proj","k_proj","v_proj","o_proj"],
    lora_dropout=0.05, task_type="CAUSAL_LM")
model = get_peft_model(model, lora_config)
# trainable%: 0.4%, adapter ~130 MB

QLoRA (LoRA on a 4-bit base) fine-tunes a 70B model on a single 24 GB GPU — the standard recipe for small teams in 2026.
SFT trains on (instruction, response); DPO on (prompt, chosen, rejected) — much simpler than classic RLHF.

Decoding

Greedy is deterministic but repetitive. The production default is temperature + top-p:

out = model.generate(inputs, do_sample=True, temperature=0.7, top_p=0.9,
                     repetition_penalty=1.05, max_new_tokens=128)

Chat: 0.7. Code: 0.0-0.3. For production, swap model.generate for vLLM — paged attention + continuous batching, often 5-20x faster.

The honest stuff

Context length costs scale quadratically — 32k isn't 4x 8k, it's ~16x.
Most prod LLM systems are 90% retrieval + 10% LLM.
Fine-tuning is rarely the answer — try prompting, RAG, and a bigger model first.
Evals beat vibes — build a golden set of 50-200 queries before you fine-tune.
Inference cost dominates training cost. Optimize for serving.

The right mental model

An LLM is not magic. It's: a tokenizer, an embedding table, a stack of transformer blocks, and a head that projects back to vocabulary. Pretraining gives general competence; fine-tuning teaches your task; decoding turns probabilities into text.

Three habits: always inspect the tokens first; build the eval set before the model; reach for the smallest model that works.

The full guide has the complete PyTorch — scaled dot-product + multi-head attention, the transformer block, the runnable tiny GPT + training loop, full/LoRA/QLoRA fine-tuning, DPO, the decoding recipes, RAG, tool-use, and the 2026 model menu:

https://prepstack.co.in/blog/llms-transformers-tokenization-attention-embeddings-pretraining-finetuning-pytorch-guide

Originally published on PrepStack.

AI Deployment & MLOps in 2026 — Serving, Monitoring, Cloud, and a Full End-to-End Project (with Code)

kirandeepjassal-crypto — Sat, 19 Sep 2026 08:16:31 +0000

A model that gets 0.94 F1 in a notebook is worth nothing until it's serving real requests, staying healthy under load, and being retrained before it goes stale. The gap between "trained" and "in production" is where most AI projects quietly die — not because the model was bad, but because nobody owned deployment, monitoring, and maintenance.

This is the MLOps playbook: deploying models (REST/batch/streaming/serverless), best practices (versioning, CI/CD, reproducibility, the registry), monitoring live systems (drift, performance, business metrics), cloud strategies, and a complete end-to-end app — with real code throughout.

The one idea

Deployment is not a model.pkl on a server. It's a versioned artifact + reproducible serving image + an API + health checks + autoscaling + monitoring + a rollback path. MLOps = DevOps for ML plus the things ML adds: data versioning, a model registry, experiment tracking, and retraining (because models go stale in a way code never does).

Three serving patterns — pick by latency

Pattern	Latency	When
Real-time (REST/gRPC)	ms	per-request, now (fraud check, chatbot)
Batch	minutes-hours	scheduled bulk scoring (nightly churn)
Streaming	sub-second	react to events (anomaly on a sensor stream)

The bug that kills more models than any other: serving/training skew

The serving code preprocesses input differently than training did. Fix it by saving the entire pipeline — preprocessing + model — as one artifact:

model = Pipeline([("prep", preprocessor), ("clf", LGBMClassifier(n_estimators=400))])
model.fit(X_train, y_train)
joblib.dump(model, "model.joblib")   # preprocessing + model travel together. Cannot drift apart.

At serving time, joblib.load("model.joblib").predict(raw_df) applies the exact training-time preprocessing. This single discipline prevents the most common production failure.

A real-time REST service (FastAPI) — three non-negotiables

MODEL = joblib.load("model.joblib")    # 1. load once at startup
MODEL_VERSION = "1.4.0"

@app.post("/predict")def predict(features: CustomerFeatures):
    df = pd.DataFrame([features.model_dump()])
    proba = float(MODEL.predict_proba(df)[0, 1])
    return {"churn_probability": proba, "will_churn": proba > 0.5,
            "model_version": MODEL_VERSION}   # 2. ALWAYS return the version

@app.get("/health/ready")def ready(): return {"status": "ready"}      # 3. readiness + liveness endpoints

Version everything — the three artifacts

code (git SHA) + data (DVC / dataset hash) + model (registry version) = a reproducible prediction

With a registry (MLflow), serving loads by stage, not a file path:

MODEL = mlflow.pyfunc.load_model("models:/churn-model/Production")

Swapping models becomes "promote version 6 to Production" — no redeploy, full audit trail, and rollback is just promoting the previous version.

The ML-specific CI/CD piece: the quality gate

- name: Quality gate - block deploy if metrics regress
  run: |
    python - <<'PY'
    import json; m = json.load(open("metrics.json"))
    assert m["roc_auc"] >= 0.82, f"ROC-AUC {m['roc_auc']} below 0.82"
    assert m["f1"] >= 0.70, f"F1 {m['f1']} below 0.70"
    PY

A new model only ships if it meets minimum metrics on a held-out set.

Monitor four layers (not just accuracy)

System health - latency (p50/p95/p99), error rate, throughput (Prometheus + Grafana).
Data drift - production inputs drift from training inputs; accuracy silently drops with no error thrown. Detect with a KS-test per feature; tools: Evidently, NannyML, WhyLabs.
Concept drift - inputs look the same but the input->output relationship changed. Shows up as falling live AUC once true outcomes arrive.
Business metrics - revenue saved, fraud caught, tickets deflected. A model with great AUC that doesn't move the business metric is a science project, not a product.

Cloud strategy: containerize once, then choose

Option	Best for	Ops
Managed endpoints (SageMaker, Vertex, Azure ML)	fastest to prod	lowest
Kubernetes (AKS/EKS/GKE)	full control, multi-model, GPU sharing	highest
Serverless (Cloud Run, Lambda)	low/spiky traffic, scale-to-zero	low

Start with a managed endpoint unless you have a reason not to.

The end-to-end project

A customer-churn system wired end to end: train.py (train -> quality gate -> register to MLflow) -> FastAPI service in Docker (loads from the registry, exports Prometheus metrics) -> monitor.py (KS-test drift + live-AUC performance) -> GitHub Actions CI/CD with a schedule block that retrains every Monday, runs the same quality gate, and only ships if the new model clears the bar.

The MLOps maturity ladder

Level 0 (notebook -> model.pkl -> manual upload) -> Level 1 (automated training) -> Level 2 (CI/CD + registry + quality gate) -> Level 3 (drift + performance + business monitoring) -> Level 4 (auto-retraining). Most teams should target Level 2-3. Match the maturity to the stakes.

The right mental model

MLOps is treating a model as a living production system, not a deliverable. Three habits:

One artifact, one version, always returned.
Gate every deploy on quality.
Assume the model will rot - monitor and retrain. Drift is the default, not an edge case. Build the feedback loop before you need it.

The full guide has every file (train/serve/monitor/CI), the Dockerfile, the K8s manifest with HPA, the Azure ML managed-endpoint code, and the mental checklist for \"in production\":

https://prepstack.co.in/blog/ai-deployment-mlops-production-serving-monitoring-cloud-end-to-end-project

Originally published on PrepStack.

No Python, No PhD: Train Real ML Models in C# with ML.NET (Regression, Classification, Clustering)

kirandeepjassal-crypto — Thu, 17 Sep 2026 19:08:04 +0000

Mattrx ran its predictive features on a Python scikit-learn microservice for two years. We replaced it with ML.NET running in-process inside the existing .NET 9 app — and trained real regression, classification, and clustering models in C# with no separate service, no second language in production, and no implementing gradient descent by hand.

If you're a .NET team that "does ML" by shipping a Python sidecar, you're paying a tax most teams never question: a second runtime, a second deploy pipeline, a second on-call surface, a cross-process hop on every prediction, and a data contract that drifts between two languages. For classical ML — regression, classification, clustering — you usually don't need any of it.

Before vs after

Dimension	Before (Python sidecar)	After (ML.NET in-process)
Languages in production	C# and Python	C# only
Deploy pipelines	2	1
Prediction path	HTTP to Flask -> scikit-learn	in-memory call
Prediction p95	45 ms	2.8 ms
Model artifact	pickle in a container image	2 MB .zip, loaded by the app
On-call surface	app + ML service	app only
Infra cost	+$160/mo for the ML service	$0 (decommissioned)

The one mental shift

The reason .NET teams reach for Python isn't the models — it's a belief that "real ML needs Python and a math background." For deep-learning research, fair. For the bread-and-butter business ML that 90% of products ship — predict a number, predict a category, group similar things — it's not true.

You don't implement algorithms; you compose a pipeline. You describe data -> transforms -> trainer -> metrics, call Fit(), call Evaluate(). You never write gradient descent, a tree split, or a k-means iteration. The skill that matters is data preparation and honest evaluation — and that's language-agnostic.

Regression — forecast campaign conversions

var pipeline = ml.Transforms.Categorical.OneHotEncoding("ChannelEnc", "Channel")
    .Append(ml.Transforms.Categorical.OneHotEncoding("VerticalEnc", "Vertical"))
    .Append(ml.Transforms.Concatenate("Features",
        "Impressions", "Week1Clicks", "AudienceSize", "ChannelEnc", "VerticalEnc"))
    .Append(ml.Transforms.NormalizeMinMax("Features"))
    .Append(ml.Regression.Trainers.FastTree(labelColumnName: "Label",
        featureColumnName: "Features"));

ITransformer model = pipeline.Fit(split.TrainSet);
var metrics = ml.Regression.Evaluate(model.Transform(split.TestSet));

FastTree is the gradient-boosted tree trainer — you just select it. Result: R² 0.78, RMSE 41 on campaigns averaging ~600 conversions. Same accuracy band as the old scikit-learn model, now with no service to call.

Classification — predict tenant churn

The catch every real churn model hits: class imbalance. Most tenants don't churn, so a model that always predicts "no" looks 94% accurate and is useless. Evaluate on AUC / precision / recall — never raw accuracy.

var m = ml.BinaryClassification.Evaluate(model.Transform(split.TestSet));
// AUC, PositivePrecision, PositiveRecall, F1

// CS can only call ~30 tenants/week -> tune the threshold for PRECISION:
bool flag = prediction.Probability >= 0.62;   // from the PR curve, not 0.5

Result: AUC 0.86, precision 0.71 at the threshold CS actually works. The weekly at-risk list is model-ranked instead of a brittle if.

Clustering — segment tenants (no labels)

var pipeline = ml.Transforms.Concatenate("Features",
        "CampaignsPerMonth", "AvgAudienceSize", "ReportDownloads",
        "SeatUtilization", "ApiCallsPerDay")
    .Append(ml.Transforms.NormalizeMinMax("Features"))   // critical: k-means is scale-sensitive
    .Append(ml.Clustering.Trainers.KMeans("Features", numberOfClusters: 5));

Result: 5 clusters, silhouette 0.52 — distinct enough the product team named them ("power users," "dormant SMBs," "report-only"). The old size-based SQL never surfaced "report-only," a high-churn group hiding inside "enterprise."

Serving in production (the part tutorials skip)

A trained ITransformer is not thread-safe to predict from directly. Use PredictionEnginePool — thread-safe, fast, hot-reloadable:

builder.Services.AddPredictionEnginePool<ChurnInput, ChurnPrediction>()
    .FromFile(modelName: "churn", filePath: "Models/churn.zip", watchForChanges: true);

The nightly retrain job trains, evaluates, and gates on a metric floor before swapping the file — never ship a regression:

if (auc >= 0.80) ml.Model.Save(model, trainSet.Schema, "Models/churn.zip"); // pool hot-reloads

Result: prediction p95 45 ms -> 2.8 ms, zero-downtime model promotion.

The classic mistake: data leakage

Catching one leaked feature (a final_invoice_flag that only existed after churn) dropped offline AUC from a too-good 0.97 to an honest 0.86 — and the honest model is the one that works on live tenants. Every feature must be knowable at prediction time. A suspiciously high AUC is a leak until proven otherwise.

When ML.NET is the wrong call

Deep learning, transformers, LLMs, computer vision belong in Python (or an API) — ML.NET can consume an ONNX model but won't train a state-of-the-art net. If your data scientists live in Python daily, don't fight that. ML.NET wins when the engineering team owns the model and the problem is classical.

The closing mental model

Classical ML is data engineering with an evaluation step — pick the language your app is already in. Regression, classification, and clustering are data -> transforms -> trainer -> metrics. ML.NET gives a .NET team all four in C#, in-process, with no second runtime to operate.

The full guide has the before/after architecture diagrams, every pipeline in full, the trainer cheat-sheet, the pre-ship checklist, and the aggregate Mattrx metrics:

https://prepstack.co.in/blog/no-python-no-phd-train-ml-models-csharp-mlnet

Originally published on PrepStack.

Build a RAG Chatbot in C# with Semantic Kernel + Azure AI Search (2026) — Full Production Guide, Real Code, Metrics

kirandeepjassal-crypto — Wed, 16 Sep 2026 16:56:56 +0000

Every "build a RAG chatbot in 30 minutes" tutorial ends at the demo. Then you ship to production and discover the index has no security trimming, hallucinations are 22% because there's no grounding instruction, the model burns tokens with no cache, partner A can read partner B's docs, and latency is 4 seconds because chunks are too big.

A production RAG chatbot in C# has ten more pieces. This is the full build, with real metrics from Mattrx Help — a multi-tenant marketing analytics SaaS (Angular 19 + .NET 9, 110k MAU). The in-app docs assistant indexes ~3,200 docs (~24k chunks), serves ~8,400 MAU, and runs at 4% hallucination, p95 retrieval 95ms, $0.004/query.

The stack

Layer	Choice	Why
Orchestrator	Semantic Kernel	First-class .NET, plugins, telemetry
Vector index	Azure AI Search	Hybrid BM25+vector, security trimming, reranker
LLM	Azure OpenAI (gpt-4o-mini)	Same tenant, managed identity
Embeddings	text-embedding-3-small (1536d)	Best price/quality in 2026
Chunking	400-600 tokens / 80 overlap	Sweet spot for docs
Retrieval	Hybrid + semantic reranker	Best recall at scale
Grounding	System prompt + cited chunks	Cuts hallucination 22% -> 4%
Streaming	Server-Sent Events	TTFT < 500ms
Cache	Redis (question hash, 60s TTL)	34% hit rate
Eval	80-question golden set, nightly	Catches regressions before users

Azure AI Search vs pgvector — the honest call

The deciding factor was the semantic reranker. Hybrid search alone got 84% top-5 recall. Adding the L2 cross-encoder reranker pushed it to 91%. For a customer-facing assistant, that 7-point bump was worth $248/month.

If you're not on Azure or don't need the reranker, pgvector is still the right answer. Don't pick AI Search because it sounds enterprise — pick it if the constraints match: multi-tenant security + reranking + already on Azure.

The five things that actually moved the numbers

1. The system prompt does most of the work. Three rules dropped hallucination 22% -> 4%: "Use ONLY the excerpts" (grounding), "If not in excerpts, say so" (an escape hatch so the model isn't pressured to confabulate), and "Cite [n]" (makes hallucinations visible and reviewable in eval).

2. Security trimming is part of the query, not a post-filter. In a multi-tenant app the most common production bug is showing tenant A's data to tenant B. The Azure AI Search filter (partnerId eq '*' or partnerId eq '{partnerId}') is enforced server-side — even a manipulated query can't get rows outside the partner's scope. Write an integration test that asserts it, every release.

3. The reranker is the most underrated feature. A 7-point recall bump for one config flag + a tier upgrade.

4. Streaming is product UX. A 2-second response feels broken; one that starts streaming in 380ms feels instant. SSE, end-to-end.

5. Tenant-scoped cache key. 34% hit rate cuts cost by a third. NEVER a global key.

Production metrics (after 4-week build + 2-week tuning)

Metric	Value
Top-5 retrieval recall	91% (84% hybrid -> 91% reranker)
Answer cites a source	96%
Hallucination rate	4% (22% before grounded prompt)
Query latency p95 (Azure Search)	95 ms
TTFT p95	380 ms
End-to-end p95 (cache miss)	2.1 s
End-to-end p95 (cache hit)	120 ms
Cache hit rate	34%
Cost per query (cache incl.)	$0.004
Total monthly infra	~$1,688
Tickets deflected / month	~520 (~$13,000 saved)
User-rated "helpful"	84% (vs 61% human first-response)

The chatbot pays for itself ~8x in deflected support tickets. The architecture is mostly Microsoft pieces glued together with ~600 lines of careful C#.

The right mental model

A production RAG chatbot is four boring pieces composed correctly: a vector store, a retriever, a grounded prompt, and a streaming UI. Three habits that make it pay off:

Treat the system prompt + eval set as a unit — never change the prompt without running the eval.
Tenant-scope every cache key and security filter.
Streaming + grounded prompt + cache + cost cap on day one — none are optimization, they're the minimum.

The full guide has the complete Semantic Kernel C# — index schema, batched ingestion, the hybrid retriever, the grounded prompt, SSE streaming, tool-calling plugins, the OpenTelemetry trace, the eval harness, and per-partner cost monitoring:

https://prepstack.co.in/blog/build-rag-chatbot-csharp-semantic-kernel-azure-ai-search-step-by-step-guide

Originally published on PrepStack.

Agentic RAG vs Traditional RAG in .NET (2026) — When Each Wins, Semantic Kernel Code, Production Metrics

kirandeepjassal-crypto — Mon, 14 Sep 2026 12:24:13 +0000

Traditional RAG is what every "ChatGPT for your docs" tutorial builds: embed the question, fetch top-k chunks, stuff them into a prompt, return the answer. It works beautifully for ~75% of the questions you'd ask a support assistant. Then someone asks "My conversion rate dropped 18% last week — check my webhook logs, the dashboard error rate, related docs, and tell me what's wrong" and traditional RAG falls over. That question needs log inspection, a SQL query, a doc lookup, a recent-events check, a hypothesis, and validation. That's an agent.

This is the condensed walkthrough; the full guide (complete Semantic Kernel code for both, the router, and the full metrics table) is on my site 👇

Full guide: https://prepstack.co.in/blog/agentic-rag-vs-traditional-rag-dotnet-comparison-guide

The decision matrix

Dimension	Traditional RAG	Agentic RAG
Steps per query	1 (retrieve → generate)	3–8 (plan → tools → critique → synth)
Tool calls	0	2–6 on average
Cost / query	$0.004	$0.038 (~10×)
Latency p95	2.1 s	8.2 s (~4×)
Best for	FAQ, doc lookup, "where is X"	Multi-step analysis, debugging, "why is X"
Accuracy — simple Qs	78%	71%
Accuracy — complex Qs	32% (hallucinates)	84%
Right model	gpt-4o-mini	gpt-4o (mini struggles to plan)

The 2026 rule of thumb: use a router. Traditional RAG by default; agentic RAG when the question requires multiple tools, multiple knowledge sources, or iteration.

What makes a RAG "agentic"

Traditional RAG = retrieve(question) → generate(prompt). Agentic RAG = agent(question) — the agent decides what to retrieve, in what order, and stops only when it's confident.

TRADITIONAL RAG                 AGENTIC RAG
retrieve top-k                  plan -> pick tool -> execute
build prompt                      -> critique ("enough?")
generate                          -> loop until confident (cap at 6)
                                  -> synthesize with all context

The four things only agents can do: decompose ("compare Q1 to last year and recommend") into sub-questions; iterate (reformulate if the first retrieval returned junk); choose tools (searchDocs for definitions, runSqlQuery for numbers, getRecentLogs for debugging); self-critique (judge whether the answer is grounded before returning). Need none of those four? Traditional RAG is the right choice.

The four costs of going agentic: money (4–8 LLM calls/query), latency (sequential tool calls push p95 from 2s to 8s+), debuggability (a wrong agent means reading 6 prompts + 6 tool results + a plan tree), and failure modes that can't happen with traditional RAG (loop forever, stop too early, wrong tool).

Agentic RAG needs five pieces

Tools — typed functions the agent can call (side-effect aware).
System prompt — role, instructions, "when to stop" rules.
Loop — orchestration that keeps calling the LLM until done (Semantic Kernel's auto function-calling).
Critic — "you have enough info" vs "go look more."
Budget guards — max iterations, max cost, max tool calls.

Tools follow three rules: server-side identity (user.TenantId from the JWT, never from the agent — the agent cannot access another tenant), read-only by default (mutations need explicit user confirmation), and rich Description attributes (the LLM reads them to choose tools; bad descriptions = bad choices).

The router — the highest-ROI piece

The router classifies each incoming query "traditional" or "agentic" and dispatches. It's a gpt-4o-mini classification call at temperature 0 with a JSON response — ~$0.0002/query, ~80ms p95.

Without router (everything agentic):
  13,800 queries/day x $0.038 = ~$15,700/month

With router (78% traditional, 22% agentic):
  10,800 x $0.004 + 3,000 x $0.038 + 13,800 x $0.0002 (router) = ~$4,800/month

Monthly savings: ~$10,900.

That's the single highest-ROI decision in the AI stack. Build the router first.

I run both in production (Mattrx)

Mattrx Help is traditional RAG (in-product docs assistant — "how do I X", "what does error 4012 mean"). Mattrx Insights is agentic RAG (analytical assistant — "why did conversions drop", "debug my integration") with six tools (docs search, analytics query, recent events, log search, config status, period compare); the agent picks 2–4 per query. A router sits in front. After 4 weeks running both:

Metric	Traditional (Help)	Agentic (Insights)	Routed (blended)
Daily queries	12,000	1,800	13,800
Avg cost / query	$0.004	$0.038	$0.012
Accuracy — simple	78%	71%	78%
Accuracy — complex	32%	84%	84%
Hallucination (complex)	18%	6%	overall 5%
Monthly OpenAI bill	~$1,440	~$2,050	~$4,800 (vs $15,700 agentic-only)
"This was helpful"	84%	89%	86%

Routed mode is strictly better than either alone: better accuracy than traditional (complex queries get the agent), cheaper than agentic-only (simple queries skip the agent), acceptable latency (only the 22% that need agentic pay 8s).

The model to carry forward

Traditional RAG is retrieve → generate. Agentic RAG is plan → loop(tool → critique) → synthesize. A router decides which to use. Three habits prevent 90% of the pain: build the router first (cheaper, saves money day one, you'll need it forever); treat tools as a public API (server-side identity, read-only by default, rich descriptions, multi-tenant tested); hard caps on iterations + cost + daily volume (agents will try to loop and will try to spend $5 on a $0.04 question).

The full guide has the complete Semantic Kernel C# — traditional service, agentic service with the auto-function-calling loop and budget guards, the tool plugins, and the router + classifier — plus a step-by-step trace of an agent debugging a real conversion drop, the architecture diagram, and the full metrics:

https://prepstack.co.in/blog/agentic-rag-vs-traditional-rag-dotnet-comparison-guide

Originally published on PrepStack.

Design YouTube — Video Upload, Transcoding & CDN Delivery at Scale (with Production .NET Code)

kirandeepjassal-crypto — Sun, 13 Sep 2026 12:01:27 +0000

"Design YouTube" is where two systems live in one product, pulling in opposite directions. The write side is a brutal batch-processing problem: someone uploads a multi-gigabyte file, and you have to turn it into a dozen resolutions and formats without melting your servers. The read side is a caching problem at planetary scale: billions of people press play and expect video to start in under a second, anywhere on Earth. The interview is about keeping those two apart — a queue-and-worker transcoding pipeline for the write, and a CDN for the read.

This is the condensed walkthrough; the full guide (estimates, API, data model, and the full production .NET 9 code) is on my site 👇

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

The design at a glance

Concern	Decision
Upload	Resumable, chunked upload straight to blob storage
Processing	Transcoding pipeline — queue + stateless worker fleet, chunk → transcode → package
Storage	Object/blob storage for raw + renditions (petabyte scale, tiered)
Delivery	CDN at the edge — the origin sees only cache misses
Playback	Adaptive bitrate (HLS/DASH) — the player picks quality by bandwidth
View counts	Approximate + aggregated — never a DB increment per view

It's two systems sharing a blob store

The two sides scale very differently:

Uploads:  ~1M videos/day, raw files tens of MB-GBs  -> petabytes of storage, huge transcode compute
Views:    billions/day  ->  ~tens of thousands of segment fetches/sec, served from the CDN edge
Read:write ratio: enormous  ->  the CDN, not the origin, carries the traffic

Storage and transcode compute dominate the write side; the CDN is not optional on the read side — it's the only way billions of views don't vaporize your origin.

Uploader --> [ Upload service ] == resumable, chunked ==> [ Blob: raw upload ]
                                                                 | event: uploaded
                                                                 v
                                     [ Transcoding pipeline - queue + worker fleet ]
                                     chunk -> transcode (144p...4K, multi-codec) -> package (HLS/DASH)
                                                                 |
                                                                 v
                                     [ Blob: renditions ] --> [ CDN edge ] --> Viewers
                                     [ Metadata DB ]   [ View counter (aggregated) ]

The write pipeline (upload → transcode → store) and the read path (CDN → viewer) meet only at the blob store. Playback never waits on a transcoder; uploads never touch the CDN.

The hard parts

Resumable, chunked upload. A multi-gigabyte upload over mobile will drop mid-transfer; a single POST that restarts from zero is unusable. The client uploads fixed-size chunks (with offsets) directly to blob storage via a pre-signed URL, and a dropped connection resumes from the last good chunk. The app server issues the URL and reacts to the completion event — it never proxies the bytes.

The transcoding pipeline — the write core. A raw upload must become many renditions (144p→4K) across codecs, packaged for streaming:

Chunk the raw video into segments so they transcode independently.
Transcode each segment to each target resolution/bitrate — an embarrassingly parallel fan-out across a stateless worker fleet (this is where the compute goes).
Package the transcoded segments into HLS/DASH + a manifest.

It's a DAG of jobs driven by a message queue: workers pull segment-transcode tasks, scale horizontally with queue depth, and are idempotent and retried (a failed segment re-runs; the pipeline dead-letters what won't).

Adaptive bitrate streaming (HLS/DASH). The packaged video is a set of short segments at multiple bitrates plus a manifest. The player downloads the manifest, starts at a modest bitrate, and switches up or down per segment based on measured bandwidth.

Player reads the manifest, then picks a rendition per segment by bandwidth:

   4K    ############   ~25 Mbps    <- fast wifi
  1080p  ########       ~8 Mbps
   720p  #####          ~5 Mbps
   480p  ###            ~2.5 Mbps
   240p  #              ~0.7 Mbps    <- weak mobile

The crucial part: the server serves static segments — all the adaptation logic lives in the player. That's what makes delivery a pure CDN problem.

CDN delivery — the read path. Views dwarf uploads and viewers are global. Serve every segment from a CDN: edge caches near the viewer hold popular content, so the origin (blob store) is hit only on a cache miss. This is what makes playback start fast worldwide and keeps billions of views from ever reaching your origin. The CDN is the read architecture.

View counts at scale. Billions of views can't each UPDATE views SET count = count + 1 — a hot-row meltdown. Aggregate: buffer increments (in Redis or a stream), flush periodic batches to the metadata store, accept approximate, eventually consistent counts.

Scaling gotchas

Transcode compute is the write bottleneck — a big worker fleet autoscaled by queue depth, often on cheap spot instances (jobs are idempotent, so eviction is fine).
CDN absorbs the read load; pre-warm popular videos at the edge.
Storage is petabyte-scale — tier cold, rarely-watched videos to cheap storage.
Pipeline resilience — idempotent jobs, retries, a DLQ for un-transcodable uploads.
Never proxy the bytes through your app server — the client talks to blob storage directly; your server orchestrates.

I shipped this shape in production (Mattrx)

Mattrx isn't a video site, but its report generation runs on the exact same shape: a heavy artifact produced by an async worker fleet, stored in blob storage, and delivered from a CDN. Marketers export branded PDF reports of campaign performance — Mattrx renders about 1.2 million every 48 hours with PuppeteerSharp. V1 generated the PDF synchronously inside the request: a big report took 30–60 seconds, tied up a web worker, timed out under load, and was streamed back through the app server. We rebuilt it as this design — enqueue on Azure Service Bus, render on a worker fleet, drop the PDF in Azure Blob Storage, serve it from Azure Front Door (CDN) via a signed URL:

Metric	Before	After
Report request	Blocked 30–60s in the request (timeouts under load)	`202 Accepted`, enqueue p95 ~90 ms
Generation	Synchronous, tied up a web worker	Async worker fleet (PuppeteerSharp)
Throughput	Capped by the web tier	~1.2M reports / 48h
Delivery	Streamed through the app server	Azure Front Door CDN (signed URL, edge)
API write-path p95	Dragged down by report load	120 ms (fully decoupled)
Worker cost	Baseline	~$1,300/mo saved (right-sized async fleet)

The API does no rendering — it writes a pending row, drops a command on Service Bus, and returns a job id in ~90 ms; the worker fleet does the expensive PuppeteerSharp render and stores the PDF in Blob Storage; and delivery is a signed URL fronted by Azure Front Door, so the finished report streams from the edge — the same decoupling that keeps YouTube's playback independent of its transcoders. (Full .NET 9 API + worker is in the post.)

The model to carry forward

A video platform is two decoupled systems sharing a blob store. The write side is a queue-and-worker batch pipeline — resumable upload, parallel transcoding across a stateless fleet, packaged into adaptive segments — and the read side is a CDN in front of static files that carries essentially all the traffic. Keep them apart: playback depends only on the blob store and the CDN, never on the transcoders; uploads never touch the read path.

Three habits it teaches: split the write pipeline from the read path (batch-process on workers, serve static from a CDN, let them meet only at the blob store); never move big bytes through your app server (clients talk to storage directly); approximate what's expensive to be exact (view counts are aggregated and eventually consistent).

That wraps my System Design Interview series — ten "Design X" walkthroughs on one framework. The full guide has the estimates, API, data model, all the hard parts in depth, scaling, the complete production .NET 9 pipeline, and the "when it's overkill" section:

https://prepstack.co.in/blog/design-youtube-system-design

Originally published on PrepStack.

Design Uber — Geospatial Matching, Live Location & Surge Pricing (with Production .NET Code)

kirandeepjassal-crypto — Sat, 12 Sep 2026 09:58:20 +0000

"Design Uber" comes down to one question that sounds easy and isn't: given a rider standing here, find the nearby available drivers — right now, among millions of them, while every one of those drivers is moving and pinging a new location every few seconds. Do it the obvious way — compute the distance from the rider to every driver — and you're doing millions of calculations per request. The entire interview is the data structure that turns "search everywhere" into "search the few blocks around the rider."

This is the condensed walkthrough; the full guide (estimates, API, data model, and the full production .NET 9 code) is on my site 👇

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

The design at a glance

Concern	Decision
Find nearby drivers	Geospatial index (geohash / quadtree / H3) — search the rider's cell + neighbors
Driver locations	In-memory geo index (Redis GEO), sharded by region — not a DB table
Location ingestion	Persistent connections; update the index, don't write each ping to a DB
Matching	Rank nearby drivers by ETA, offer, and lock the driver to avoid double-dispatch
Surge	Per-cell demand ÷ supply ratio, updated continuously
Live trip	Stream driver location to the rider over a WebSocket

Two forces: a write firehose and a proximity read

The write side is the monster:

Drivers: ~5M active, each pings location every ~4s
  -> 5,000,000 / 4  ~  1.25M location updates/sec

Ride requests: millions/day  ~  hundreds/sec, each a nearby-driver search

You cannot write 1.25M rows/sec to a relational database, so driver location lives in an in-memory, sharded geo index updated in place; and the proximity search must be cell-bounded, never a scan over millions of drivers.

Drivers == location every ~4s ==> [ Location ingestion ] --> [ Geo index (Redis GEO), sharded by region ]
                                                                    ^
Rider request (pickup) --> [ Matching service ] -- search nearby cells
                                |  rank by ETA - offer - LOCK driver
                                v
                         [ Ride store ] - [ Trip tracking (WebSocket) ] - [ Surge (per cell) ]

The hard parts

Geospatial indexing — the heart of it. The naive approach — distance from the rider to every driver — is O(N) per request and dies at millions of drivers. Instead, partition space into cells and bucket drivers by cell; a proximity search only examines the rider's cell and its neighbors.

Geohash: interleave lat/lng bits into a string. Nearby points share a prefix, so a cell is a prefix and "nearby" is "matching prefix + the 8 neighbor cells." Simple, and what Redis GEO uses under the hood.
Quadtree: recursively split space into four quadrants; dense areas (downtown) subdivide deeper — adaptive to density.
S2 (Google) / H3 (Uber): hierarchical global cell systems; Uber's H3 uses hexagons (uniform neighbor distance, no corner problems).

A geohash cell + its 8 neighbors — a "nearby" search scans these 9 cells:

      +-----+-----+-----+
      | NW  |  N  | NE  |
      +-----+-----+-----+
      |  W  |  *  |  E  |     * = the rider's cell
      +-----+-----+-----+
      | SW  |  S  | SE  |
      +-----+-----+-----+

You examine ~9 cells' worth of drivers, never all N drivers.

The location write firehose. 1.25M updates/sec can't hit a database. Drivers stream location over persistent connections; the ingestion layer updates the driver's position in the in-memory geo index in place (one current position, not a history of rows). The index is sharded by region (geohash prefix), so each shard owns its slice of the map and the write load spreads. Hot regions get finer shards.

Matching — closest isn't the answer, best ETA is. A nearby search returns candidates; ranking by straight-line distance is wrong — a driver 200m away across a river is farther by road than one 500m away on the same street. Rank by ETA (road-network + traffic). Then offer the ride to the top driver and lock them (a short hold) so a second rider's search can't dispatch the same car; if they decline or time out, release and offer the next. Locking prevents double-dispatch.

Surge pricing. Per cell, compute demand ÷ supply — open requests vs available drivers. When demand outstrips supply, a surge multiplier rises for that cell, pricing the scarcity and nudging drivers toward it. A continuously recomputed, per-region number — and a feedback loop, so tune it or it oscillates.

Live trip tracking. Once matched, the driver's location streams to the rider in real time — the exact push-over-WebSocket problem from the chat design.

Scaling gotchas

Ingestion firehose: in-memory geo index, sharded by region; persistent connections, not per-ping HTTP.
Hot cells (downtown, a stadium at closing): split finer; the index adapts to density, or that cell melts.
Proximity search: cell-bounded and served from memory — the whole point.
Consistency: driver location is eventually consistent (seconds stale is fine); dispatch uses a lock where it matters.
Durability split: rides persist relationally; location stays ephemeral in Redis (a lost ping just re-arrives in 4s).
Privacy: streaming precise movement of millions is a serious responsibility — minimize retention.

I shipped this in production (Mattrx)

Mattrx isn't ride-hailing, but its geo-analytics run on exactly this proximity-search machinery. Conversions carry coordinates, and marketers ask location questions: "how many conversions within 5 km of this store?" (footfall attribution) and "render a heatmap of engagement." V1 answered those with a Haversine distance filter scanned across the CampaignEvents table (1.2B rows) — a full range scan per query, p95 ~1,800 ms that pinned the DB whenever a marketer dragged the map. We moved recent conversion events into per-tenant Redis GEO sets on ingestion, so a radius question becomes a geohash-bounded GEOSEARCH over a few cells:

Metric	Before	After
"Conversions within 5 km of a store" p95	~1,800 ms (Haversine scan)	~12 ms (Redis `GEOSEARCH`)
Rows examined per query	full `CampaignEvents` range scan	a few geohash cells
Store-attribution DB load	heavy per query	offloaded to the Redis geo index
Geo-heatmap render	seconds, laggy panning	sub-second, smooth

GeoAddAsync upserts a conversion's position by encoding it into a geohash score, and GeoSearchAsync with a GeoSearchCircle does the cell-bounded radius query natively — so a "near this store" question touches a handful of geohash cells in memory instead of Haversine-scanning a billion rows in Azure SQL, the whole difference between an 1,800 ms map drag and a 12 ms one. (Full .NET 9 geo index is in the post.)

The model to carry forward

Ride-hailing is a proximity-search problem wrapped in a location firehose. You never search all drivers — you bucket the map into cells, drop drivers into cells, and a nearby search touches only the cells around the rider. Keep that index in memory because the write rate is enormous, shard it by region so it scales and adapts to density, match on ETA rather than distance, and lock a driver during an offer so you never book one car twice.

Three habits it teaches: reach for a spatial index immediately ("distance to every driver" fails; "cell + neighbors" scales); keep the firehose out of your database (a current-location-per-driver index in memory beats a million writes/sec to disk); match on ETA, lock on dispatch (distance is a lie the map tells; the driver lock keeps matching correct).

The full guide has the estimates, API, data model, all the hard parts in depth, scaling, the complete production .NET 9 Redis GEO code, and the "when it's overkill" section:

https://prepstack.co.in/blog/design-uber-system-design

Originally published on PrepStack.

Design a Payment System — Idempotency, Ledgers & Exactly-Once at Scale (with Production .NET Code)

kirandeepjassal-crypto — Fri, 11 Sep 2026 16:24:43 +0000

"Design a payment system" is the one where scale is not the point. Nobody cares that it does ten thousand transactions a second; they care that it never does one transaction twice, never loses one, and can prove — line by line, months later — exactly where every cent went. The interview lives in four words: idempotency, ledger, and reconciliation.

This is the condensed walkthrough; the full guide (estimates, API, data model, and the full production .NET 9 code) is on my site 👇

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

The design at a glance

Concern	Decision
Double-charge safety	Idempotency key (unique) — a retry returns the first result, never re-charges
Money records	Double-entry ledger — balanced entries; balances derived, not stored
Provider events	At-least-once + dedup by event id (exactly-once is a myth)
Consistency	Ledger writes atomic (DB transaction); external charge bridged by a state machine
Safety net	Reconciliation — compare ledger to provider daily; flag discrepancies
Card data	Never store it — tokenize via the provider (PCI)

It's a correctness problem, not a scale problem

Say the quiet part out loud: even a large processor does a few million transactions/day ≈ tens–hundreds/sec. That fits comfortably on a well-indexed relational database. So you spend the budget not on sharding and caching but on invariants: uniqueness constraints for idempotency, a balanced ledger, and a reconciliation job. Correctness is the scarce resource here, not QPS.

Client --> [ Payment API ] -- idempotency check --> [ Provider (Stripe) ]
                |  (pending)                              |
                v                                         | webhook (at-least-once)
          [ Ledger (double-entry, atomic) ] <-- dedup ---+  payment_intent.succeeded
                |
          [ Reconciliation job ] -- daily compare vs provider --> flag discrepancies

The hard parts

Idempotency — the whole ballgame. A client charges, the request times out, the client retries. Did the first attempt succeed? You can't know from the client side — so the server makes the retry safe. The client sends an idempotency key; the server stores it under a unique constraint before doing anything expensive. On a retry the key already exists, so you return the stored result instead of charging again. Pass the same key to the provider too (Stripe's Idempotency-Key header) so even the external call dedups. One key, one charge, forever.

You can't make the charge and the ledger one transaction. The provider is external — you cannot enroll "call Stripe" and "write my ledger" in one ACID transaction. Use a state machine: record the payment as pending (committed), call the provider, and let the webhook drive the authoritative transition to succeeded/failed, at which point you post the ledger — all in one local transaction. Internal ledger strongly consistent; external settlement eventually consistent; the webhook is the bridge.

Double-entry ledger — the books must balance. Never store a single mutable balance. Every money movement posts balanced entries — debits equal credits, netting to zero — into an immutable, append-only ledger. A successful charge might debit Cash and credit the customer's Receivable. Balances are derived (SUM over an account), so the ledger is auditable, replayable, and self-checking: if a transaction's entries don't sum to zero, reject it.

Webhooks are at-least-once — dedup them. The provider will occasionally deliver the same payment_intent.succeeded twice; applying it twice double-credits the ledger. Guard every handler with a UNIQUE(eventId) dedup log: record the event id first; if it's already there, the second delivery is a no-op.

Reconciliation — the backstop. What if a webhook is lost? The charge succeeded at the provider but your ledger never recorded it — a silent gap. A scheduled job pulls the provider's transaction list and compares it to your ledger, flagging anything that exists on one side but not the other. Reconciliation turns "hope the webhook arrived" into "prove the books match."

Failure & scaling gotchas

Provider timeout (the classic): you called Stripe and got no response. Don't blindly retry the charge — retry with the same idempotency key (safe), or query the provider for the intent's status. Reconciliation catches whatever slips through.
Ledger scale: append-only writes scale well; partition by account/time; balances via periodic snapshots + entries since.
Outbox for downstream events: publish payment.succeeded to other services via the outbox pattern so a crash can't drop the event.
Refunds/reversals are just more balanced entries — never delete or mutate existing ones.
PCI: never let raw card numbers touch your servers; tokenize through the provider and store only the token.

I shipped this in production (Mattrx)

Mattrx bills ~thousands of tenant workspaces through Stripe. V1 was dangerously naive: it charged inline, and a timeout on Stripe's response left it not knowing whether the charge landed — so a retry occasionally double-charged a customer, cleaned up by hand. "Paid" was a boolean on the subscription row, so there was no audit trail and monthly reconciliation was a spreadsheet. We rebuilt it as exactly the design above:

Metric	Before	After
Double-charges on retry	A handful a month (manual refunds)	0 (idempotency key + Stripe `Idempotency-Key`)
Money record	`paid` boolean on the subscription	Immutable double-entry ledger (always reconciles)
Webhook double-application	Occasional double-credit	0 (`UNIQUE(eventId)` dedup)
Reconciliation vs Stripe	Manual spreadsheet (~hours/month)	Automated nightly, discrepancies auto-flagged
Billing disputes from double-charges	Non-zero	0 in the last two quarters

The charge path reserves the idempotency key before calling Stripe and passes the same key onward, so a client retry and a provider retry both collapse to one charge; the webhook handler dedups on event_id and posts a balanced ledger transaction inside one local DB transaction; and Ledger.PostAsync refuses to write anything that doesn't net to zero — so the books are correct by construction, and the nightly reconciliation job catches the one thing code can't: a settlement Stripe recorded but never told us about. (Full .NET 9 billing service + webhook handler + ledger is in the post.)

The model to carry forward

A payment system is a machine for staying correct when you don't know what happened. The timeout is the enemy, and every part of the design is a defense against it: an idempotency key so retries are safe, a state machine so an external charge and an internal record don't have to be one transaction, a double-entry ledger so the truth is auditable and self-checking, deduped webhooks so at-least-once behaves like once, and reconciliation so a lost message can't quietly corrupt the books.

Three habits it teaches: lead with idempotency ("the client sends an idempotency key" frames the entire correctness story); make money a ledger, not a number (immutable balanced entries with derived balances is the only design an auditor or a bug can't break); assume the webhook can be lost (reconciliation is what turns hope into proof).

The full guide has the estimates, API, data model, all the hard parts in depth, failure/scaling, the complete production .NET 9 code, and the "when it's overkill" section:

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

Originally published on PrepStack.