DEV Community: Vignesh Athiappan

We Cut a 190 GB Production Database to 45 GB in One Night. Here's What We Learned

Vignesh Athiappan — Mon, 10 Aug 2026 11:44:35 +0000

We Cut a 190 GB Production Database to 45 GB in One Night. Here's What We Learned.

Our flagship internal application had a storage problem. Twelve years of accumulated project data had pushed the production database past 190 GB, and we were about to migrate it to a managed cloud instance where every gigabyte carries a monthly bill.

The mandate was simple: get it under control before the migration. The execution was less simple.

Here's how it went, and the six things I'd tell anyone attempting the same.

Lesson 1: Your database is probably smaller than you think

The first number everyone quoted was 190 GB. That's what the file size said, and that's what went into the planning deck.

Then we actually measured it:

SELECT name,
       CAST(size*8/1024.0/1024 AS decimal(10,1)) AS AllocatedGB,
       CAST(FILEPROPERTY(name,'SpaceUsed')*8/1024.0/1024 AS decimal(10,1)) AS UsedGB
FROM sys.database_files;

Allocated: 190.6 GB. Actually used: 106.7 GB.

Eighty-four gigabytes of the file was empty space — pages that had been allocated during past growth spikes and never released. The database had been quietly lying to us for years.

This changed the entire plan. We didn't need to delete 150 GB of data. We needed to delete about 65 GB and then reclaim the empty space that was already there.

Takeaway: allocated size and used size are different numbers, and stakeholders almost always quote the wrong one. Measure both before you scope anything.

Lesson 2: Size doesn't correlate with row count

We built a per-table inventory expecting the biggest tables to be the ones with the most rows. Mostly true — but the outliers were where the real wins were.

One configuration table held 13 GB across 21,000 rows. That's roughly 640 KB per row. It was storing serialized blobs, and nobody had ever cleaned it up because it "only had twenty thousand rows in it."

An attachment metadata table: 3.7 GB across 8,700 rows.

Meanwhile a history table with 30 million rows took 2.2 GB, because it was six narrow integer columns.

Takeaway: rank tables by megabytes, not row count. The blob-heavy tables hiding behind small row counts are often the fastest wins available — and they're invisible if you only look at sys.partitions.rows.

(Related trap: if you join sys.partitions to sys.allocation_units to get sizes, your row counts get multiplied by 2–3× for any table with LOB or overflow allocation units. Trust the MB column from that query; get row counts from a separate `COUNT()`.)*

Lesson 3: The transaction log will kill you before the data file does

This is the one that nearly ended the night early.

