Forem: Mohammad Shoeb

The C# Feature That Saves You Thousands… But No One Talks About

Mohammad Shoeb — Wed, 27 Aug 2025 10:57:05 +0000

Why This Blog Matters

Most cloud overruns don’t come from AI models or Kubernetes complexity.

They come from small inefficiencies in your .NET code — the kind of hidden multipliers that chew up CPU, memory, and dollars every day.

Microsoft has quietly shipped features that don’t get keynote spotlight but can decide whether your App Service scales down or your CFO calls about a $30K overage.

This post highlights one such overlooked gem: Frozen Collections in .NET 8.

The Hidden Hero: Frozen Collections

Dictionaries and hash sets are staples of .NET. But at scale, they carry a hidden tax:

GC churn from repeated allocations
CPU wasted re-hashing keys on every lookup
App Service scaling triggered by inefficient memory pressure

Frozen Collections (Microsoft Docs) flip the model:

Immutable → once built, they never change (thread-safe by default)
Pre-hashed → expensive work is done once at build time
Throughput wins → Microsoft benchmarks show FrozenDictionary achieves ~1.9 ns/lookup vs ~2.5 ns for Dictionary<TKey,TValue> (~25% faster steady-state)
Memory efficiency → lower footprint, fewer GC pauses

👉 Think of it like password hashing. Dictionary re-hashes every login. FrozenDictionary hashes once and reuses forever.

Real-World Case: Cosmos DB Partition Routing

Workload Context:

~12K requests/sec
~10K partition keys (static)
Routing service hosted on Azure App Service P1v3 (2 cores)
Partition map rebuilt once at startup

Observed Behavior (Before):

With Dictionary<string,string>:

CPU averaged 85%
p99 latency ~180 ms
Service scaled from 4 → 6 instances
Cost impact: +2 × P1v3 = $560/month = $6,720/year

After Swap (FrozenDictionary):

private static readonly FrozenDictionary<string,string> PartitionMap =
routingList.ToFrozenDictionary(x => x.Key, x => x.Value);

Results:

💡 In this single service: $6,720/year saved.
💡 Across five routing-heavy services with similar lookup patterns: ~$33K/year saved.

Profiling Evidence (dotnet-counters)

Test setup: 30-minute steady load at 12K RPS using k6, 10K partition keys.

% Time in GC: 12.3% → 5.8%
Alloc Rate: 350 MB/s → 120 MB/s
CPU Usage: 85% → 67%

👉 Lower % Time in GC + lower allocation rate = fewer pauses and more CPU available for real work.

Microsoft Benchmark Data (Build vs Lookup Trade-Off)

Source: .NET 8 performance benchmarks

Startup: ~4× slower — but only paid once.
Lookups: faster and cheaper forever.

For static sets ≥10K, Frozen wins.

For small or frequently mutating sets, stick with Dictionary.

Visuals (Conceptual)

App Service Scaling (Before vs After)

Dictionary: 6 Instances at peak load
FrozenDictionary: 4 Instances at peak load

GC Time Reduction

From 12.3% → 5.8%

When to Use (and When Not To)

✅ Best suited for

Configurations that don’t change after startup
Routing tables (e.g., Cosmos DB partition maps)
Feature flags / metadata lookups
Multi-threaded services (immutability removes locking overhead)

❌ Avoid if

Collections need frequent updates
Dataset is tiny (startup overhead > benefit)
Startup latency is critical (cold path scenarios)

The Bigger Lesson

As engineers, we often jump to flashy fixes: caching layers, Redis tuning, Kubernetes autoscaling.

But sometimes, the highest ROI comes from the most boring one-liner in your codebase.

Frozen Collections don’t just clean up code. They cut real dollars off your bill.

⚡ Coming Next in This Series

Frozen Collections are just one of Microsoft’s “quiet million-savers.”

Part 2 — LoggerMessage Source Generator: How precompiled logging cut one team’s App Insights bill by 30%
Part 3 — Cosmos DB Analytical Store TTL: How a retailer saved $3,000/month with one config

Follow to catch the full series.

Takeaway