We had 40 GB free on the data volume. The plan was to delete ~65 GB of rows. In full recovery mode, with no log backups running (we'd stopped the scheduler for the maintenance window), every one of those deletes would accumulate in the transaction log until the volume filled and the whole operation rolled back — a rollback that would itself need log space it didn't have.

Delete operations log the full row image plus every index entry removed. Log volume typically meets or exceeds the data volume being deleted. We were looking at 65+ GB of log growth into 40 GB of free space.

The fix was one line:

ALTER DATABASE MyDatabase SET RECOVERY SIMPLE;

In simple recovery, the log truncates at every checkpoint. Ours stayed at 6.5 GB for the entire three-hour run — it never grew a single megabyte.

This is safe specifically because of the conditions we'd established: applications were offline, no users were writing, and we had a verified full backup as our rollback. We weren't giving up anything we needed.

Critical follow-up: switching back to full recovery afterward is not enough on its own.

ALTER DATABASE MyDatabase SET RECOVERY FULL;
BACKUP DATABASE MyDatabase TO DISK = '...' WITH COMPRESSION, INIT;

Until that backup runs, the database sits in what's often called "pseudo-simple" mode — the recovery chain is broken and log backups will fail. This step gets skipped constantly. Don't skip it.

Lesson 4: Gates and abort flags, not rollbacks

The purge script was structured in six waves, each handling a dependency layer — child records first, then parents, then orphan sweeps.

Between every wave sat a gate: a verification query that confirmed zero remnants before the next wave was allowed to start. And before every destructive batch, the script checked a control table:

IF EXISTS (SELECT 1 FROM dbo.Purge_RunState WHERE Aborted = 1)
BEGIN
    PRINT 'SKIPPED (aborted)';
    RETURN;
END

That abort flag meant a second session could halt the run at the next batch boundary without triggering a multi-hour rollback of work already committed. During UAT it saved us more than once.

The gates also caught something we would otherwise have missed. Wave A was planned to delete 6,435,445 rows. It deleted 8,824,935 — a difference of exactly 2,389,490. Those were orphaned parent headers whose children had just been removed, and the script logged them explicitly. Because the number reconciled to the row, we knew it was correct behaviour rather than a bug.

Takeaway: design for stopping, not for undoing. On a dataset this size, rollback is a worse outcome than a controlled halt.

Lesson 5: Prove what you didn't delete

The single most valuable thing in the script wasn't a delete — it was a set of before/after assertions on the data we promised not to touch.

Active projects   before=2154     after=2154        (must be equal)
Timesheet records before=4391749  after=4391749     (must be equal)
Task records      before=3536910  after=3536910     (expected drop=0)

Every stakeholder conversation about a purge eventually arrives at the same question: "How do you know you didn't delete something important?"

"We were careful" is not an answer. "Here are the exact counts of your financially-relevant records before and after, and they are identical" ends the conversation.

Take a snapshot of the protected data before you start. Verify against it after. Put both numbers in the communication.

Lesson 6: Deleting rows doesn't shrink the file

We finished the purge at 43 GB of actual data. The file was still 190.6 GB.

Deleting rows frees space inside the file; it doesn't return it to the operating system. That requires an explicit shrink — and shrinking 190 GB down to 45 GB means physically relocating well over 100 GB of pages.

Don't do that in one statement. A single massive SHRINKFILE can run for many hours, and cancelling it mid-flight loses everything it accomplished. Step it down instead:

DBCC SHRINKFILE (MyDatabase, 150000);
DBCC SHRINKFILE (MyDatabase, 110000);
DBCC SHRINKFILE (MyDatabase,  85000);
DBCC SHRINKFILE (MyDatabase,  65000);
DBCC SHRINKFILE (MyDatabase,  46000);

Each step completes in a manageable window, and if you have to stop, you keep the ground you've gained.

Be aware of the cost: shrinking works by moving pages from the end of the file to the front, which destroys index ordering. Expect heavy fragmentation afterward and plan an index rebuild — which will grow the file back somewhat. Budget for that before you report a final number.

The result

Metric	Before	After
File size	190.6 GB	44.9 GB
Actual data	106.7 GB	43.0 GB
Transaction log	6.5 GB	6.5 GB (never grew)
Runtime	—	3h 02m
Failed gates	—	0
Active records lost	—	0

Roughly 146 GB returned to the operating system, and a database that will cost meaningfully less to run in the cloud.

What I'd do differently

Measure earlier. Two weeks of planning were built on a number that turned out to be 44% empty space. One query on day one would have reframed the entire project.

Inventory everything, not just the suspects. Our purge script targeted 22 tables. A full-database inventory run late in the process surfaced two more totalling 5.7 GB that nobody had thought about — one of them the parent of a table we were purging, which meant we were about to create orphans.

Decide the retention policy before the maintenance window. We finished the night 3 GB above our stretch target, blocked entirely on one table that needed a business decision about how much history to keep. That decision could have been made a week earlier over email. Instead it became a follow-up item, and follow-up items have a way of becoming next quarter's items.

Take the backup twice. Once before you start. Once after you finish. The second one is the one people skip because they're tired and it's 4 AM, and it's the one that matters if something surfaces on Monday.

Every environment is different. Test on staging first — every wave and every retention rule in this operation was validated against a full production restore before it touched anything real. That discipline is the reason there's a blog post about a successful night instead of a post-mortem about a bad one.

Designing a humane involuntary exit workflow: what I learned building one

Vignesh Athiappan — Sat, 08 Aug 2026 11:40:31 +0000

Involuntary exits are the workflow nobody wants to talk about, which is exactly why most companies handle them badly — over email threads, spreadsheets, and hallway conversations. I recently spent a few weeks designing an end-to-end system for bench-driven involuntary separations for US full-time employees, and it taught me more about process design than any "happy path" workflow ever has. Here's the shape of it, with everything company-specific stripped away.

The trigger: let the system start it, never finish it

The flow begins when someone on the bench approaches the end of their allocation window with no new project confirmed. Instead of relying on a resource manager to remember to start the process, the system auto-initiates the workflow a few business days before the bench end date and notifies the resource management group (RMG).

That word initiates is doing careful work. The system opens the case; a human must verify it. RMG reviews the employee's situation, attaches a justification document, adds comments, and only then does the workflow actually move. If there's even a remote chance of a position, they can hold the case (by moving the allocation end date, which re-arms the trigger) or cancel it outright. Automation for reliability, humans for judgment.

And because people don't always act on time, the verification step carries a 24-hour SLA with daily reminders, escalating first to HR for visibility and eventually to a senior leader if it sits untouched for days. The lesson: an SLA without an escalation path is just a suggestion.

Approvals: parallel where possible, sequential where it matters

Once verified, two things happen at the same time. The employee's reporting manager gets a pure FYI — not an approval, just the chance to flag "wait, I have an opportunity for this person, expected to start on this date." Making this a comment instead of a gate was deliberate: the manager closest to the work often knows about openings first, but they shouldn't be able to stall the process by simply not responding.

In parallel, the vertical head — the actual decision-maker — gets an approval request framed as a staffing question rather than paperwork: "I have a position" (which rejects the exit and keeps the person) or "go with the exit, I don't have a position." Any one approver from a defined list is enough. If nobody acts within one business day, the case auto-approves and everyone gets notified that it did. Silence can slow a person's exit; it can never leave them in limbo forever.

Then comes the one branch in the flow: tenure. For long-tenured employees (past a defined threshold), an additional business-unit-head approval kicks in — mandatory, with no auto-approval, escalating to a configured senior contact if it sits for 24 hours. The more someone has invested in the company, the more senior the human who must personally sign off. I think that's the right instinct encoded as a rule.

The last mile: the employee hears it from a person, not a system

This was the most important decision in the whole design. The final step is deliberately not integrated with the HRIS. When all approvals are done, HR gets notified and must do three things in strict order: talk to the employee face to face, close the case in the workflow tool, and only then manually raise the exit in the HR system.

Why manual? Because the moment an exit is created in most HR platforms, automated emails fire — to the employee, to stakeholders, to IT. Nobody should learn they're being separated from a system notification. The workflow physically cannot reach the HRIS until a human confirms the conversation has happened. We gave up integration elegance to guarantee dignity, and I'd make that trade every time.

Cancellation is a feature, not an edge case

At every single stage — including after the exit has been initiated — the process can be cancelled with a mandatory reason, and whoever is currently holding the case gets notified. Opportunities appear late. Clients extend. Someone finds a role at the last minute. A separation process that can't gracefully reverse itself will either be bypassed or will hurt someone. Until the very last step, the door back stays open.

Everything is configuration, everything is audited

Two engineering choices rounded it out. First, nothing is hardcoded: triggers, stage sequences, SLAs, and escalation contacts all live in configuration tables, so a different country, a different employee type, or a different trigger (performance-based, contract end) becomes a set of rows rather than a rewrite. Second, an append-only audit log — insert-only at the database permission level — records every transition, every decision with its comments, every auto-approval, every escalation, and every email sent. When the question is "who approved this person's exit, and was it a real decision or an SLA timeout," the answer must be one query away, forever.

The takeaway

The system's job in an involuntary exit isn't to make the process faster. It's to make sure nothing is forgotten, nobody is skipped, silence never traps a case, and the human moments stay human. Automate the memory, escalate the accountability, and keep a person between the decision and the email — that's the whole design in one sentence.

Azure Managed Redis: A Field-by-Field Walkthrough of the Create Blade

Vignesh Athiappan — Wed, 05 Aug 2026 13:49:10 +0000

I recently spun up my first Azure Managed Redis (AMR) instance. The create wizard looks simple — five tabs, a handful of checkboxes — but several of those checkboxes are one-way doors, and a couple of them will silently break your applications if you get them wrong.

This is the walkthrough I wish I'd had. Every field, what it does, and what I'd actually pick.

First, a clarification that matters: Azure Managed Redis is not the same product as Azure Cache for Redis. AMR is the newer service replacing the Enterprise tiers. A lot of the blog posts and Stack Overflow answers you'll find describe the old Premium tier behaviour, and some of it is flat-out wrong for AMR. Persistence is the big one — more on that below.

The Advanced tab (where all the interesting decisions live)

Modules

Optional Redis capabilities:

Module	What it gives you
`RedisJSON`	Store and query JSON documents natively
`RedisTimeSeries`	Time-series data with downsampling
`RedisBloom`	Bloom filters, count-min sketch, top-k
`RediSearch`	Secondary indexes + vector search

RediSearch is the one to think hardest about — it's what turns Redis into a vector store for RAG workloads.

The catch: modules can only be set at creation time. You cannot add one later without rebuilding the instance. But they also consume memory and CPU, so don't enable all four "just in case."

My pick: only what I'll use in the next quarter. If vector search is anywhere on the roadmap, tick RediSearch now.

Non-TLS access only

Leave it unchecked. Checking it opens plaintext port 6379. There is no good reason to do this in production, and Entra authentication won't work without TLS anyway.

Eviction Policy

What Redis does when memory fills up.

No Eviction — writes start failing with OOM errors once full
volatile-lru — evicts least-recently-used keys that have a TTL
allkeys-lru — evicts least-recently-used keys, TTL or not

The portal defaults to No Eviction, which is the right default for a data store and the wrong one for a cache. If you're building a cache, you want it to shed cold data gracefully rather than start throwing errors at 3am.

My pick: volatile-lru for a cache. No Eviction only if losing keys is genuinely unacceptable.

High availability

Adds a replica in a second availability zone with automatic failover.

Disabling it roughly halves your cost. It also means a single node failure is total data loss with no failover. For anything production-facing, keep it Enabled.

Clustering Policy

How clients talk to the instance:

OSS — the client discovers shards and talks to each node directly. Best throughput and latency, but needs a cluster-aware client, and multi-key operations must land in the same hash slot.
Enterprise — a single proxy endpoint that behaves like one Redis server. Slightly higher latency, far less friction.
Non-clustered — smaller SKUs only.

StackExchange.Redis handles OSS fine. But if you're pointing legacy code, low-code connectors, or anything you don't fully control at this instance, Enterprise will save you debugging time.

My pick: Enterprise unless I've explicitly tested OSS with every client.

Data Persistence — read this part carefully

Three options: No Persistence, RDB, AOF.

RDB takes a point-in-time snapshot of the whole dataset on a configurable interval. Cheap in steady state. If your interval is one hour and you lose the instance at minute 59, you lose 59 minutes of writes.
AOF appends every write operation to a log, flushed once per second. Tiny loss window, but a real throughput cost. Note that with HA enabled, AOF runs on the replica shards only — primaries have appendonly disabled to avoid the write overhead.

Now the part that surprises everyone:

In AMR, persisted data is written to a managed disk attached to the instance. The location is neither configurable nor accessible to you. There is no blob to browse. No .rdb file to download. No restore-point picker.

Persistence exists so that if a catastrophic event takes out both the primary and the replica, the instance rebuilds itself automatically. It is a self-healing mechanism, not a backup product.

Two things follow from this:

Persistence is not a backup and not point-in-time recovery. If a buggy job writes corrupted data into Redis, the corruption gets faithfully persisted too.
Persisted files cannot be imported into another instance. To move data between caches — or to get an actual file you can hold — you use the separate Import/Export feature, which writes RDB files to a blob container you specify. If you want real backups, script periodic exports via CLI or PowerShell on a schedule.

The old Premium tier of Azure Cache for Redis did write RDB into your own storage account. AMR does not. That's the single most common piece of stale information out there.

My pick: No Persistence for a pure cache — the data is regenerable and I'd rather have the throughput. RDB if a cold start would hammer the backing database hard enough to matter, or if I'm holding sessions and don't want to force everyone to re-authenticate after an outage.

Persistence is changeable after creation. Not a one-way door.

Customer-managed key encryption at rest

Leaving this unchecked does not mean "unencrypted."

AMR encrypts persistence data and OS disks with Microsoft-managed keys by default. The CMK option just wraps those keys with one from your own Key Vault. The difference isn't whether data at rest is encrypted — it's who controls the key material.

CMK gives you rotation control, access auditing, and the ability to revoke (which makes the instance inaccessible — that's the point for some threat models). The cost is operational: it requires a user-assigned managed identity plus a Key Vault with both purge protection and soft delete enabled. Delete that key or break the identity's access, and your instance breaks.

Also worth noting: if you chose No Persistence, there's very little at rest to encrypt in the first place.

My pick: unchecked, unless a client contract or auditor explicitly requires customer-controlled keys. It's addable later.

Defer automatic major Redis version updates (preview)

Lets you postpone major engine upgrades so they don't land in the middle of a release window. Useful if you need change control. You still have to take them eventually.

Access Keys Authentication — the one that will break your apps

This is the field most likely to cause a bad afternoon.

Unchecked means Entra ID authentication only. No access keys, no password= in a connection string. This is now AMR's default — managed identity is enabled when you create a new instance, and Microsoft is deliberately steering people off shared secrets.

If you go Entra-only, here's what's involved:

The client acquires an Entra token (scope https://redis.azure.com/.default) and uses it in place of the password. Username is the object ID of the principal.
Tokens expire. The client must refresh before expiry and re-send AUTH, or connections drop. For .NET, use the Microsoft.Azure.StackExchangeRedis package — don't hand-roll this.
Entra auth is TLS only.
A valid token alone isn't enough. You must separately authorize the identity on the Redis side: Data Access Configuration → new Redis User → Data Owner / Data Contributor / Data Reader. No grant, no access.
Entra groups aren't supported. You add individual users or service principals. For a team of any size, that's a real operational annoyance.

Use a managed identity wherever the caller runs inside Azure. A service principal / app registration is only needed for callers outside Azure. And note that the authorization is not API permissions on the app registration — there's nothing to configure on that side.

Two gotchas:

Toggling this setting terminates all existing client connections, regardless of which auth method they were using. Do it in a window, with retry logic in place.
On geo-replicated instances you must unlink → disable keys → relink.

My pick: tick it at creation. Get everything connected and working, migrate app-by-app to Entra, then disable keys. It's changeable post-creation — unlike modules.

Quick reference: what's a one-way door?

Setting	Changeable later?
Modules	❌ No — creation only
Clustering policy	❌ No
Persistence	✅ Yes
Eviction policy	✅ Yes
High availability	✅ Yes
CMK	✅ Yes
Access keys	✅ Yes (but kills live connections)
SKU / size	✅ Yes

After it's created: the things I wish I'd known on day one

Redis is a flat key → value store. No tables, no joins, no queries. You must know the key to get the value. Your key naming convention is your schema — something like app:entity:id:field.

TTL is the whole game. Every cache key gets an expiry, or you leak memory until eviction kicks in.

It's single-threaded. One slow command blocks every other client. Which is why:

Never run KEYS * in production. Use SCAN.
Never store multi-megabyte values.
FLUSHALL has no undo.

Redis is not the source of truth. Your code must work correctly when the cache is completely empty. Test that path.

Watch for cache stampede. A thousand requests miss simultaneously and all hammer the database at once. Add jitter to your TTLs.

On the .NET side: ConnectionMultiplexer is a singleton. Register it once in DI. Creating one per request is the single most common Redis mistake and it will exhaust your connections. If you want the easy path, AddStackExchangeRedisCache() gives you IDistributedCache with straightforward get/set/TTL semantics.

The pattern you'll use 90% of the time is cache-aside: read from Redis, return on hit; on miss, read from the database, write to Redis with a TTL, return. Write that helper once and reuse it everywhere.

Finally, monitor these four things and alert on them: memory used %, evicted keys, cache hit ratio, and server load. Memory above 80% or evictions climbing above zero means it's time to scale or shorten your TTLs.

The short version

Don't overthink the sizing — that's changeable. Do think hard about modules and clustering policy, because those aren't. Leave access keys on until your clients are ready for Entra. And remember that persistence in AMR is self-healing, not a backup.

The Moving Bike on Your Food App: How Live Order Tracking Actually Works (in Azure)

Vignesh Athiappan — Tue, 04 Aug 2026 05:48:33 +0000

You order biryani on Swiggy. You keep refreshing. A little bike icon crawls across the map toward your house. It feels like magic.

It isn't. It's four tools, each doing exactly one job. This post breaks the whole thing down using that one everyday moment — no heavy theory, just the flow.

Swiggy runs on AWS; I've mapped everything to its Azure equivalent so you can build the same thing.

The cast: 4 tools, 4 jobs

Tool	Its one job	Real-life analogy
Service Bus	Carry the order — must never be lost	Registered post
Event Hubs	Carry the GPS firehose — millions of pings	CCTV recording
Redis	Hold "where's the bike right now"	Sticky note
Cosmos DB / SQL	Keep the order forever	Filing cabinet

The whole trick is: never make one tool do two jobs. Each is great at exactly one thing.

The journey, step by step

1. You tap "Place Order"

Tap → Service Bus (1 order message) → Order Service → saved to Cosmos

Service Bus = reliable, so the order can't vanish or double. Cosmos = the permanent record.

2. Restaurant gets notified

Order Service → Service Bus → Restaurant App: "New order!"

A discrete command that must arrive → Service Bus again.

3. Rider assigned — and GPS starts immediately

Rider assigned → phone GPS starts streaming → Event Hubs

This is why you can watch the bike drive to the restaurant first, then to you. GPS begins at "assigned," not at "picked up."

4. The firehose hits the pipe

Bike GPS (every ~4 sec) → Event Hubs

One bike is tiny. 500,000 bikes = ~125,000 pings/sec. Event Hubs swallows it without blinking.

5. A processor turns the firehose into one value

Event Hubs → Stream Processor → Redis: "bike_4471 = 12.97, 77.59"

Each new ping overwrites the last one in Redis. 15 pings a minute collapse into 1 sticky note.

6. You refresh the map

Your app → reads Redis (1 value, <1ms) → 🛵 dot moves

You read Redis, not Event Hubs. It's instant because it's a single lookup, not a firehose.

7. Delivered — keep only what matters

Order Service → status "Delivered" → Cosmos
Processor → sampled trail → Lakehouse

The raw 4-second pings are thrown away. Kept: the final order (Cosmos) + a thinned route trail (Lakehouse).

The one idea that makes it all click: TWO LANES

Beginners picture one straight line. It's actually two independent lanes that meet only at Redis.

WRITE lane (always on, background):   GPS → Event Hubs → Processor → Redis
READ lane  (only when you refresh):   You → Redis → 🛵

The processor is always filling Redis in the background.
Your refresh only reads Redis.
You never touch Event Hubs or the processor.

Analogy: a chef (processor) keeps refilling the buffet tray (Redis). You (refresh) grab from the tray. You never wait for the chef.

The 4 confusions everyone hits (and the fix)

"Isn't the cached position outdated?"
It can be — by design. You only cache things where "a few seconds old is fine" (bike position). You never cache the wallet balance. Redis holds a fresh value because the processor overwrites it every few seconds.

"Is Event Hubs just a database?"
No. A database lets you ask "give me bike 4471's location." Event Hubs can't — it only lets you read the stream front-to-back, like a ticker. It's a log that forgets (data expires after 1–7 days). Filing cabinet vs conveyor belt.

"Event Hubs overwrites, so no history?"
Swapped tools. Event Hubs KEEPS history (every ping, in order, for days). Redis is the one that overwrites. History survives in Event Hubs short-term and Lakehouse long-term.

"Won't the database get the same 125k/sec firehose anyway?"
No — the consumer is a filter + funnel, not a pass-through:

Reduce — Redis overwrites; only a sampled trail is kept (drop ~87%)
Batch — 1,000 events → 1 bulk write
Smooth — the buffer absorbs the dinner-time spike so the DB sees a calm, flat rate

By the time data reaches the DB, it's a trickle — sampled, batched, and calm.

Bonus: how does it say "25 mins" before the food is even made?

It's a prediction, not a measurement. An ML model adds three guesses:

ETA = prep time + rider-to-restaurant + restaurant-to-you

Piece	Guessed from
Prep time	This restaurant's history for this dish + kitchen load
Pickup travel	Rider GPS distance + live traffic
Delivery travel	Route distance + live traffic

That's why your ETA sometimes jumps 25 → 35 mid-order: the model re-adjusts as reality changes.

Why not just use one big tool?

Because every tool is great at one thing and bad at the others:

If you forced Event Hubs to also be the database	If you forced Redis to keep history
Can't look up by key	Runs out of memory fast
Data expires and vanishes	Loses "current" clarity

Splitting the jobs is the same trade-off principle behind all system design: pick the right tool for each job, and accept that no single tool wins at everything.

The whole thing in 3 lines

Order → Service Bus → Cosmos (keep forever)
GPS → Event Hubs → Redis (keep "now") → your map
The database never sees the firehose — only the trickle that matters.

Next time you watch that bike crawl toward your door, you'll know: it's not magic. It's a write lane quietly filling a sticky note, and a read lane grabbing it every time you refresh.

System Design Foundations, Explained with Swiggy

Vignesh Athiappan — Mon, 03 Aug 2026 06:38:27 +0000

Every system design decision comes down to trade-offs between a handful of properties. This post walks through the foundational ones — quality attributes, the CAP theorem, PACELC, and the consistency spectrum — using one running example: you open Swiggy on a Friday night and order biryani.

Uber works almost identically (rider + driver instead of eater + delivery partner), so the same lens applies there too.

Part 1 — Quality Attributes

Scenario: Friday 8:30 PM. You order biryani on Swiggy.

Attribute	One-line meaning	Swiggy moment
Scalability	Handle more load	10k users at 3PM → 5M at dinner. Add servers.
Latency	Speed of your one request	Tap search → results in <1 sec
Throughput	Total volume for everyone	2M searches/sec across India
Availability	Is it up?	App must not go down at peak
Reliability	Is the answer correct?	Don't show "delivered" when food's still cooking
Durability	Data survives crashes	Your paid order never gets lost
Consistency	Everyone sees same latest data	"Sold out" shows to all instantly (or not)
Fault tolerance	Keeps working when a part dies	1 of 500 servers crashes → you notice nothing
Maintainability	Easy to change code	Ship features weekly, safely
Observability	Can see inside	Order stuck? Trace exactly where

The ONE big idea

You can't max all of them. They fight. Pick 2–3 that matter, sacrifice the rest.

Proof — same Swiggy, opposite choices:

💳 Payment → wins: consistency, durability, reliability. sacrifices: latency (2-sec wait is fine)
🔍 Search/browse → wins: latency, availability. sacrifices: consistency (stale for 5 sec is fine)

Same company. Opposite rankings. That ranking = the architecture decision.

One quick distinction that trips people up:

Reliability / Consistency / Availability = what the user feels
Observability / Maintainability = what the engineer needs behind the scenes

Don't mix the two camps.

Part 2 — CAP Theorem

Setup: Swiggy runs on many servers in different cities. Sometimes the network between them breaks — a server in Delhi can't talk to a server in Bengaluru. That break is called a partition.

Three things you want:

Letter	Means
C — Consistency	Everyone sees the same latest data
A — Availability	Every request gets an answer
P — Partition tolerance	System survives the network break

The rule: During a partition, you can only keep 2 of 3. And since network breaks will happen, P is not optional. So the real choice is just: C or A?

The choice, on Swiggy

Delhi and Bengaluru servers can't talk. You place an order. What does Swiggy do?

Pick C (refuse): "Sorry, try again later." → Correct, but you got blocked. This is a CP system.
Pick A (accept): "Order placed!" → but Delhi doesn't know yet, data is briefly out of sync. This is an AP system.

You can't have both during the break. Correctness OR uptime.

Which does Swiggy pick? Depends on the feature

💳 Payment → CP. Better to block than double-charge. Refuse and stay correct.
🔍 Browse restaurants → AP. Better to show slightly stale list than an error page. Stay up.

The classic trap: "CA system"

A CA system means "no partition tolerance" — that only works on a single machine. Any real distributed system will face network breaks, so P is forced on you. You're always really choosing C or A. "CA distributed" is a contradiction.

The clean way to hold it: P is forced, C-or-A is the actual choice.

Part 3 — PACELC

The gap in CAP: CAP only tells you what happens during a network break. But breaks are rare. What about normal times, when everything's healthy? CAP says nothing. PACELC fixes that.

Read it like a sentence:

Partition? → choose A or C
Else (normal times)? → choose L or C

(L = Latency)

Situation	The choice
P — network broken	Availability or Consistency (this is just CAP)
E — normal, healthy	Latency or Consistency (this is the NEW part)

Why is there even a choice when the network is fine?

Because to be strongly consistent, servers must coordinate — "wait, let me check with Delhi and Mumbai before I answer." That checking takes time = latency.

So even with a perfect network:

Want everyone to see the exact same data? → coordinate → slower (pay latency)
OK with slightly stale? → skip coordination → faster

This trade-off is happening all the time, not just during failures. That's PACELC's whole point.

On Swiggy

💳 Payment → PC / EC → consistent always, even if it's a bit slow. Both cases pick C.
🔍 Browse → PA / EL → during break: stay available. Normal times: stay fast. Both cases avoid the cost of C.

Read it as two letters: PA/EL = "in Partition pick A, Else pick L." Speed and uptime over correctness.

Part 4 — The Consistency Spectrum (the dial)

"Consistent vs eventual" isn't a switch — it's a dial. Here it is, strongest (slowest) → weakest (fastest):

Level	Plain meaning	Swiggy example
Strong	Every read = newest write, always	Wallet balance — never wrong
Bounded staleness	Can lag, but only by X seconds max	Order status, max 5 sec behind
Session	You always see your own writes in order	Your cart — you added it, you see it
Consistent prefix	Never see things out of order, just maybe old	Order timeline: placed→cooking→out, never scrambled
Eventual	Catches up eventually, no promise on order	"Trending near you" list

Top = safest + slowest. Bottom = fastest + loosest. You turn the dial per feature.

Azure tie-in

Cosmos DB literally exposes these as 5 settable levels — Strong, Bounded Staleness, Session, Consistent Prefix, Eventual. Session is the default. This isn't theory — it's a dropdown you configure. Wallet → Strong. User cart → Session. Trending list → Eventual.

Wrapping up

The whole of foundations comes down to one habit: name the 2–3 attributes that matter for the feature in front of you, then choose what to sacrifice — during failures (CAP), during normal operation (PACELC), and at the exact level of consistency you actually need (the spectrum). Same system, different features, opposite choices. That ranking act is the architecture.

Chain of Responsibility: The Support Escalation Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 06:44:21 +0000

You call customer support with a problem. Level 1 tries to help. If they can't solve it, they escalate to Level 2. If Level 2 is stuck, it goes to Level 3. The request travels down a line until someone handles it — and you, the caller, never needed to know which level would end up solving it.

That's the Chain of Responsibility pattern: pass a request along a chain of handlers until one of them handles it.

The problem it solves

Imagine approving an expense, where the approver depends on the amount:

public void Approve(decimal amount)
{
    if (amount <= 1000) Console.WriteLine("Team lead approves");
    else if (amount <= 10000) Console.WriteLine("Manager approves");
    else if (amount <= 100000) Console.WriteLine("Director approves");
    else Console.WriteLine("CFO approves");
}

It works, but every new approval level means editing this one method, and the sender is hard-wired to know the entire hierarchy. Chain of Responsibility turns each level into its own handler and links them together.

The Chain way

Each handler knows one thing to do and who to pass to if it can't:

public abstract class Approver
{
    protected Approver? _next;

    public Approver SetNext(Approver next)
    {
        _next = next;
        return next;    // return next so we can chain the setup fluently
    }

    public abstract void Handle(decimal amount);
}

Each concrete handler either handles the request or forwards it:

public class TeamLead : Approver
{
    public override void Handle(decimal amount)
    {
        if (amount <= 1000) Console.WriteLine("Team lead approves");
        else _next?.Handle(amount);         // can't handle — pass it on
    }
}

public class Manager : Approver
{
    public override void Handle(decimal amount)
    {
        if (amount <= 10000) Console.WriteLine("Manager approves");
        else _next?.Handle(amount);
    }
}

public class Director : Approver
{
    public override void Handle(decimal amount)
    {
        if (amount <= 100000) Console.WriteLine("Director approves");
        else _next?.Handle(amount);
    }
}

Link the chain, then send requests to the front of it:

var teamLead = new TeamLead();
var manager = new Manager();
var director = new Director();

teamLead.SetNext(manager).SetNext(director);   // build the chain

teamLead.Handle(500);      // Team lead approves
teamLead.Handle(5000);     // Manager approves
teamLead.Handle(50000);    // Director approves

The caller always talks to the front of the chain and never worries about who ultimately handles the request. Add a CFO level? Write one handler and link it on the end — nothing else changes.

The key idea

Each handler makes one small decision: can I deal with this? If yes, handle it and stop. If no, pass it to the next one. No single place holds the whole branching logic — it's distributed across small, independent handlers you can reorder, insert, or remove freely.

You can even design chains where every handler runs (each doing its bit and always passing along), rather than stopping at the first match — useful for pipelines where several steps should all get a turn.

Where you've seen it

ASP.NET Core middleware — the single clearest example. Each middleware inspects the request, does its bit (auth, logging, compression), and calls next() to pass control down the pipeline.
Logging frameworks — a message passes through handlers filtered by level (Debug, Info, Warning, Error).
Event bubbling in UIs — a click travels up through parent elements until something handles it.
Validation pipelines — each rule checks the input and passes it on.

Chain of Responsibility vs Decorator

Both build a chain of wrapped objects, so they look related. The difference is intent. A Decorator always calls the next one and its whole point is to add behavior around the result. A Chain of Responsibility handler may stop the chain — the point is to find the one handler that should deal with the request. Decorator enhances every layer; Chain looks for a place to stop.

One line to remember

Chain of Responsibility = support escalation. A request travels down a line of handlers until one deals with it — and the sender never needs to know which one.

Part 15 — the finale — of a series on must-know design patterns in C#, explained the simple way. Across the series we covered all fifteen: Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Proxy, Composite, Observer, Strategy, Command, Iterator, State, Template Method, and Chain of Responsibility. If you followed along from part one, you now have a working mental model for every pattern on the list — each tied to something from everyday life. Thanks for reading.

Template Method: The Recipe-With-Blanks Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 06:43:39 +0000

Think about how a recipe works. Making tea and making coffee follow the same skeleton:

Boil water
Add the main ingredient (tea leaves / coffee powder)
Add extras (milk, sugar)
Pour into cup

The steps and their order never change. Only one or two steps differ between tea and coffee. You don't rewrite the whole procedure for each drink — you keep the skeleton and swap the parts that vary.

That's the Template Method pattern: a parent class defines the fixed skeleton of an algorithm, and subclasses fill in specific steps without changing the overall order.

The problem it solves

Say you process two report types — PDF and Excel. Both follow the same flow: fetch data, format it, export, then email it. Without Template Method, you copy-paste that flow twice and each copy drifts out of sync over time:

public void GeneratePdfReport()
{
    var data = FetchData();      // same
    // ...format as PDF...       // different
    // ...export...              // different
    SendEmail();                 // same
}

public void GenerateExcelReport()
{
    var data = FetchData();      // same — duplicated
    // ...format as Excel...     // different
    // ...export...              // different
    SendEmail();                 // same — duplicated
}

The shared steps are duplicated, and if the flow changes, you have to fix it in every copy.

The Template Method way

The parent class owns the skeleton in one place. The steps that vary become abstract methods for subclasses to implement:

public abstract class ReportGenerator
{
    // The template method — defines the fixed skeleton. Note: it's NOT overridable.
    public void Generate()
    {
        var data = FetchData();     // shared step
        Format(data);               // varies — subclass decides
        Export();                   // varies — subclass decides
        SendEmail();                // shared step
    }

    private string FetchData() { Console.WriteLine("Fetching data"); return "data"; }
    private void SendEmail()   => Console.WriteLine("Emailing report");

    // The blanks — subclasses must fill these in
    protected abstract void Format(string data);
    protected abstract void Export();
}

Each subclass fills only the blanks:

public class PdfReport : ReportGenerator
{
    protected override void Format(string data) => Console.WriteLine("Formatting as PDF");
    protected override void Export()            => Console.WriteLine("Exporting PDF");
}

public class ExcelReport : ReportGenerator
{
    protected override void Format(string data) => Console.WriteLine("Formatting as Excel");
    protected override void Export()            => Console.WriteLine("Exporting Excel");
}

Run it:

ReportGenerator report = new PdfReport();
report.Generate();
// Fetching data
// Formatting as PDF
// Exporting PDF
// Emailing report

The Generate() flow lives in exactly one place. Subclasses can't reorder or skip steps — they only fill the blanks. Add a CSV report? Write one subclass with two methods; the skeleton is untouched.

The key idea: "don't call us, we'll call you"

Notice the control flow. You don't call Format() and Export() yourself — the parent's Generate() calls them for you, at the right moment. The subclass just provides the pieces; the parent drives the sequence. This inversion is sometimes called the Hollywood Principle: "don't call us, we'll call you."

Template Method vs Strategy

They solve a similar problem — varying part of a behavior — but differently:

Template Method uses inheritance. The skeleton is fixed in a base class; subclasses override steps. The variation is chosen at compile time by which subclass you instantiate.
Strategy uses composition. You inject a whole algorithm object and can swap it at runtime.

Rule of thumb: fixed skeleton with a few pluggable steps → Template Method. Whole interchangeable algorithm, swappable on the fly → Strategy.

Where you've seen it

ASP.NET Core middleware and framework base classes — you override specific methods (OnActionExecuting, ConfigureServices) while the framework runs the overall pipeline.
Unit test lifecycles — Setup(), the test body, Teardown() run in a fixed order; you fill in the parts.
Data import pipelines — validate, transform, save always run in that order; each importer customizes transform.

One line to remember

Template Method = a recipe with blanks. The parent locks the steps and their order; subclasses fill in only the parts that differ.

Part 14 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton through State. Next up: Chain of Responsibility — passing a request down a line of handlers.

State: The Traffic Light Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 06:41:04 +0000

A traffic light is always in exactly one state, and its behavior depends entirely on which one:

Red — cars stop. After a timer, it becomes Green.
Green — cars go. After a timer, it becomes Yellow.
Yellow — cars slow. After a timer, it becomes Red.

Same object, but what it does — and what it becomes next — changes completely based on its current state. And crucially, the light switches itself. Red decides when to become Green. Nobody from outside picks the next state.

That's the State pattern: an object changes its own behavior when its internal state changes — as if it became a different class.

The problem it solves

Without it, you get a mess of flags and ifs scattered across every method:

public void Play()
{
    if (_state == "playing") Console.WriteLine("Already playing");
    else if (_state == "paused")  { _state = "playing"; Console.WriteLine("Resumed"); }
    else if (_state == "stopped") { _state = "playing"; Console.WriteLine("Starting"); }
}

public void Pause()
{
    if (_state == "playing") { ... }
    else if (_state == "paused") { ... }
    // the same tangle repeated in every method
}

Every method re-checks the state. Add a new state and you edit every method. This is the classic "state machine as spaghetti."

The State way

Each state becomes its own class that knows two things: how to behave, and which state to move to next.

The state interface:

public interface IPlayerState
{
    void Play(MediaPlayer player);
    void Pause(MediaPlayer player);
}

The context holds the current state and delegates to it:

public class MediaPlayer
{
    public IPlayerState State { get; set; }
    public MediaPlayer() => State = new StoppedState();   // start here

    public void Play()  => State.Play(this);    // delegate to current state
    public void Pause() => State.Pause(this);
}

Each state is a class — and it decides the next state:

public class StoppedState : IPlayerState
{
    public void Play(MediaPlayer player)
    {
        Console.WriteLine("Starting playback");
        player.State = new PlayingState();   // the state switches itself
    }
    public void Pause(MediaPlayer player) => Console.WriteLine("Can't pause — already stopped");
}

public class PlayingState : IPlayerState
{
    public void Play(MediaPlayer player) => Console.WriteLine("Already playing");
    public void Pause(MediaPlayer player)
    {
        Console.WriteLine("Pausing");
        player.State = new PausedState();
    }
}

public class PausedState : IPlayerState
{
    public void Play(MediaPlayer player)
    {
        Console.WriteLine("Resuming");
        player.State = new PlayingState();
    }
    public void Pause(MediaPlayer player) => Console.WriteLine("Already paused");
}

Watch it flow:

var player = new MediaPlayer();   // Stopped
player.Play();    // "Starting playback"  → Playing
player.Pause();   // "Pausing"            → Paused
player.Play();    // "Resuming"           → Playing
player.Play();    // "Already playing"

No if (_state == ...) anywhere. Each state class handles its own behavior and points to the next. Adding a new state — say a buffering state — means writing one new class; no existing method gets touched.

Strategy vs State — the confusion, settled

The code looks almost identical. Both plug in an object and delegate to it. The difference is who decides, and whether it changes itself:

Who picks the plugged-in object? Strategy: you, from outside. State: the object switches itself.
Does it change during use? Strategy: no — pick once, it runs. State: yes — it flips as things happen.
Do the objects know each other? Strategy: no, they're independent algorithms. State: yes, each state knows the next.
Analogy. Strategy is Google Maps — you pick car vs walking. State is a traffic light — red becomes green on its own.

The tell: in Strategy, the context never reassigns its own strategy — you do, from outside. In State, PlayingState sets player.State = new PausedState() — the states rewrite the context from inside. Self-transitioning means State. Externally-chosen means Strategy.

Where you've seen it

Order lifecycle — Pending, Paid, Shipped, Delivered, each stage allowing different actions.
Workflow and approval engines — Draft, Submitted, Approved, Published.
Game character states — Idle, Running, Jumping, Attacking.
Connection states — Disconnected, Connecting, Connected, Reconnecting.
UI wizards — each step enables or disables different buttons.

One line to remember

State = traffic light. The object holds one state at a time, behaves according to it, and switches itself to the next — no giant if-else tangle.

Part 13 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton through Iterator. Next up: Template Method — defining a skeleton and letting subclasses fill in the steps.

Iterator: The "Next" Button Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 05:41:00 +0000

Iterator: The "Next" Button Pattern

You flip through TV channels with a remote. Press "next" — channel 1. Next — channel 2. Next — channel 3.

You don't know or care how the TV stores channels internally. Array? Linked list? Database? Doesn't matter. You press next and get the next one. The remote gives you one simple way to walk through everything, one at a time, without exposing the internals.

That's the Iterator pattern: walk through a collection one item at a time, without knowing how it's stored inside.

The problem it solves

Different collections store data completely differently. An array uses an index, a linked list uses node pointers, a tree walks branches. Without Iterator, your loop has to know each collection's internal structure:

// array — must know it's index-based
for (int i = 0; i < array.Length; i++) { ... }

// linked list — completely different traversal
var node = list.Head;
while (node != null) { ...; node = node.Next; }

Every collection type forces a different loop. Change the storage and you rewrite every loop. Iterator hides all that behind one uniform "give me the next item."

The C# reality: you already have this

In C#, Iterator is the foreach loop, and it works on arrays, lists, dictionaries, sets — anything:

foreach (var item in anyCollection)
    Console.WriteLine(item);

That one line works everywhere because every collection provides an iterator under the hood. You never see the difference between an array and a linked list — foreach just asks each one for the next item until it's done. You've used this pattern thousands of times without naming it.

Making your own class iterable

Here's the useful part. Say you build a custom Playlist class and want foreach to work on it. The keyword yield return makes that effortless:

public class Playlist
{
    private readonly List<string> _songs = new();
    public void Add(string song) => _songs.Add(song);

    public IEnumerator<string> GetEnumerator()
    {
        foreach (var song in _songs)
            yield return song;      // hand out one at a time
    }
}

Now your own class walks like any built-in collection:

var playlist = new Playlist();
playlist.Add("Song A");
playlist.Add("Song B");

foreach (var song in playlist)     // works — because we gave it an iterator
    Console.WriteLine(song);

`yield return`: the magic word

yield return is genuinely powerful. It pauses the method, hands back one item, and remembers where it left off for the next request. That makes it lazy — items are produced only when asked for, not all at once.

Which unlocks something wild: infinite sequences.

public IEnumerable<int> Naturals()
{
    int n = 1;
    while (true)           // infinite loop, but safe
        yield return n++;  // produces one number only when asked
}

foreach (var num in Naturals().Take(5))
    Console.WriteLine(num);   // 1 2 3 4 5 — the rest never get computed

An infinite loop that doesn't hang, because yield only computes the next value when you actually ask for it. Try that with a normal List and it runs out of memory instantly. This laziness is also why LINQ can chain .Where().Select().Take() efficiently — it's all iterators, computed on demand.

The two interfaces

IEnumerable means "I can be iterated" — the collection.
IEnumerator means "I do the actual walking" — the cursor, with MoveNext() and Current.

foreach calls GetEnumerator() to get a cursor, then calls MoveNext() until it's done. You almost never write these by hand — yield return generates them for you.

Where it's everywhere

Every foreach loop you've ever written.
All of LINQ — .Where(), .Select(), .Take() return lazy iterators.
Streaming large files or database results row by row via yield, instead of loading everything into memory.
Paginated APIs that yield results page by page.

One line to remember

Iterator = the "next" button. Walk a collection one item at a time without caring how it's stored — and in C#, foreach + yield return give it to you for free.

Part 12 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Proxy, Composite, Observer, Strategy, and Command. Next up: State — when an object changes its behavior as its state changes.

Command: The TV Remote Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 05:36:14 +0000

Look at a TV remote. Each button is a wrapped-up request. Power means "turn the TV on." Volume+ means "increase volume." Channel means "change channel."

The remote has no idea how the TV actually turns on internally. The button just holds the instruction. Press it, and the instruction runs on the TV.

Here's the magic: because each action is now an object — a button — you can do things you couldn't before. Record a sequence of presses, replay them, or undo the last one.

That's the Command pattern: wrap a request as an object, so you can pass it around, queue it, log it, or undo it.

The problem it solves

Normally you call a method directly:

light.TurnOn();   // happens immediately, then vanishes

The action is a fleeting event. You can't store it, queue it, undo it, or ask "what did the user just do?" Once it runs, it's gone. Command turns that verb into a noun — an object you can hold.

The three players

Receiver — the thing that does the actual work (the TV, the light).
Command — an object wrapping "call this method on the receiver."
Invoker — triggers commands but knows nothing about what they do (the remote).

The code

Every command can execute, and optionally undo:

public interface ICommand
{
    void Execute();
    void Undo();
}

The receiver does the real work:

public class Light
{
    public void On()  => Console.WriteLine("Light ON");
    public void Off() => Console.WriteLine("Light OFF");
}

Each concrete command wraps one action on the receiver — and knows its own reverse:

public class TurnOnCommand : ICommand
{
    private readonly Light _light;
    public TurnOnCommand(Light light) => _light = light;

    public void Execute() => _light.On();
    public void Undo()    => _light.Off();   // the reverse action
}

public class TurnOffCommand : ICommand
{
    private readonly Light _light;
    public TurnOffCommand(Light light) => _light = light;

    public void Execute() => _light.Off();
    public void Undo()    => _light.On();
}

The invoker presses buttons and keeps a history — but knows nothing about lights:

public class RemoteControl
{
    private readonly Stack<ICommand> _history = new();

    public void PressButton(ICommand command)
    {
        command.Execute();
        _history.Push(command);      // remember it, so we can undo
    }

    public void PressUndo()
    {
        if (_history.Count > 0)
            _history.Pop().Undo();   // undo the last thing
    }
}

Use it:

var light = new Light();
var remote = new RemoteControl();

remote.PressButton(new TurnOnCommand(light));   // Light ON
remote.PressButton(new TurnOffCommand(light));  // Light OFF
remote.PressUndo();                             // Light ON  — undo!

The remote replayed and undid actions — because each action was an object it could store on a stack. You cannot do this with plain light.On() method calls. That's the entire point.

What "action as object" unlocks

Once a request is an object, you get superpowers for free:

Undo / Redo — keep a history stack and call .Undo(). Every text editor works this way.
Queuing — put commands in a queue and run them later. This is how background job systems work.
Scheduling — "run this command at 2 AM."
Logging and audit — store executed commands to replay or review.
Macros — bundle several commands into one.

None of these are possible when the action is just a method call that runs and disappears.

Where you've seen it

Undo/redo in any editor — Word, Photoshop, VS Code — is a command history stack.
Background job queues (Hangfire, message queues) — each job is essentially a command.
ICommand in WPF/MVVM — button bindings are literally this pattern by name.
The CQRS command side and MediatR's IRequest — command objects sent to handlers.

Command vs Strategy

Both wrap behavior in an object, but the intent differs:

Strategy is about how to do one thing, swappable — which shipping algorithm to run. It usually runs immediately, no history.
Command is about what to do, captured as an object so it can be queued, undone, or logged. The action itself becomes storable data.

Strategy chooses a method. Command captures a request.

One line to remember

Command = TV remote button. Wrap an action as an object so you can store it, queue it, replay it, or undo it — things a plain method call can never do.

Part 11 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Proxy, Composite, Observer, and Strategy. Next up: Iterator — walking a collection without exposing its internals.

Strategy: The Google Maps Travel-Mode Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 05:24:03 +0000

Strategy: The Google Maps Travel-Mode Pattern

You open Google Maps to go somewhere, and it asks: how do you want to travel? By car, walking, public transport, or cycling.

Same goal — get from A to B — but each option runs a completely different algorithm to work out the route. You pick one, and Maps swaps in that method. Tomorrow you pick another; same app, different strategy, chosen at runtime.

That's the Strategy pattern: a family of interchangeable algorithms, picked and swapped at runtime.

The problem it solves

Say you calculate shipping cost, and it depends on the method:

public decimal CalculateShipping(string method, decimal weight)
{
    if (method == "standard")  return weight * 5;
    else if (method == "express")   return weight * 10 + 20;
    else if (method == "overnight") return weight * 15 + 50;
    // add "drone"? edit this method again...
}

Every new method means editing this one function. It becomes a dumping ground of ifs — hard to test each branch alone, and it keeps forcing you to modify code that already works.

The Strategy way

Define the shape all algorithms share:

public interface IShippingStrategy
{
    decimal Calculate(decimal weight);
}

Each algorithm becomes its own small class:

public class StandardShipping : IShippingStrategy
{
    public decimal Calculate(decimal weight) => weight * 5;
}

public class ExpressShipping : IShippingStrategy
{
    public decimal Calculate(decimal weight) => weight * 10 + 20;
}

public class OvernightShipping : IShippingStrategy
{
    public decimal Calculate(decimal weight) => weight * 15 + 50;
}

The context holds a strategy and delegates to it, without knowing which one:

public class ShippingCalculator
{
    private IShippingStrategy _strategy;
    public ShippingCalculator(IShippingStrategy strategy) => _strategy = strategy;

    public void SetStrategy(IShippingStrategy strategy) => _strategy = strategy;
    public decimal Calculate(decimal weight) => _strategy.Calculate(weight);
}

Swap strategies at runtime:

var calc = new ShippingCalculator(new StandardShipping());
Console.WriteLine(calc.Calculate(10));   // 50

calc.SetStrategy(new ExpressShipping());  // swapped the algorithm, same object
Console.WriteLine(calc.Calculate(10));   // 120

Add drone delivery? Write one DroneShipping class. The calculator never changes. You add a new class instead of modifying working code.

The idea behind it

Strategy replaces a big conditional — an if/else or switch picking behavior — with a set of small classes plus composition. Instead of the code deciding what to do inside one method, you hand it the behavior you want.

Don't bury the "how" inside an if-else. Inject the way to do it.

The C# shortcut

For simple strategies you don't even need classes — just pass a function:

public class ShippingCalculator
{
    private Func<decimal, decimal> _strategy;
    public ShippingCalculator(Func<decimal, decimal> strategy) => _strategy = strategy;
    public decimal Calculate(decimal weight) => _strategy(weight);
}

var standard = new ShippingCalculator(w => w * 5);
var express  = new ShippingCalculator(w => w * 10 + 20);

A Func<> or lambda is a strategy. Every time you pass a comparison to list.Sort(...) or a predicate to .Where(...), you're using Strategy. LINQ is soaked in it.

Strategy vs Factory

These get confused, but the jobs are different:

Factory decides which object to create — its job is creation.
Strategy decides which algorithm to run — its job is behavior.

They often team up: a factory creates the right strategy, then the context runs it.

Where you've seen it

LINQ — .Where(predicate), .OrderBy(selector); predicates and selectors are strategies.
List.Sort(IComparer) — the comparer is a pluggable sorting strategy.
Payment processing — pick Card, UPI, or Wallet strategy at checkout.
Compression, encryption, pricing rules, discount engines — anywhere "same task, multiple methods."

One line to remember

Strategy = Google Maps travel mode. Same goal, a family of swappable algorithms, pick one at runtime — adding a new one never touches existing code.

Part 10 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Proxy, Composite, and Observer. Next up: Command — wrapping a request as an object.

Observer: The YouTube Subscribe Pattern

Vignesh Athiappan — Sun, 02 Aug 2026 05:20:34 +0000

You subscribe to a YouTube channel and hit the bell. Now, whenever the creator uploads, you get notified automatically. You don't sit there refreshing every five minutes asking "new video yet?" The channel pushes the news to everyone subscribed.

The channel is the thing being watched — the Subject.
You and the other subscribers are the Observers.
A new upload is the event that triggers notifications to everyone.

And subscribers come and go freely. You can unsubscribe anytime, and the channel doesn't care who's on the list — it just notifies whoever currently is.

That's the Observer pattern: when one object changes, all its dependents get notified automatically.

The problem it solves

An order gets placed, and several things must happen: send an email, update inventory, log analytics, notify the warehouse. The naive way glues them all onto the order class:

public void PlaceOrder()
{
    // ...place order...
    _emailService.Send(...);
    _inventoryService.Update(...);
    _analyticsService.Track(...);
    _warehouseService.Notify(...);
}

Every time you add a new reaction — "also send an SMS" — you edit the order class. It knows about everyone and is tightly coupled to all of them. Observer breaks exactly this.

The Observer way

First, an interface describing what a subscriber looks like:

public interface IOrderObserver
{
    void OnOrderPlaced(int orderId);
}

The subject keeps a list of subscribers and notifies them — without knowing who they are:

public class OrderService
{
    private readonly List<IOrderObserver> _observers = new();

    public void Subscribe(IOrderObserver o)   => _observers.Add(o);
    public void Unsubscribe(IOrderObserver o) => _observers.Remove(o);

    public void PlaceOrder(int orderId)
    {
        // ...place the order...
        foreach (var observer in _observers)   // notify everyone on the list
            observer.OnOrderPlaced(orderId);   // no idea who they actually are
    }
}

Each observer reacts in its own way:

public class EmailNotifier : IOrderObserver
{
    public void OnOrderPlaced(int id) => Console.WriteLine($"Email sent for #{id}");
}

public class InventoryUpdater : IOrderObserver
{
    public void OnOrderPlaced(int id) => Console.WriteLine($"Inventory updated for #{id}");
}

Wire it up:

var orderService = new OrderService();
orderService.Subscribe(new EmailNotifier());
orderService.Subscribe(new InventoryUpdater());

orderService.PlaceOrder(101);
// Email sent for #101
// Inventory updated for #101

Add SMS later? Write SmsNotifier, call Subscribe(new SmsNotifier()). OrderService never changes — it has no idea SMS exists, it just loops over whoever subscribed. The subject and its reactions are fully decoupled. That's the payoff.

The C# native way

C# has Observer baked into the language via events, so you rarely write the observer list by hand:

public class OrderService
{
    public event Action<int>? OrderPlaced;   // the "channel"

    public void PlaceOrder(int orderId)
    {
        // ...place order...
        OrderPlaced?.Invoke(orderId);        // notify all subscribers
    }
}

var service = new OrderService();
service.OrderPlaced += id => Console.WriteLine($"Email sent for #{id}");
service.OrderPlaced += id => Console.WriteLine($"Inventory updated for #{id}");

service.PlaceOrder(101);   // both fire automatically

Every += on an event, every button Click handler, every PropertyChanged in MVVM — that's Observer. You've been using it since day one.

Where it's everywhere

UI events — button.Click += ..., every DOM addEventListener.
MVVM and data binding — INotifyPropertyChanged is Observer; the UI observes your model.
Event buses and domain events — publish once, many handlers react.
SignalR, webhooks, pub/sub — the same idea at network scale.
IObservable<T> and Reactive Extensions — Observer turned into full data streams.

One line to remember

Observer = YouTube subscribe. When the subject changes, everyone on the list gets notified automatically — and the subject doesn't know or care who's listening.

Part 9 of a series on must-know design patterns in C#, explained the simple way. Earlier parts covered Singleton, Factory Method, Builder, Adapter, Decorator, Facade, Proxy, and Composite. Next up: Strategy — the choose-your-algorithm pattern.

DEV Community: Vignesh Athiappan

We Cut a 190 GB Production Database to 45 GB in One Night. Here's What We Learned

We Cut a 190 GB Production Database to 45 GB in One Night. Here's What We Learned.

Lesson 1: Your database is probably smaller than you think

Lesson 2: Size doesn't correlate with row count

Lesson 3: The transaction log will kill you before the data file does

Lesson 4: Gates and abort flags, not rollbacks

Lesson 5: Prove what you didn't delete

Lesson 6: Deleting rows doesn't shrink the file

The result

What I'd do differently

Designing a humane involuntary exit workflow: what I learned building one

The trigger: let the system start it, never finish it

Approvals: parallel where possible, sequential where it matters

The last mile: the employee hears it from a person, not a system

Cancellation is a feature, not an edge case

Everything is configuration, everything is audited

The takeaway

Azure Managed Redis: A Field-by-Field Walkthrough of the Create Blade

The Advanced tab (where all the interesting decisions live)

Modules

Non-TLS access only

Eviction Policy

High availability

Clustering Policy

Data Persistence — read this part carefully

Customer-managed key encryption at rest

Defer automatic major Redis version updates (preview)

Access Keys Authentication — the one that will break your apps

Quick reference: what's a one-way door?

After it's created: the things I wish I'd known on day one

The short version

The Moving Bike on Your Food App: How Live Order Tracking Actually Works (in Azure)

The cast: 4 tools, 4 jobs

The journey, step by step

The one idea that makes it all click: TWO LANES

The 4 confusions everyone hits (and the fix)

Bonus: how does it say "25 mins" before the food is even made?

Why not just use one big tool?

The whole thing in 3 lines

System Design Foundations, Explained with Swiggy

Part 1 — Quality Attributes

The ONE big idea

Part 2 — CAP Theorem

The choice, on Swiggy

Which does Swiggy pick? Depends on the feature

The classic trap: "CA system"

Part 3 — PACELC

Why is there even a choice when the network is fine?

On Swiggy

Part 4 — The Consistency Spectrum (the dial)

Azure tie-in

Wrapping up

Chain of Responsibility: The Support Escalation Pattern

The problem it solves

The Chain way

The key idea

Where you've seen it

Chain of Responsibility vs Decorator

One line to remember

Template Method: The Recipe-With-Blanks Pattern

The problem it solves

The Template Method way

The key idea: "don't call us, we'll call you"

Template Method vs Strategy

Where you've seen it

One line to remember

State: The Traffic Light Pattern

The problem it solves

The State way

Strategy vs State — the confusion, settled

Where you've seen it

One line to remember

Iterator: The "Next" Button Pattern

Iterator: The "Next" Button Pattern

The problem it solves

The C# reality: you already have this

Making your own class iterable

yield return: the magic word

The two interfaces

`yield return`: the magic word