If you’re running high-throughput .NET apps in 2025, ask yourself:

Am I paying CPU + GC tax for collections that never change?
Do I need to scale out, or can I scale smarter?

Because sometimes the difference between burning money and saving it is just one line:

myList.ToFrozenDictionary(x => x.Id, x => x.Value);

It’s not glamorous — but it’s the kind of decision that compounds into thousands of dollars at scale.

Call to Action

At Microsoft, we obsess over deleting the right line of code.

This one deletion (of a Dictionary) saved us $6,720/year in one service — and ~$33K/year across the fleet.

👉 What’s the most expensive line of code you’ve ever deleted?

Drop it in the comments — I’ll feature the top 3 in Part 2 of this series.

In enterprise systems, efficiency isn’t optional — it compounds into millions at scale.

Frozen Collections are one of those tools you overlook until you see the bill. Don’t wait for that moment.

Azure Isn't Expensive — Your Code Is: 10 Proven Patterns That Cut Costs Fast

Mohammad Shoeb — Wed, 27 Aug 2025 10:44:03 +0000

🔥 Why This Blog Matters
❌ A company I worked with once spent $7,400 in a single month…
Just because an Azure Function was triggered around 8 million times — by stale messages in a forgotten queue.
The devs didn’t even know it was still active.

💡 You don’t need cheaper pricing tiers.
You need smarter code.

This post is your developer-first playbook.
I’ll show you 10 real code patterns that:

Slash compute, storage, and telemetry waste
Are used inside Microsoft (Azure SDKs, Copilot infra, and durable workloads)
Can be implemented within a couple of weeks
Not a medium member? you can read this blog here.

👻 Pattern 0: Cost Ghosts — What’s Billing You Silently
“You can’t optimize what you don’t measure.” — Azure Advisor Team

👎 Common Mistake:
Ignoring silent costs from idle VMs, orphaned App Services, or chatty logs.

✅ Fix:
Start with diagnostics:

Azure Cost Analysis → by tag or service
Application Insights → filter high-traffic routes
Azure Workbooks → cost-by-operation
Azure Advisor → underutilized resources
💡 Quick Win: Tag every resource by team + feature. Unused ones will light up.

🧠 Pattern 1: Queue-First, Not Compute-First
👎 Common Mistake:
Triggering Functions or APIs directly per event — even when it could wait.

✅ Fix:
Use Storage Queues, Service Bus, or Event Hubs to buffer and batch.

API → Queue → Azure Function (batch trigger)
“Queues are cheaper than compute. Push work downstream.” — Azure Arch Center

💡 Quick Win: Ingest telemetry → Event Hub → Storage Queue → Batch Function

📉 Potential Savings: 30–60% reduction in over-scaled compute

⏳ Pattern 2: Time-to-Live Everything
👎 Common Mistake:
Cosmos DB, queues, and logs live forever. You keep paying for ghost data.

✅ Fix:
Use TTL aggressively:

Cosmos DB: defaultTimeToLive
Service Bus: TimeToLive
Blobs: lifecycle policies
Durable Functions: auto-purge history
“Use TTL to enforce data lifecycle and reduce cost.” — Cosmos TTL Docs

💡 Quick Win: Set Service Bus TTL = 48 hours. Cosmos = 7 days.

📉 Potential Savings: 10–25% on storage & telemetry

📈 Pattern 3: Cap Concurrency — Don’t Over-AutoScale
👎 Common Mistake:
Relying on autoscaling alone leads to bill spikes under load.

✅ Fix:
Apply hard caps:

Azure Function → maxConcurrentRequests
Web APIs → SemaphoreSlim, ParallelOptions
Polly → BulkheadPolicy
“Concurrency limits prevent downstream exhaustion and surprise bills.” — Functions Scale Docs

💡 Quick Win: Limit queue-triggered Functions to 5 concurrent instances.

📉 Potential Savings: 30–50% compute reduction in spikes

🧾 Pattern 4: Structured Logging + Sampling
👎 Common Mistake:
Logging every HTTP response at Information. Every. Single. Time.

✅ Fix:
Use:

Structured logs:
_logger.LogInformation("Order {Id} processed at {Time}", id, DateTime.UtcNow);
Application Insights sampling
Log filters in host.json
“Use sampling to reduce ingestion, not insight.” — App Insights Docs

💡 Quick Win: Use AdaptiveSamplingTelemetryProcessor. It auto-throttles verbosity.

📉 Potential Savings: 40–70% on App Insights ingestion cost

⏱️ Pattern 5: Use Durable Timers Instead of Waiting
👎 Common Mistake:
Using Task.Delay or polling loops — which bills you per second.

✅ Fix:
Use context.CreateTimer(...) in Durable Functions:

await context.CreateTimer(DateTime.UtcNow.AddMinutes(15), CancellationToken.None);
“Durable timers pause without active billing.” — Durable Functions Docs

💡 Quick Win: Replace Thread.Sleep with CreateTimer in approval workflows.

📉 Potential Savings: 50–90% on wait-heavy Functions

📦 Pattern 6: Blob Tiering Isn’t Optional
👎 Common Mistake:
Leaving all blobs in Hot Tier — even audit logs and backups.

✅ Fix:
Use Lifecycle Management to move:

Hot → Cool → Archive → Delete
“Archive storage is up to 80% cheaper than Hot.” — Azure Storage Pricing

💡 Quick Win: Set lifecycle policy:
30 days → Cool
90 days → Archive
180 days → Delete

📉 Potential Savings: 50–80% on storage cost

🧲 Pattern 7: Trigger Filters Save You Real Money
👎 Common Mistake:
Function triggered by every Event Grid event — even irrelevant ones.

✅ Fix:
Use:

Event Grid filters (eventType, subject)
Service Bus SQL filters
Cosmos DB Change Feed filters
“Filter events at the source to reduce compute.” — Event Grid Filters

💡 Quick Win: Trigger only when eventType == "InvoiceCreated"

📉 Potential Savings: 20–40% reduction in Function invocations

🔁 Pattern 8: Resilient Outbound Calls: Retry + Bulkhead
👎 Common Mistake:
Retrying failed APIs immediately → creates a retry storm.
Or worse — calling external APIs at 1000 RPS when they handle 50.

✅ Fix:
Use:

new BlobClientOptions
{
Retry = {
MaxRetries = 5,
Mode = RetryMode.Exponential,
Delay = TimeSpan.FromSeconds(2)
}
}
And cap concurrency:

await semaphore.WaitAsync();
// API Call
semaphore.Release();
“Smart retries and bulkheads reduce downstream throttling and cost.” — Azure SDK + Cloud Patterns

💡 Quick Win: Use Polly + SemaphoreSlim for any 3rd-party API call.

📉 Potential Savings: Up to 50% reduction in failed/duplicated requests

📊 Pattern 9: Track Cost per Route, Not Just Monthly Spend
👎 Common Mistake:
Reviewing cost by month or service — not by API route or feature.

✅ Fix:
Use App Insights operation_Name
Correlate with Azure Cost Exports
Build Workbooks to analyze cost per endpoint
“Tags + correlation = true FinOps insight.” — Azure FinOps Docs

💡 Quick Win: Tag by project, owner, feature. Then sort cost by those.

📉 Potential Savings: Visibility = control = smarter decisions

🎁 Bonus Pattern 10: Stop Paying for Premium SKUs You Don’t Need
👎 Common Mistake:
Using P1 Redis, Standard App Service, or AKS with 3-node pools for tiny workloads.

✅ Fix:
Audit your SKU usage:

Redis: Use Basic unless you’re clustering
App Service: Move idle apps to Free or Consumption
AKS: Scale to 0 or move to Azure Container Apps
“Premium doesn’t mean better. Just pricier.” — Azure Advisor

💡 Quick Win: Downgrade unused Redis cache from P1 to Basic.

📉 Potential Savings: $500–$1500/month depending on SKUs

✅ Start Here: Apply These 3 Today
Add TTL to Cosmos + Service Bus
Cap Function concurrency to 5
Enable sampling in App Insights
🔍 Watch your Azure bill dip within 48 hours.

🧠 Final Thought
Smart code isn’t just faster — it’s cheaper. And it starts today.

💬 Found a pattern you’re using already — or one that surprised you?
Drop it in the comments or share this with a teammate burning Azure cash.

Stop Using Dumb Search Bars: Build Smart, AI-Powered Search with Azure + .NET

Mohammad Shoeb — Sat, 14 Jun 2025 04:43:53 +0000

Users are typing smart questions, but your search bar is still stuck on keyword matching.
Let’s change that.

🎯 What You'll Build
A .NET Web API that performs semantic + vector hybrid search using Azure Cognitive Search
Integration with Azure OpenAI to implement Retrieval-Augmented Generation (RAG)
Response enrichment that offers intelligent, context-aware answers

🛠️ Prerequisites

Azure subscription with Cognitive Search (Standard+) and Azure OpenAI resources
.NET 7 or 8 SDK installed
IDE: Visual Studio or VS Code

🗂️ Architecture Overview

[User Query] → [.NET API] → [Azure Search (Hybrid)] → [Relevant Docs] → [Azure OpenAI RAG] → [Answer]

⚙️ Step 1: Configure Azure Cognitive Search

Create a Standard or higher-tier Search service in Azure Portal (required for semantic & vector features).

dotnet add package Azure.Search.Documents

Note: Azure SKUs (e.g., Basic won’t work for vector/semantic).

Azure CLI command:

az search service create --name my-search --sku standard --resource-group my-rg

📦 Step 2: Index Your Documents with Embeddings

var client = new SearchClient(new Uri(endpoint), indexName, new AzureKeyCredential(apiKey));
await client.UploadDocumentsAsync(new[]
{
    new
    {
        id = "doc1",
        content = "Azure OpenAI enables powerful GPT models...",
        contentVector = /* byte[] embedding from Azure OpenAI's embedding model */
    }
});

ℹ️ Use Azure OpenAI’s text-embedding-ada-002 or text-embedding-3-small to generate the vector.

🔍 Step 3: Perform Hybrid Semantic + Vector Search

var options = new SearchOptions
{
    Vector = embeddingBytes,
    VectorFields = { "contentVector" },
    QueryType = SearchQueryType.Semantic,
    SemanticConfigurationName = "default",
    Size = 5
};
Response<SearchResults<SearchDocument>> response = await client.SearchAsync("azure ai", options);

💬 Step 4: Add Azure OpenAI for RAG

var openAi = new AzureOpenAIClient(new Uri(openAiEndpoint), new AzureKeyCredential(openAiKey));
var chat = openAi.GetChatCompletionsClient("gpt-35-turbo");

var resultDoc = response.Value.GetResults().First();
string resultContent = resultDoc.Document["content"].ToString();

var completion = await chat.GetChatCompletionsAsync(new ChatCompletionsOptions
{
    Messages = {
        new ChatMessage(ChatRole.System, "You are an AI assistant."),
        new ChatMessage(ChatRole.User, $"Answer based on: {resultContent}\n\nQuery: azure ai")
    },
    Temperature = 0.7f,
    MaxTokens = 256
});
Console.WriteLine(completion.Value.Choices[0].Message.Content);

📈 Real-World Use Cases

Microsoft Learn: uses semantic + vector search for documentation lookup
Enterprise RAG: internal knowledge base Q&A, compliance, automation
Internal copilots: powering smart assistants across domains

🧠 GPT Prompt Engineering Tip

new ChatMessage(ChatRole.User, $"Answer like a search assistant. Use this context: {resultContent}")

✅ Summary & Takeaways
In just 30 minutes, you've gone from basic keyword search to GPT-enhanced hybrid retrieval.

Connected vector embeddings, semantic ranking, and GPT
Production-ready with encryption, scaling, and observability

🔗 References
Azure Cognitive Search – Official Docs
Hybrid Search in Azure
Azure OpenAI Embeddings
Azure OpenAI .NET SDK

⭐ Final CTA
💬 Found this helpful? Share it with your team, leave a clap, and follow for more .NET + Azure AI deep dives.