DEV Community: Manohari Jayachandran

Advanced C# Generics: Contravariance, Custom Comparers and Real Abstractions

Manohari Jayachandran — Thu, 02 Jul 2026 21:48:33 +0000

A previous post on TechStack blog covered the foundations of C# generics - generic classes, methods, basic constraints, and the five main collection types. A reader on Dev.to asked specifically for a contravariant collection base class example. A separate comment noted the first post was too light for senior level. Both pieces of feedback point at the same gap: there is a meaningful difference between using generics and designing with them. This post covers the patterns that belong in the second category, with complete working code throughout.

Quick Recap

The previous post covered these foundations:

// Generic class - type filled at point of use
public class Box<T>
{
    private T _item;
    public void Store(T item) => _item = item;
    public T Retrieve() => _item;
}

// Generic method - type inferred from argument
public T GetFirst<T>(List<T> items)
    => items.Count > 0 ? items[0] : default(T)!;

// Basic constraints
where T : class          // reference types only
where T : new()          // has parameterless constructor
where T : IComparable<T> // supports comparison

This post builds directly on that foundation.

Part 1: Covariance and Contravariance, Properly

The Direction Problem

Generics are invariant by default. A List<string> is not a List<object>, even though every string is an object. This is correct behavior:

List<string> strings = new List<string>();

// Does NOT compile - correct behavior
List<object> objects = strings;

// If it compiled, strings would now contain an int
// and crash at runtime - this is why invariance exists
objects.Add(42);

Covariance and contravariance are the two safe exceptions to this rule, and they work in opposite directions for a specific reason.

Covariance - Safe to Widen the Type (out T)

Covariance is safe when a generic type only ever PRODUCES values of T, never accepts them. If you can only read T out, widening is safe because every string you read out is already an object.

// IEnumerable<T> is declared as IEnumerable<out T> // It only produces T via foreach, never accepts it IEnumerable<string> strings =
    new List<string> { "hello", "world" };

// Compiles - safe covariance
IEnumerable<object> objects = strings;

foreach (var obj in objects)
    Console.WriteLine(obj); // "hello", "world"

// Your own covariant interface
public interface IProducer<out T>
{
    T Produce(); // only ever RETURNS T - safe to widen
}

public class StringProducer : IProducer<string>
{
    public string Produce() => "from string producer";
}

IProducer<string> sp = new StringProducer();

// Compiles because IProducer<out T> is covariant
IProducer<object> op = sp;
object result = op.Produce(); // "from string producer"

Contravariance - Safe to Narrow the Type (in T)

Contravariance is safe when a generic type only ever CONSUMES values of T, never produces them. If something handles any object, it certainly handles a string.

// Action<T> is declared as Action<in T>
// It only consumes T as a parameter, never returns it
Action<object> processObject =
    obj => Console.WriteLine(obj.GetType().Name);

// Compiles - safe contravariance
Action<string> processString = processObject;

processString("hello"); // prints "String"

// Your own contravariant interface
public interface IConsumer<in T>
{
    void Consume(T item); // only ACCEPTS T - safe to narrow
}

public class ObjectPrinter : IConsumer<object>
{
    public void Consume(object item)
        => Console.WriteLine(item);
}

IConsumer<object> oc = new ObjectPrinter();

// Compiles because IConsumer<in T> is contravariant
// Something that handles object handles string too
IConsumer<string> sc = oc;
sc.Consume("works"); // prints "works"

The rule in plain English: out T means the type only produces T (safe to widen). in T means it only consumes T (safe to narrow).

The Contravariant Collection Base Class

Multiple concrete collections sharing a common generic base, usable polymorphically through a contravariant interface - the exact pattern requested on Dev.to.

// Data models
public class Post
{
    public int    Id          { get; set; }
    public string Title       { get; set; } = "";
    public string Slug        { get; set; } = "";
    public string Tech        { get; set; } = "";
    public int    ReadingTime { get; set; }
}

public class Tag    { public string Name { get; set; } = ""; }
public class Author { public string Bio  { get; set; } = ""; }

// Abstract generic base - shared behaviour
// without knowing the concrete type
public abstract class EntityCollectionBase<T>
    : IEnumerable<T>
    where T : class
{
    protected readonly List<T> _items = new();

    public void Add(T item)
    {
        ArgumentNullException.ThrowIfNull(item);
        _items.Add(item);
    }

    public bool Remove(T item) => _items.Remove(item);
    public int  Count          => _items.Count;

    public IEnumerator<T> GetEnumerator()
        => _items.GetEnumerator();

    IEnumerator IEnumerable.GetEnumerator()
        => GetEnumerator();
}

// Concrete collections - each adds domain-specific methods
public class PostCollection : EntityCollectionBase<Post>
{
    public IEnumerable<Post> GetByTech(string tech) =>
        _items.Where(p => p.Tech == tech);
}

public class TagCollection : EntityCollectionBase<Tag>
{
    public IEnumerable<string> Names =>
        _items.Select(t => t.Name);
}

public class AuthorCollection
    : EntityCollectionBase<Author>
{
    public Author? FindByBio(string keyword) =>
        _items.FirstOrDefault(
            a => a.Bio.Contains(keyword));
}

// Contravariant consumer interface
public interface ICollectionProcessor<in T>
{
    void Process(IEnumerable<T> items);
}

// A processor for object handles ANY entity collection
public class ItemLogger : ICollectionProcessor<object>
{
    public void Process(IEnumerable<object> items)
    {
        foreach (var item in items)
        {
            var name = item.GetType().Name;
            Console.WriteLine($"[LOG] {name}: {item}");
        }
    }
}

// The polymorphism in action
var posts = new PostCollection();
posts.Add(new Post { Title = "Advanced Generics" });

var tags = new TagCollection();
tags.Add(new Tag { Name = "Azure" });

ICollectionProcessor<object> logger = new ItemLogger();

// Contravariance - one logger, all entity types
ICollectionProcessor<Post> postLogger = logger;
ICollectionProcessor<Tag>  tagLogger  = logger;

postLogger.Process(posts); // works
tagLogger.Process(tags);   // works

// Generic method that accepts any EntityCollectionBase<T>
public void PrintAll<T>(EntityCollectionBase<T> col)
    where T : class
{
    Console.WriteLine(
        $"{typeof(T).Name}: {col.Count} items");
    foreach (var item in col)
        Console.WriteLine($"  {item}");
}

PrintAll(posts); // Post: 1 items
PrintAll(tags);  // Tag: 1 items

Part 2: Custom Comparers

IComparer - Custom Sorting Logic

IComparer lets you define sorting strategy without touching the class being sorted. Writing a generic KeyComparer once lets you sort any type by any key.

// A generic key comparer - write once, use with any type
public class KeyComparer<T, TKey> : IComparer<T>
    where TKey : IComparable<TKey>
{
    private readonly Func<T, TKey> _keySelector;

    public KeyComparer(Func<T, TKey> keySelector)
    {
        _keySelector = keySelector;
    }

    public int Compare(T? x, T? y)
    {
        if (x == null && y == null) return 0;
        if (x == null) return -1;
        if (y == null) return 1;
        return _keySelector(x)
            .CompareTo(_keySelector(y));
    }
}

// Usage - same class, completely different sort keys
var posts = new List<Post>
{
    new() { Title = "Azure Key Vault",   ReadingTime = 13 },
    new() { Title = "C# Generics",       ReadingTime = 16 },
    new() { Title = "OAuth Token Flows", ReadingTime = 15 }
};

// Sort by reading time
var byReading =
    new KeyComparer<Post, int>(p => p.ReadingTime);
posts.Sort(byReading);
// Result: Azure Key Vault(13), OAuth(15), C# Generics(16)

// Sort by title - same comparer class, different key
var byTitle =
    new KeyComparer<Post, string>(p => p.Title);
posts.Sort(byTitle);
// Result: Azure Key Vault, C# Generics, OAuth Token Flows

// You can also use it with LINQ
var sorted = posts
    .OrderBy(p => p, byReading)
    .ToList();

IEqualityComparer - Custom Equality for Dictionary and HashSet

IEqualityComparer defines what "equal" means when a type is used as a Dictionary key or HashSet member. Both Equals and GetHashCode must stay consistent - equal objects must produce the same hash code.

// Case-insensitive slug lookup for Dictionary
public class CaseInsensitiveStringComparer
    : IEqualityComparer<string>
{
    public bool Equals(string? x, string? y) =>
        string.Equals(
            x, y,
            StringComparison.OrdinalIgnoreCase);

    public int GetHashCode(string obj) =>
        obj.ToUpperInvariant().GetHashCode();
}

// Dictionary with case-insensitive keys
var bySlug = new Dictionary<string, Post>(
    new CaseInsensitiveStringComparer());

bySlug["Azure-Key-Vault"] =
    new Post { Title = "Azure Key Vault" };

// All three find the same post - case doesn't matter
var p1 = bySlug["azure-key-vault"];  // found
var p2 = bySlug["AZURE-KEY-VAULT"];  // found
var p3 = bySlug["Azure-Key-Vault"];  // found

// Custom Post equality based on slug not reference
public class PostBySlugComparer
    : IEqualityComparer<Post>
{
    public bool Equals(Post? x, Post? y)
    {
        if (ReferenceEquals(x, y)) return true;
        if (x == null || y == null) return false;
        return x.Slug == y.Slug;
    }

    public int GetHashCode(Post obj) =>
        obj.Slug?.GetHashCode() ?? 0;
}

// HashSet deduplication by slug, not reference
var uniquePosts = new HashSet<Post>(
    new PostBySlugComparer());

uniquePosts.Add(new Post
{
    Slug = "azure-key-vault",
    Title = "Azure Key Vault"
});

// Duplicate - same slug, different Title
uniquePosts.Add(new Post
{
    Slug = "azure-key-vault",
    Title = "DUPLICATE ATTEMPT"
});

Console.WriteLine(uniquePosts.Count); // 1

The key distinction: IComparer belongs in sort operations. IEqualityComparer belongs in Dictionary and HashSet construction. Mixing them up compiles but does nothing useful.

Part 3: The notnull Constraint and Generic Factories

The notnull Constraint

Introduced in C# 8, notnull restricts T to non-nullable types. It makes intent explicit at compile time rather than leaving null as a runtime surprise.

// Without notnull - null can silently slip through
public T FindFirst<T>(
    List<T> items,
    Func<T, bool> predicate)
{
    // Unsafe - suppresses nullable warning with !
    return items.FirstOrDefault(predicate)!;
}

// With notnull - throw rather than return null
public T FindOrThrow<T>(
    List<T> items,
    Func<T, bool> predicate)
    where T : notnull
{
    return items.FirstOrDefault(predicate)
        ?? throw new InvalidOperationException(
               "No matching item found");
}

// default(T) is different per type - always know which:
// string      -> null
// int         -> 0
// bool        -> false
// DateTime    -> DateTime.MinValue (0001-01-01)
// custom class -> null

// Safe dictionary lookup with notnull key
public T GetOrThrow<T>(
    Dictionary<string, T> dict,
    string key)
    where T : notnull
{
    return dict.TryGetValue(key, out var value)
        ? value
        : throw new KeyNotFoundException(
              $"Key '{key}' not found");
}

// Usage
var posts = new Dictionary<string, Post>
{
    ["azure-key-vault"] =
        new Post { Title = "Azure Key Vault" }
};

var found  = GetOrThrow(posts, "azure-key-vault");
// found.Title = "Azure Key Vault"

var missing = GetOrThrow(posts, "doesnt-exist");
// throws KeyNotFoundException: Key 'doesnt-exist' not found

Generic Factory with Validation

A generic factory pairs where T : new() with an Action for configuration and a Func for validation - construction, configuration, and validation as composable arguments.

public static T CreateValidated<T>(
    Action<T> configure,
    Func<T, bool> validate,
    string errorMessage = "Validation failed")
    where T : new()
{
    var instance = new T();
    configure(instance);

    if (!validate(instance))
        throw new InvalidOperationException(
            errorMessage);

    return instance;
}

// Usage - throws if post has no title or slug
var post = CreateValidated<Post>(
    configure: p =>
    {
        p.Title = "Advanced Generics";
        p.Slug  = "csharp-advanced-generics";
    },
    validate: p =>
        !string.IsNullOrEmpty(p.Title)
        && !string.IsNullOrEmpty(p.Slug),
    errorMessage: "Post must have a title and slug"
);

// This throws
var invalid = CreateValidated<Post>(
    configure: p => { p.Title = ""; p.Slug = ""; },
    validate:  p => !string.IsNullOrEmpty(p.Title),
    errorMessage: "Post must have a title"
);
// throws InvalidOperationException: Post must have a title

Part 4: Generic Repository with Multiple Constraints

Combining constraints shows what the constraint system looks like composed into a real, reusable abstraction.

// Marker interface - only domain entities allowed
public interface IEntity { int Id { get; } }

// Post now implements IEntity
public class Post : IEntity
{
    public int    Id          { get; set; }
    public string Title       { get; set; } = "";
    public string Slug        { get; set; } = "";
    public string Tech        { get; set; } = "";
    public int    ReadingTime { get; set; }
}

// Four constraints combined in one declaration:
// class   - must be a reference type
// IEntity - must have an Id property
// notnull - must not be nullable
// new()   - must be constructable with new T()
public abstract class RepositoryBase<T>
    where T : class, IEntity, notnull, new()
{
    protected readonly List<T> _store = new();

    public virtual void Add(T entity)
    {
        if (_store.Any(e => e.Id == entity.Id))
            throw new InvalidOperationException(
                $"{typeof(T).Name} with Id "
                + $"{entity.Id} already exists");
        _store.Add(entity);
    }

    public virtual T? GetById(int id) =>
        _store.FirstOrDefault(e => e.Id == id);

    public virtual IEnumerable<T> GetAll() =>
        _store.AsReadOnly();

    public virtual bool Delete(int id)
    {
        var entity = GetById(id);
        if (entity == null) return false;
        _store.Remove(entity);
        return true;
    }

    // Create, configure, validate, and add in one call
    // new() constraint lets us call new T() here
    public T CreateAndAdd(
        Action<T> configure,
        Func<T, bool>? validate = null)
    {
        var entity = new T();
        configure(entity);

        if (validate != null && !validate(entity))
            throw new InvalidOperationException(
                $"Validation failed for "
                + $"{typeof(T).Name}");

        Add(entity);
        return entity;
    }
}

// Concrete repository - inherits everything above,
// adds Post-specific queries
public class PostRepository : RepositoryBase<Post>
{
    public IEnumerable<Post> GetByTech(string tech) =>
        GetAll().Where(p => p.Tech == tech);

    public Post? GetBySlug(string slug) =>
        GetAll().FirstOrDefault(
            p => p.Slug == slug);

    // Override to add Post-specific validation
    public override void Add(Post entity)
    {
        if (string.IsNullOrWhiteSpace(entity.Slug))
            throw new InvalidOperationException(
                "Post must have a slug");
        base.Add(entity);
    }
}

// Usage
var repo = new PostRepository();

// Create, configure, validate, and add in one call
var post = repo.CreateAndAdd(
    configure: p =>
    {
        p.Id          = 1;
        p.Title       = "Advanced Generics";
        p.Slug        = "csharp-advanced-generics";
        p.Tech        = "C#";
        p.ReadingTime = 16;
    },
    validate: p => p.ReadingTime > 0
);

// Retrieve
var found = repo.GetBySlug("csharp-advanced-generics");
Console.WriteLine(found?.Title);
// "Advanced Generics"

var csharpPosts = repo.GetByTech("C#");
Console.WriteLine(csharpPosts.Count());
// 1

// Delete
bool deleted = repo.Delete(1);
Console.WriteLine(deleted);       // true
Console.WriteLine(repo.GetAll().Count()); // 0

Part 5: Generic Extension Methods

Extension methods can be generic, making a single implementation available across every type satisfying the constraint - write once, use everywhere.

public static class CollectionExtensions
{
    // Split any IEnumerable<T> into two lists
    // by a predicate - works for any type
    public static (
        List<T> Matching,
        List<T> NotMatching)
        Partition<T>(
            this IEnumerable<T> source,
            Func<T, bool> predicate)
    {
        var matching    = new List<T>();
        var notMatching = new List<T>();

        foreach (var item in source)
        {
            if (predicate(item))
                matching.Add(item);
            else
                notMatching.Add(item);
        }

        return (matching, notMatching);
    }

    // Safe Dictionary conversion - throws on duplicates
    // rather than silently overwriting like ToDictionary
    public static Dictionary<TKey, T>
        ToDictionaryOrThrow<T, TKey>(
            this IEnumerable<T> source,
            Func<T, TKey> keySelector)
        where TKey : notnull
    {
        var result = new Dictionary<TKey, T>();

        foreach (var item in source)
        {
            var key = keySelector(item);
            if (!result.TryAdd(key, item))
                throw new InvalidOperationException(
                    $"Duplicate key detected: {key}");
        }

        return result;
    }

    // Add an item to any ICollection<T> and return it
    // Useful for fluent initialization chains
    public static T AddAndReturn<T>(
        this ICollection<T> collection,
        T item)
    {
        collection.Add(item);
        return item;
    }
}

// Usage - all three extensions work on any type
var posts = new List<Post>
{
    new() { Title = "Azure Key Vault",   ReadingTime = 13 },
    new() { Title = "C# Generics",       ReadingTime = 16 },
    new() { Title = "OAuth Token Flows", ReadingTime = 15 },
    new() { Title = "Azure Service Bus", ReadingTime = 8  }
};

// Partition - split by reading time
var (longPosts, shortPosts) =
    posts.Partition(p => p.ReadingTime >= 15);

Console.WriteLine($"Long: {longPosts.Count}");
// Long: 2

Console.WriteLine($"Short: {shortPosts.Count}");
// Short: 2

// ToDictionaryOrThrow - safe Dictionary from any list
var bySlug = posts.ToDictionaryOrThrow(p => p.Slug);

// AddAndReturn - fluent chain
var newList = new List<Post>();
var addedPost = newList.AddAndReturn(
    new Post { Title = "New Post" });

Console.WriteLine(addedPost.Title); // "New Post"
Console.WriteLine(newList.Count);   // 1

Key Lessons

Use covariance (out T) on interfaces that only produce T - widening is safe because every value coming out already satisfies the broader type.
Use contravariance (in T) on interfaces that only consume T - narrowing is safe because a consumer built for a broader type handles any narrower one.
IComparer belongs in sort operations - Sort(), OrderBy(). IEqualityComparer belongs in Dictionary and HashSet construction. They look similar and solve completely different problems.
The notnull constraint makes nullability intent explicit at compile time rather than leaving null as a runtime surprise for callers.
default(T) behaves differently for reference and value types - always know which category T falls into in context.
Generic extension methods multiply their usefulness because they work across every type satisfying the constraint, not just one specific type.
Multiple constraints combined - class, IEntity, notnull, new() - express a precise contract a concrete type must satisfy, and the base class can rely on every guarantee throughout its implementation.

Summary

The patterns in this post belong in real library and framework design rather than just application code. Covariance and contravariance enable polymorphism across generic types without unsafe casting. Custom comparers
separate ordering and equality logic from data classes. The generic repository with multiple constraints shows the constraint system composed into a real, reusable abstraction. Generic extension methods multiply their usefulness across the entire type system.

These are the generics patterns worth knowing when the goal is designing things other code depends on, not just using things that someone else already built.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=csharp-advanced-generics

First generics post (foundations):
https://www.techstackblog.com/post.html?slug=csharp-generics-collections-explained

OAuth Token Flows and Microsoft Entra ID: How One Application Proves Who It Is to Another

Manohari Jayachandran — Tue, 30 Jun 2026 16:33:15 +0000

A post on my TechStack blog about Azure Key Vault answered the question of where secrets live. This one answers a different, equally fundamental question: how does one application actually prove its identity to another and stay proven over time without constant re-authentication. Managing exactly this - a three-month token refresh cycle for one external system, a six-month cycle for another - was a real operational responsibility on an Azure-based integration platform at Blue Yonder. This post explains the mechanism underneath that responsibility.

What Microsoft Entra ID Actually Is

Microsoft Entra ID, formerly Azure Active Directory and still commonly called Azure AD, is Microsoft's identity platform. It is where users, applications, and services prove who they are before being allowed to do anything at all. Every Managed Identity referenced in earlier posts on this blog is, underneath, an Entra ID identity using exactly the mechanism described here.

Think of a hotel. Checking in verifies identity once - a passport, a reservation, a form of payment. In exchange, the front desk issues a key card. The card itself does not prove who someone is; it proves they were verified recently and are permitted into specific rooms for a specific window of time. The card eventually expires. When it does, full check-in is not required again - showing the old card along with proof of still being a guest is enough to get a new one.

An access token is the key card. The identity verification at check-in is the OAuth flow itself. A refresh token is the proof shown at the desk to get a new card without redoing the full check-in process.

The Core Vocabulary

The Resource Owner is the user, or in service-to-service contexts the system, that owns the data being accessed.
The Client is the application requesting access - a web app, a backend service, a mobile app.
The Authorization Server issues tokens after verifying identity, and in this context that role belongs to Entra ID.
The Resource Server is the API that actually holds the requested data Salesforce's API, ServiceNow's API, or an internal API.
An Access Token is short-lived proof of authorization, the key card itself, sent with every API request typically in the Authorization header. A Refresh Token is a longer-lived credential used to obtain a new access token without re-authenticating from scratch.
Scope defines what a token is actually permitted to do - read access to a resource is a meaningfully different scope from read and write access to that same resource.

Client Credentials Flow

This is the flow that matters most for backend integrations - precisely the kind of system-to-system connection that powers an integration platform. No human is involved at any point. One application proves its own identity directly in order to gain access to another application system's API.

The application holds a Client ID and either a Client Secret or a certificate, registered in Entra ID ahead of time. It sends those credentials directly to the Entra ID token endpoint. Entra ID verifies the credentials and returns an access token - no user, no browser redirect, no login screen anywhere in this entire exchange. The application includes that access token in the Authorization header of every subsequent API call to the target system. When the access token expires, commonly after one hour, the application requests a new one using the same client credentials, and the cycle repeats automatically - usually handled transparently by a library rather than custom code.

In C#, using the Microsoft.Identity.Client (MSAL) NuGet package, this means building a ConfidentialClientApplication with the client ID, client secret, and tenant authority, then calling AcquireTokenForClient with the target scope. MSAL caches the resulting token automatically and silently refreshes it on subsequent calls if the cached token has expired - there is no need to write manual expiry-checking logic in application code.

Authorization Code Flow

This is the flow behind every "Sign in with Microsoft" button. Unlike client credentials, a real human user is present and must explicitly approve the requested access.

A user clicks sign in, and the browser redirects to Entra ID's login page.
The user authenticates - password, multi-factor authentication, whatever policy requires - and approves the requested scopes.
Entra ID redirects back to the application with a short-lived authorization code, deliberately not a token yet.
The application's backend then exchanges that code, along with its own client secret, for an access token and a refresh token.
The access token handles subsequent API calls; when it expires, the refresh token obtains a new access token without requiring the user to log in again.

The reason the code-for-token exchange happens server-side, separately from the browser redirect, is a deliberate security measure. The authorization code passes through the user's browser and could theoretically be intercepted, but it is useless on its own without the client secret, which never leaves the application's backend.

Why Access Tokens Are Deliberately Short-Lived

If an access token leaks - logged accidentally, intercepted in transit, stored somewhere insecure - a short expiry limits the actual damage window. A typical access token lifetime is around one hour. A typical refresh token lifetime runs closer to ninety days, often configurable, and frequently with sliding expiration where each use resets the clock.

This is precisely why token refresh cycles become a genuine operational concern in production systems. A refresh token itself eventually expires too, and if nothing actively refreshes it before that happens, the integration breaks until someone manually re-authenticates from scratch. The three-month and six-month cycles managed at Blue Yonder for two different external systems were exactly this scenario - each external provider enforced its own refresh token lifetime, and centralizing those credentials in Key Vault meant there was one governed place to monitor expiry and rotate credentials proactively, rather than discovering an integration had silently broken.

What a JWT Actually Contains

Most Entra ID access tokens are JSON Web Tokens, a specific and inspectable format rather than a random opaque string.
A JWT consists of three parts separated by dots -
a header indicating which algorithm signed the token,
a payload containing the actual claims (who issued it, who it is intended for, what scopes it carries, when it expires), and
a signature providing cryptographic proof the token has not been tampered with.

A critical detail: JWTs are signed, not encrypted. The payload is fully readable by anyone holding the token, even without any ability to forge a new one. This is precisely why a JWT should never contain sensitive data directly in its claims - readability is not a bug in this format, it is the design and treating the payload as confidential is a genuine security mistake.

Validating a Token on the Receiving Side

Protecting an API endpoint with token validation in ASP.NET Core involves configuring JWT Bearer authentication with the expected authority and audience, and enabling validation of the issuer, audience, lifetime, and signing key. Once configured, an Authorize attribute on a controller action is enough to require a valid token - the middleware itself handles signature verification, expiry checking, issuer checking, and audience checking automatically none of which needs to be written by hand.

Refresh Token Rotation

Conceptually, refreshing an access token means sending a request to the token endpoint with a grant type of refresh token, the client credentials, and the previously stored refresh token. The response contains a new access token, and frequently a brand new refresh token as well - a pattern called refresh token rotation, where the old refresh token is invalidated the moment a new one is issued.

This rotation behavior is worth knowing about specifically, because it is a genuine, subtle source of production bugs. If a system stores a refresh token and the provider rotates it on every use, the stored copy must be updated after every single refresh. Skip that update once, and the next refresh attempt fails with an invalidated token - often discovered only when an integration that worked fine in testing quietly stops working in production weeks later.

Common Mistakes

Storing access tokens long-term defeats their entire security model - they are designed to be short-lived and re-fetched frequently, not cached for days.
Hardcoding a client secret directly in source code repeats the exact mistake covered in the Key Vault post on this blog - client secrets belong in Key Vault or GitHub Secrets, never committed alongside application code.
Failing to handle refresh token rotation correctly, as described above, causes integrations to fail unpredictably after their first successful refresh cycle.
Requesting overly broad scopes - asking for full read and write access when only read access is actually needed - is a real, avoidable security smell worth catching in code review.
Confusing authentication with authorization is a more conceptual mistake: a valid token proves who is asking, but it does not automatically mean they are permitted to do what they are asking. That second check is a separate concern, typically handled through scopes or application roles layered on top of basic token validity.

Choosing the Right Flow

Client Credentials Flow fits service-to-service scenarios with no human user present - backend integrations calling another backend API, scheduled jobs, daemon processes, and the Salesforce and ServiceNow style integrations referenced throughout this blog's other posts. Authorization Code Flow fits scenarios where a real human user needs to log in and the application acts on that specific user's behalf - any "sign in with Microsoft" style scenario.

Neither flow is more secure than the other in the abstract; they solve genuinely different problems. Using client credentials for a user-facing login, or authorization code for a headless backend job, are both signs of reaching for the wrong flow for the actual situation at hand.

How This Connects to the Rest of This Blog's Azure Coverage

Key Vault, covered in an earlier post, is where the client secret in this entire flow actually lives. Managed Identity, covered in that same post, is in fact a special case of this exact OAuth machinery - an Azure resource receives an automatically managed Entra ID identity, and the client credentials flow happens entirely behind the scenes with no secret for a developer to manage at all. Application Insights, covered in an even earlier post, is where a failed token refresh would actually surface in production - an exception appearing in the logs, a spike in 401 responses, exactly the kind of pattern a KQL query against the requests table would catch quickly.

Key Lessons

Client Credentials Flow is the right mental model for almost every backend-to-backend Azure integration - two systems proving identity to each other with no user involved anywhere in the exchange.
Refresh tokens exist specifically so a long-running integration does not require constant manual re-authentication, but they still expire, and that expiry genuinely needs active, ongoing monitoring.
Refresh token rotation is a frequent, subtle source of production bugs whenever a stored token is not updated on every single refresh.
A JWT's payload is readable by anyone holding the token - sensitive data should never be placed directly in token claims.
Managed Identity removes the need to manage a client secret at all by having Azure itself handle the client credentials flow transparently on a resource's behalf.
Requesting the minimum scope an integration genuinely needs, rather than the broadest available scope, is a simple and frequently overlooked security improvement.

Summary

OAuth 2.0 is the mechanism underneath nearly every system-to-system connection in enterprise Azure architecture.
Client Credentials Flow handles service-to-service trust with no user involved at all.
Authorization Code Flow handles a real user logging in and delegating access.
Access tokens are short-lived by design; refresh tokens exist to renew them quietly behind the scenes, and both carry real expiry windows that demand active management in any long-running integration.

Understanding this properly is what separates simply knowing an API call works from actually understanding why it works - and why it eventually stops working if nobody is watching the token lifecycle underneath it.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-ad-oauth-token-flows-explained

Related reading on TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-key-vault-secrets-management

More from TechStack Blog, by category:
Azure: https://www.techstackblog.com/category.html?cat=azure
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Follow for weekly posts on Azure, C#, and cloud engineering.

C# Generics and Collections: The Interview Topic That Comes Up Every Single Time

Manohari Jayachandran — Sun, 28 Jun 2026 14:01:57 +0000

Of all the C# topics that come up in technical interviews, generics and collections show up the most consistently - across junior, mid, and senior level conversations. Not because they are exotic, but because they are the foundation almost every other piece of C# code sits on top of. This post covers both properly, with the analogies that made them click and real code from the kind of work that actually shows up in production systems.

Part 1: Generics

The Problem Generics Solve

Before generics existed in C#, building a container that could hold any type meant choosing between two bad options: writing a separate class for every single type - endless, near-identical duplication - or using the base object type and casting everything, which threw away compile-time type safety and added a real performance cost for value types through boxing.

Think of a generic class like a shipping container with a label you fill in later. The container itself - its size, its locking mechanism, how it gets loaded onto a ship - is exactly the same regardless of what goes inside. You write the container once. At the moment you actually use it, you decide: this one holds books, this one holds electronics, this one holds furniture. The container does not need to be rebuilt for each cargo type - but once declared to hold books, it refuses to let someone load a refrigerator into it instead.

Generic Classes in Practice

A generic class declares one or more type parameters, conventionally named T, that get filled in at the point of use rather than when the class is written. A simple Box class written once as Box<T> works identically well for Box<Post>, Box<int>, or Box<string> - the compiler enforces that whatever type was specified at creation is the only type that class instance will ever accept, with zero runtime casting required anywhere.

Generic Methods

The same idea applies at the method level without requiring an entire generic class. A method that returns the first item in any list, or null if the list is empty, can be written once as a generic method and called with a list of posts, a list of integers, or a list of strings equally correctly, with the compiler inferring the type parameter automatically from what gets passed in.

This is, in fact, exactly what every LINQ method already does. Where and Select are generic methods under the hood - the reason they work identically well on a list of blog posts and a list of integers is the same generic mechanism covered here, not separate special-cased implementations for every possible type.

Generic Constraints

Sometimes a generic container should not accept literally any type - it should only accept types with certain specific capabilities. Constraints express that restriction directly in the type parameter declaration.

A constraint of where T : class restricts T to reference types only.
A constraint of where T : IComparable<T> guarantees that comparison operations are actually available inside the generic code, which matters
enormously for something like a generic GetMax method that needs to compare items to find the largest one.
A constraint of where T : new() guarantees a public parameterless constructor exists, which is required before generic code can legally write new T() to create an instance.
Multiple constraints can combine - a repository base class might reasonably require where T : class, IEntity, new() all at once.

A small but realistic generic repository pattern over Entity Framework Core illustrates this well: a single Repository class, constrained to where T : class, provides GetByIdAsync and GetAllAsync methods that work correctly for Post, Tag, or Comment entities without writing three nearly identical repository classes.

Covariance and Contravariance

This is the part interviewers most often use to probe deeper understanding, and it is genuinely simpler than it sounds once translated out of the in/out keyword syntax into plain language.

Covariance, marked with the out keyword in an interface declaration, allows a more derived type to be used where a less derived type was originally specified. IEnumerable is declared as covariant, which is why a List<string> can be assigned to an IEnumerable<object> variable without any cast - if something only ever produces values of type T by reading them out, it is probably safe to treat every string as the
object it also happens to be.

Contravariance, marked with the in keyword, runs the opposite direction - it allows a less derived type to be used where a more derived type was specified. Action is contravariant, which is why an Action<object> can be assigned to an Action<string> variable - something that knows how to process any object can certainly handle the more specific case of a string, since a string satisfies every requirement an object-handling method might have.

Part 2: Collections

If generics are the shipping container with a fillable label, collections are the different container designs built on top of that same underlying pattern - a numbered shelf, a labeled drawer system where each drawer has exactly one name, a single-entry tube, a stack of plates where only the top one is reachable. Same generic foundation, shaped differently for different access patterns.

List<T>

The default, ordered, resizable collection - genuinely the correct first choice in the large majority of real-world cases. List preserves insertion order, supports fast indexed access, and handles frequent additions and removals well. Use it whenever order matters and there is no specific reason to reach for something more specialized.

Dictionary<TKey, TValue>

The collection built specifically for fast lookup by a unique key. Where List.Contains() or a manual loop scans through every item until it finds a match - an O(n) operation that gets slower as the collection grows - Dictionary lookup by key is close to O(1) regardless of how many entries exist. The moment "look this thing up by some identifier" becomes a frequent operation in a piece of code, that is the signal to reach for a Dictionary rather than continuing to scan a List.

TryGetValue provides a safe lookup pattern that avoids exceptions when a key might not exist, which is almost always preferable to a direct indexer access wrapped in a try/catch.

HashSet<T>

A collection whose entire purpose is guaranteeing uniqueness and supporting fast set operations. Adding a duplicate value to a HashSet simply does nothing rather than creating a second copy and checking whether a value exists runs in close to O(1) time rather than the O(n) scan a List would require. Beyond simple uniqueness, HashSet supports genuine set operations - union, intersection, and except - that are easy to forget exist but are often exactly the right tool when comparing two collections of tags, categories, or identifiers.

Queue<T> and Stack<T>

Two collections where the access pattern itself is the entire point.
Queue is first-in-first-out, conceptually identical to a line at a coffee shop - the first item added is the first item retrieved.
Stack is last-in-first-out, conceptually identical to a stack of plates - the most recently added item is the first one retrieved. These are not purely academic constructs invented for textbooks - every running program's call stack is, quite literally, a stack of execution frames, and many real messaging systems implement queue-like processing semantics for exactly the reasons a Queue would suggest.

IEnumerable<T> vs IList<T> vs List<T>

This is close to a guaranteed interview question in some form, and the honest answer is a hierarchy of guarantees rather than a single right answer.

IEnumerable is the most general - it guarantees only that the collection can be iterated once with foreach, with no promise of indexed access or even an efficient Count. LINQ queries are returned as IEnumerable specifically because of deferred execution, where the underlying work has not actually run yet at the point the type is returned.

IList adds indexed access, a real Count property, and Insert/RemoveAt methods, while still remaining an interface rather than a concrete implementation - useful when a method needs indexing but should stay abstract about exactly which concrete collection type a caller provides.

List is the concrete implementation most code actually instantiates and works with directly.

The practical, interview-relevant rule that ties this together: accept the most general type a method actually needs as a parameter - frequently IEnumerable, since many methods only need to iterate once - and return the most specific type that gives callers genuinely useful guarantees, frequently List or an array, rather than hiding a concrete result behind an unnecessarily abstract interface.

Why the Old Non-Generic Collections Should Never Appear in New Code

ArrayList and Hashtable predate generics in the .NET framework and store everything as the base object type. Every read requires an explicit cast, which both adds overhead and removes compile-time type checking - a type
mismatch that should be caught immediately by the compiler instead surfaces later as a runtime InvalidCastException. Value types stored in these collections also get boxed, wrapped in an object allocated on the heap, which carries a genuine, measurable performance cost compared to a generic List storing integers directly without any boxing at all. There is no scenario in modern C# where reaching for ArrayList or Hashtable over their generic equivalents is the right engineering decision.

Why Dictionary Lookup Is Actually O(1)

A Dictionary is backed by a hash table internally. Each key gets run through a hash function that produces a number, and that number determines which internal bucket the entry is stored in. Looking up a key means hashing it and jumping directly to the relevant bucket, rather than scanning through every stored entry in sequence - which is precisely why lookup time stays close to constant regardless of how many items the Dictionary holds.

This convenience comes with one real responsibility: a custom class used as a Dictionary key must correctly override both GetHashCode and Equals, consistently with each other. Get this wrong, and lookups fail in confusing, silent ways - entries land in unexpected buckets, or two objects that should be treated as equal are instead treated as entirely different keys.

Key Lessons

Default to List unless there is a specific, identifiable reason to reach for something else - it remains correct for the large majority of real-world cases.
Reach for Dictionary the moment looking something up by an identifier becomes a frequent operation - the jump from O(n) to O(1) is a real, measurable difference at any meaningful scale. Use HashSet for uniqueness guarantees and set operations rather than manually checking Contains on a List inside a loop.
Accept IEnumerable in method parameters specifically when a method only needs to iterate once - it keeps an API's surface flexible for whatever callers want to pass in.
Return concrete types like List when callers genuinely need the stronger guarantees a concrete type provides, rather than hiding behind an abstraction that gives them less to work with.
Never reach for the legacy non-generic collections in new code - there is no remaining scenario in modern C# where they represent the better engineering choice.
If a custom class is ever used as a Dictionary key, both GetHashCode and Equals must be overridden correctly and consistently, or lookups will fail in ways that are genuinely difficult to debug after the fact.

Summary

Generics make it possible to write a single class or method that works correctly and safely across many different types, without duplicating code and without giving up compile-time type checking along the way. Collections are the most common, most practical application of that underlying idea - List, Dictionary, HashSet, Queue, and Stack are all generic containers shaped deliberately for different access patterns. Knowing which one genuinely fits a given problem, and being able to
explain why, is one of the most consistently tested pieces of C# knowledge in technical interviews, precisely because it is also one of the most consistently used pieces of knowledge in real production code.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=csharp-generics-collections-explained

More from TechStack Blog, by category:
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
Azure: https://www.techstackblog.com/category.html?cat=azure

Follow for weekly posts on C#, Azure, and cloud engineering.

Azure Table Storage: The Middle Ground Between a SQL Table and a Document Database

Manohari Jayachandran — Fri, 26 Jun 2026 15:01:28 +0000

I published a comparison of Azure SQL, Cosmos DB, and Blob Storage a little while back. Looking back at it, Azure Table Storage was a real gap - it sits in a genuinely useful middle position between a relational table and a full document database, and it deserves its own proper explanation rather than a passing mention. This post fills that in, with real C# code and a few lessons from using it in production alongside Azure Service Bus at Blue Yonder.

What Azure Table Storage Actually Is

Azure Table Storage is a NoSQL key-value store for large amounts of structured, non-relational data. It occupies an interesting middle position - simpler and considerably cheaper than Cosmos DB, while still being schema-flexible in a way Azure SQL fundamentally is not. Despite the name, it has nothing to do with SQL tables in the relational sense - "table" here is closer to a giant, partitioned dictionary than a database table with fixed columns.

Azure SQL is a filing cabinet with identical forms in every folder.
Cosmos DB is a box of index cards where every card can say something different.
Table Storage sits somewhere in between - a long row of labeled shoeboxes on a shelf, where each shoebox holds many index cards, and every card in a shoebox can still carry different fields, but things get found quickly specifically because you know which shoebox to check first.

Where Table Storage Actually Sits

Against Azure SQL, Table Storage trades real relational power and joins for dramatically lower cost and a flexible schema per entity.
Against Cosmos DB, it trades rich query capability and global distribution for an even simpler pricing model and operational footprint. It is genuinely the cheapest of the three options, and the one with the most limited query language by a meaningful margin.

Core Concepts

A Table is a collection of entities - schema-flexible in spirit, similar to a Cosmos DB container, but considerably simpler in practice.
An Entity is a single row-like record, identified by a PartitionKey and a RowKey, plus any number of additional properties beyond those two required fields.
The PartitionKey groups related entities together for fast lookup and horizontal scalability - exactly the same kind of design decision as a partition key in Cosmos DB, and just as consequential if chosen poorly. The RowKey uniquely identifies an entity within its specific partition.

Together, PartitionKey and RowKey form an entity's complete unique identifier within the table.

A practical example makes the flexibility clear: two log entities sharing the same partition, representing the same month, can still carry entirely different fields if a logging format changes over time - no schema migration required, the same flexibility spirit as Cosmos DB, at a fraction of the operating cost.

Reading and Writing From C

After installing the Azure.Data.Tables NuGet package, working with Table Storage from C# follows a straightforward pattern: construct a TableClient pointed at a specific table, then read and write TableEntity objects using their PartitionKey and RowKey.

A point read - fetching one specific entity by its exact PartitionKey and RowKey - is the fastest possible operation the service offers, conceptually identical to a point read in Cosmos DB. Querying within a single partition using a filter expression remains fast and well-supported. Updates and deletes follow the same PartitionKey-plus-RowKey addressing scheme throughout.

The Query Language, and Its Real Limitation

This is where Table Storage is honest about being the cheapest, simplest option of the three. There is no SQL-like query language the way Cosmos DB offers one. Filtering uses OData-style string expressions - reasonably readable for simple conditions, but with no joins, no aggregates, and no server-side grouping available at all.

A filter checking for entities in a specific partition with a specific status level reads naturally enough as an OData expression,and produces broadly similar results to the equivalent Azure SQL or Cosmos DB query for that simple case. The difference becomes obvious the moment a query needs a join, an aggregate like a count or an average, or needs to span many partitions efficiently. Table Storage simply does not offer that capability - querying happens within a partition, or by scanning across all partitions, with nothing in between.

Why The Limitation Is Actually The Point

Table Storage deliberately trades query power for extreme low cost and high throughput on simple lookups. It is the right tool specifically when the access pattern is almost always "give me everything in partition X" or "give me the one entity at this exact PartitionKey and RowKey combination" - when joins, aggregates, and complex filtering are simply not needed, when data volume runs into the millions of records but the logic per record stays simple, and when cost matters more than query flexibility.

Real-world scenarios that fit this profile well include application logging and audit trails, IoT telemetry keyed by device identifier and timestamp, session state keyed by session identifier, simple lookup caches, and a message or event audit trail running alongside a service like Azure Service Bus - logging every message processed, keyed by date and message identifier, without needing the query power or cost of a full database to answer a simple question like "did this message get processed, and when." At Blue Yonder, Table Storage and Service Bus worked together in exactly this way, with Service Bus handling actual message delivery while Table Storage held a lightweight, low-cost record of what had moved through the pipeline.

A Genuine Naming Trap Worth Knowing

Confusingly, Cosmos DB also offers its own "Table API" that uses the exact same entity model - PartitionKey and RowKey - and is largely code-compatible with standalone Table Storage. Azure Table Storage, the storage-account-based service covered in this post, remains the cheapest option, with no throughput SLA beyond standard storage account limits and the simplest possible pricing model. Cosmos DB's Table API uses the identical programming model but runs on Cosmos DB's underlying infrastructure - global distribution, guaranteed throughput, multi-region replication - at Cosmos DB pricing.

The practical migration path this enables is genuinely useful: start on plain Table Storage for cost efficiency, and if global distribution or guaranteed low-latency service levels become necessary later, migrate to Cosmos DB's Table API with minimal code changes, since the entity model is shared between them.

No native recovery - know this before you rely on it

Table Storage has no built-in soft-delete or point-in-time restore for individual entities - once deleted, an entity is gone immediately. The common production workaround is to never actually delete: add an IsDeleted flag and update it instead, or pair the table with a scheduled export for backup. This is a real limitation, and it is part of why Table Storage fits append-heavy, rarely-deleted data (logs, telemetry, audit trails) far better than it fits data where deletion and recovery are routine operations.

An Honest Three-Way Comparison

Choose Azure SQL when data is relational, real joins and aggregates are genuinely needed, and the data shape stays consistent across records.
Choose Table Storage when data volume is high and the access pattern is simple - point lookups or partition scans - and cost matters more than
query flexibility.
Choose Cosmos DB when document shape varies meaningfully between records, real query power over JSON structure is needed, or global distribution and guaranteed low-latency reads are genuine requirements.

Key Lessons

Table Storage and Cosmos DB share an entity model but are priced and operated in completely different ways - know precisely which one is actually being provisioned before committing to either.
The OData filter syntax is genuinely limited. If a query needs a join or an aggregate, Table Storage is the wrong tool for that job regardless of how attractive its cost looks.
PartitionKey design matters here exactly as much as it does in Cosmos DB get it wrong and partition scans become expensive as data grows.
Table Storage is frequently the right default first choice for logging and telemetry data specifically because that access pattern is almost always simple key-based lookups rather than anything more complex.
Pairing it with a messaging service like Service Bus for a lightweight audit trail is a genuinely useful pattern worth knowing, not just a theoretical one.

Summary

Azure Table Storage fills the real gap between a relational table and a full document database - schema-flexible in the same spirit as Cosmos DB, but priced and queried far more simply, with genuine limitations on what it can be asked to do. It earns its place specifically when the access pattern is simple and the volume is high. It was a gap worth closing properly, with real production context behind it rather than just a theoretical comparison.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-table-storage-explained

Related reading on TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-cosmos-db-blob-storage

More from TechStack Blog, by category:
Azure: https://www.techstackblog.com/category.html?cat=azure
Database: https://www.techstackblog.com/category.html?cat=database

Follow for weekly posts on Azure, C#, and cloud engineering.

Azure Cosmos DB and Blob Storage: When SQL Is Not the Right Tool

Manohari Jayachandran — Wed, 24 Jun 2026 16:35:38 +0000

Every post on my blog so far has used Azure SQL - a relational database with a fixed schema, queried with standard SQL. That has been the right choice for the blog's Posts table, which is tabular and consistent in shape. But not every kind of data fits neatly into rows and fixed columns, and not every kind of content belongs in a database row at all. At Blue Yonder, I used Cosmos DB to hold operational and application data from an Azure-based integration platform, querying it with KQL to support troubleshooting and reporting - a genuinely different use case from a primary transactional database, and a good illustration of just how flexible the document model can be. This post covers the two Azure services worth reaching for when SQL genuinely is not the right fit: Cosmos DB for flexible, fast-changing JSON documents, and Blob Storage for files.

What Azure Cosmos DB Actually Is

Azure Cosmos DB is a fully managed NoSQL database built for global distribution and elastic scale. Instead of rows constrained to fixed columns, it stores JSON documents - and critically, each document can have a different shape from the next, even within the same container.

Azure SQL is a filing cabinet with labeled folders and a fixed form inside each one - every form has the same fields in the same order, every single time. Cosmos DB is closer to a box of index cards, where each card can hold completely different information structured however makes sense for that one card, while still letting you flip through the whole box quickly when needed.

A Concrete Comparison Using This Blog's Own Data

The Posts table in Azure SQL has a fixed set of columns - Id, Title, Slug, Tech, and so on. Every row shares exactly the same structure. Adding a genuinely new field - say, an array of structured code blocks with language tags - means altering the table schema for every single row, even posts that will never use that field.

The same data reshaped as a Cosmos DB document removes that constraint entirely. One document might carry a codeBlocks array with language and code properties. A different document might instead carry a relatedServices array and a diagramUrl pointing at an image. Neither document needs to match the other's shape, and no schema migration is required to introduce a field that only some documents will ever use.

Core Cosmos DB Concepts

An Account is the top-level Cosmos DB resource - a single account can actually support multiple APIs, including NoSQL, MongoDB, Cassandra, Gremlin, and Table, though the NoSQL API is the most commonly used and the one covered here.
A Database is a logical grouping within an account, conceptually similar to a SQL database.
A Container is roughly the document-world equivalent of a SQL table, but with no fixed schema enforced across the documents inside it.
An Item, or document, is a single JSON object inside a container - roughly equivalent to a row, but with a flexible shape.

The Partition Key deserves its own emphasis, because it is genuinely the single most consequential design decision in Cosmos DB. It is a property within your document used to distribute data across physical partitions for scale. Choosing poorly does not just create a minor inefficiency - it can cause real performance problems as data grows, because all writes for a given partition key value land on the same physical partition.

Choosing a Partition Key

For a hypothetical Posts container, several candidates illustrate the tradeoff clearly. Partitioning by technology tag works well if queries are usually filtered by technology, but risks creating a disproportionately large "Azure" partition if that tag dominates the content, which becomes a hot, oversized partition relative to the others. Partitioning by slug guarantees excellent distribution since every slug is unique, but querying "all posts" still requires a fan-out across every partition, which costs more in Request Units. Partitioning by year suits time-based access patterns well, but concentrates all of the current year's writes onto a single partition until the calendar turns over.

The actual rule underlying all of this: pick the property that aligns with the most frequent query pattern in your application, while also spreading data roughly evenly across many distinct values.

Querying Cosmos DB

Cosmos DB's NoSQL API uses a query language that visually resembles SQL but operates over JSON structure rather than table columns. Anyone who already knows SQL picks this up quickly. A query like selecting title, slug, and reading time from a container, filtering where a tech array contains "Azure", and ordering by reading time descending, reads almost identically to the equivalent Azure SQL query - the syntax is genuinely that close for simple cases.

Where it diverges meaningfully is querying into nested structures. Cosmos DB can join directly into an array nested inside the same document - for instance, finding every code block with a specific language tag, embedded inside posts - without needing a second table at all. The equivalent in a relational model requires an actual separate table and a real JOIN across tables, since SQL has no native concept of an array living inside a single row.

LINQ Against Cosmos DB

For anyone who has used Entity Framework Core's LINQ support against Azure SQL, querying Cosmos DB from C# will feel immediately familiar at the syntax level - Where, OrderByDescending, and the rest of the standard LINQ vocabulary all work against a Cosmos DB container through its LINQ provider. The vocabulary is the same. The engine underneath is completely different - EF Core generates T-SQL against a relational engine, while Cosmos DB's LINQ provider generates its own SQL-like query against a document store with an entirely different cost and performance model. Familiar syntax does not imply equivalent execution.

Request Units

Cosmos DB does not bill the way Azure SQL does, on compute tiers and DTUs or vCores. It bills on Request Units, a normalized measure of the cost of any given operation. A simple point read by id and partition key is roughly one Request Unit - the cheapest possible operation in the system. A broader query scanning many documents can cost tens or hundreds of Request Units depending on its complexity. Writes typically cost more Request Units than an equivalent read.

Two billing modes exist. Provisioned throughput reserves a fixed Request Unit per second capacity that is paid for whether it is fully used or not - appropriate for predictable, steady traffic. Serverless mode charges only for the Request Units actually consumed, with no fixed reservation at all - a far better fit for unpredictable, generally low-traffic workloads, which describes most personal blogs and small applications far more accurately than a fixed provisioned tier would.

When Cosmos DB Is The Right Choice Over Azure SQL

Cosmos DB earns its place when document shape varies significantly between items, when an application needs single-digit millisecond reads at genuinely global scale, when multi-region write distribution matters, when data is naturally hierarchical or nested in a way that maps cleanly to JSON, or when throughput needs to scale elastically and automatically without manual intervention.

Azure SQL remains the better choice when data is naturally tabular with a consistent shape across records, when strong relational integrity through foreign keys and joins across many related tables genuinely matters, when a team already thinks fluently in SQL and the data fits that model comfortably, or when complex multi-table transactions are a common part of the workload.

This blog's own Posts data is tabular and consistent in shape - Azure SQL remains the correct choice for it. Where Cosmos DB genuinely earns its place, based on real production experience, is somewhere quite different from "replace your application database": holding operational and log data from an integration platform, where one event might carry a handful of fields and another dozens, then querying that data with KQL for troubleshooting and reporting rather than serving it as primary application content. That pattern - flexible storage for fast-changing
operational data, queried for insight rather than served to end users - is worth knowing even for engineers who never touch Cosmos DB as a primary database.

What Azure Blob Storage Actually Is

Azure Blob Storage stores unstructured files - images, videos, PDFs, backups, log files - as objects called blobs, organized inside containers. It functions as neither a traditional database nor a traditional filesystem but remains accessible over HTTP in a way that feels filesystem- like in practice.

If Azure SQL and Cosmos DB are both filing systems built for structured information, Blob Storage is closer to a warehouse. There is no querying the contents of what sits inside a stored box - only knowing which box it is, after which the warehouse hands it over, whole, exactly as it was left.

Blob Storage Tiers

The Hot tier is optimized for frequently accessed data, carrying the highest storage cost paired with the lowest access cost - appropriate for something like images displayed on a blog's homepage that get requested constantly. The Cool tier suits infrequently accessed data intended to be stored for at least thirty days, trading lower storage cost for higher access cost relative to Hot - last month's exported analytics reports fit naturally here. The Archive tier suits data rarely accessed at all, intended for at least one hundred eighty days of storage, with the lowest storage cost and highest access cost of the three, plus the detail that data must be rehydrated before it can be read again, a process that can take hours - genuinely multi-year backups nobody expects to open belong here.

Blob Types

Block Blobs are the most common type, optimized for efficiently uploading large amounts of data in individually manageable blocks - the right choice for images, video, documents, and backups in the overwhelming majority of cases.
Append Blobs are optimized specifically for append operations, allowing data to be added to the end without modifying what already exists - well suited to logging scenarios where new entries continuously accumulate.
Page Blobs are optimized for random read and write access patterns, primarily relevant to virtual hard disk files backing virtual machines, a scenario that rarely comes up outside infrastructure-focused work.

SAS Tokens

Blob containers are private by default, which is the correct default. A Shared Access Signature, or SAS token, grants temporary, narrowly scoped access to a blob or container without making the entire container public and without sharing the storage account's actual access key. A SAS token can be constrained to a specific blob, a specific permission like read-only, and a specific expiration time - a token built to expire in one hour, granting read-only access to exactly one blob, does exactly that and nothing more once it expires.

Where This Blog Would Realistically Use Blob Storage

A few concrete, realistic use cases stand out for this specific project, none of which are implemented yet. Post cover images and inline diagrams currently rely on external links rather than self-hosted assets - Blob Storage would be the natural home for self-hosted images served from a stable URL. The Open Graph share image used for social previews is currently committed directly into the frontend code repository - it could instead live in Blob Storage behind a CDN, cleanly separating binary assets from application source code. Scheduled database backups, exported independently of Azure SQL's own built-in backup retention, would fit naturally in the Cool tier. And if a comments feature with image uploads is ever added, Blob Storage is precisely the right service for storing user-submitted files.

The Three Services, Side By Side

Azure SQL handles fixed-shape rows, queried in standard SQL, requiring a defined schema, and billed on a DTU or vCore model - the right fit for relational, structured data, which describes this blog's own Posts table accurately.
Cosmos DB handles flexible JSON documents, queried in a SQL-like language suited to NoSQL access patterns, requiring no fixed schema, and billed on Request Units - the right fit for fast-changing documents that need global scale.
Blob Storage handles raw files with no query language at all beyond retrieval by key, requiring no schema in the traditional sense, and billed per gigabyte stored plus per operation - the right fit for images, video, backups, and any other genuinely unstructured content.

Key Lessons

Choosing a Cosmos DB partition key is the single decision most likely to cause real performance problems later if made carelessly early on.
Serverless billing mode fits unpredictable, low-to-moderate traffic far better than provisioned throughput - defaulting to provisioned out of habit, without a real reason, adds cost without a corresponding benefit.
SAS tokens belong on any blob access that needs to be temporary or narrowly scoped - a fully public container should be reserved for content that is genuinely meant to be public without exception.
LINQ syntax transfers comfortably between EF Core and Cosmos DB, but the execution engine and cost model underneath are entirely different - familiarity with the syntax should not be mistaken for familiarity with the performance characteristics.
The actual skill is matching the shape of the data to the right service, not defaulting to whichever tool sounds newest or most powerful. A relational table remains exactly the right choice for plenty of real workloads, including this blog's own. And Cosmos DB's most valuable real-world use is not always "primary database" - operational and log data analysis, queried with KQL, is a pattern worth recognizing on its own.

Summary

Azure SQL fits data that is naturally tabular and relational. Cosmos DB fits data that is naturally document-shaped, fast-changing, or in need of global low-latency distribution. Blob Storage fits anything that is fundamentally a file rather than structured data at all. All three coexist comfortably within real Azure architectures - the genuine skill lies in matching the shape of the data to the right service, rather than selecting one tool and forcing every problem through it regardless of fit.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-cosmos-db-blob-storage

More from TechStack Blog, by category:
Azure: https://www.techstackblog.com/category.html?cat=azure
Database: https://www.techstackblog.com/category.html?cat=database

Follow for weekly posts on Azure, C#, and cloud engineering.

Azure Key Vault: Where Every Secret in This Blog Actually Lives

Manohari Jayachandran — Mon, 22 Jun 2026 15:33:14 +0000

I have written some version of "never hardcode secrets, store them in Key Vault instead" in at least five of my last nine posts on this blog. I never actually stopped to explain what that means in practice. This post fixes that, using the real secrets this very blog depends on: a database connection string, an admin panel password, and a set of GitHub deployment credentials.

What Azure Key Vault Actually Is

Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely in the cloud. Instead of a password sitting in a configuration file or a public GitHub repository where anyone with read access can see it, the password lives in Key Vault - encrypted, access-controlled, and logged every single time it is read.

Picture your code as a house with see-through walls - anyone looking at the repository can see everything inside, including any password left lying on the kitchen table. Key Vault is a bank vault a few streets away. Your code does not hold the password directly; it holds a key card that lets it walk over and request the password at the exact moment it is needed. Lose the key card, and you still cannot get into the vault without proper identity verification on top of it.

Three Things Key Vault Stores

Secrets are plain string values - passwords, connection strings, API keys, tokens.
Keys are cryptographic keys used for encrypting and decrypting data, or for signing and verifying it.
Certificates are X.509 certificates used for TLS or client authentication between services.
Most applications, including this one, primarily use the Secrets feature.

An Honest Admission About TechStackBlog's Own Setup

This blog does not actually use Key Vault directly today. The database password lives in Azure App Service Configuration. The admin panel password and deployment credentials live in GitHub Secrets. For a single-application personal project, this is a perfectly reasonable and secure setup.

Key Vault earns its place once you have multiple applications that need to share the same secret, once you need automated secret rotation, or once a compliance requirement demands a complete audit trail of every single
read. Understanding when a simpler tool is genuinely sufficient is as much a part of good engineering judgment as knowing how to use the more powerful tool when it is actually warranted.

Setting It Up For Real

Creating a Key Vault starts the same way as any other Azure resource - through the portal, in the same resource group as everything else. Adding a secret is a matter of giving it a name and a value under the Secrets blade.

The access model is where most of the real decisions happen. The modern, recommended approach uses Azure RBAC rather than the older Access Policies model - assign the "Key Vault Secrets User" role to whatever identity needs to read secrets, rather than the much more powerful "Key
Vault Administrator" role, which can also modify access policies and delete the vault entirely. An application that only needs to read a connection string should never hold administrator-level access.

Enabling Managed Identity on the consuming App Service is the final piece - this gives the application its own identity within Azure Active Directory, with no password or client secret to manage at all on the application's side.

The Code That Actually Reads a Secret

After installing the Azure.Identity and Azure.Security.KeyVault.Secrets NuGet packages, reading a secret from C# looks like this conceptually: construct a SecretClient pointed at your vault's URL, authenticate using DefaultAzureCredential, and call GetSecretAsync with the secret's name.

DefaultAzureCredential is the detail that makes this genuinely pleasant to work with rather than painful. It tries several authentication methods in sequence automatically - environment variables for CI/CD contexts, Managed Identity when running inside Azure, then falls back to your local Azure CLI or Visual Studio sign-in when running on your own machine during development. The practical result is that the exact same line of code works identically whether you are debugging locally or running in production App Service. No environment-specific branching, no "if local environment use this connection string, if production use that one."

For even simpler integration, App Service Configuration supports Key Vault references directly - a special value syntax that tells App Service to resolve the actual secret value from Key Vault at startup, using its own Managed Identity, with zero Key Vault SDK code required anywhere in the application at all.

Why Versioning Matters More Than It Sounds

Key Vault never overwrites a secret's value outright - updating a secret creates a new version while preserving every previous version with its own timestamp. Retrieving a secret without specifying a version always returns the current one, but a specific old version remains retrievable by its version identifier if ever needed.

The practical benefit is a built-in safety net. Roll back to a previous secret value instantly if a rotation goes wrong. Maintain a complete history of every value a secret has ever held. Accidentally overwriting a secret with the wrong value becomes a recoverable mistake rather than a permanent one.

Knowing Who Read What, And When

Every read of every secret can be logged automatically by enabling diagnostic settings on the vault and routing those logs into a Log Analytics workspace - the same workspace already used for Application Insights telemetry in a typical setup. From there, a KQL query against the diagnostic logs answers genuinely useful questions: did anyone access this secret outside normal business hours, which specific application is reading this secret and how frequently, and is some old deprecated application still pulling a secret it should no longer have access to at all.

Mistakes Worth Avoiding

Granting Key Vault Administrator when Key Vault Secrets User would suffice is the most common over-permissioning mistake - the application almost never needs to manage access policies or delete the vault, it just needs to read values.

Caching a secret value in application memory indefinitely with no refresh mechanism means that if the underlying secret rotates, the application keeps using the stale value until its next restart. Either set a reasonable cache expiry explicitly or rely on Key Vault references in App Service Configuration, which handle refresh automatically without any extra code.

Storing ordinary, non-sensitive configuration values in Key Vault is a subtler mistake - Key Vault has per-operation rate limits and an associated cost, and a simple page size or feature flag does not need the protection a real secret does. Reserve Key Vault for things that genuinely need secrecy.

Finally, Key Vault has soft-delete enabled by default, meaning deleted secrets remain recoverable for a retention period rather than disappearing instantly. This is usually a helpful safety net, but it also means a vault name cannot always be reused immediately after deletion during that window - worth knowing before it causes unexpected confusion during a rebuild.

Summary

Azure Key Vault exists so that passwords, connection strings, and certificates never have to sit directly inside application code or a public repository. Managed Identity removes the need to manage a credential purely to access your other credentials. Versioning provides a built-in safety net. Diagnostic logging provides real visibility into who is reading what.

None of this is mandatory for every project from day one - but understanding it properly means being able to make a deliberate, informed choice about when a simpler option like App Service Configuration is genuinely enough, and when it is time to bring in the vault.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-key-vault-secrets-management

More from TechStack Blog, by category:
Azure: https://www.techstackblog.com/category.html?cat=azure
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Follow for weekly posts on Azure, C#, and cloud engineering.

C# Async/Await and Delegates/Events: The Concepts Behind Every Responsive Application

Manohari Jayachandran — Fri, 19 Jun 2026 16:27:37 +0000

Every endpoint in the C# API powering my techstackblog uses async/await. Every LINQ query I write is secretly built on delegates. These two concepts are usually taught in separate chapters, but in real production code they constantly overlap - an event handler is often async, and a delegate parameter is often awaited.

This post covers both, with the analogies that made them click for me and the mistakes I see most often in production code.

Part 1 — Async and Await

The Analogy

Imagine ordering food at a restaurant.

A synchronous waiter takes your order, walks to the kitchen, and stands there waiting for your food to finish cooking - completely blocked from serving any other table the entire time.

An asynchronous waiter takes your order, hands it to the kitchen, and immediately goes to serve other tables. When the kitchen finishes, the waiter is notified and brings the food over. One waiter handles many tables efficiently instead of freezing on one slow task.

async/await in C# is that asynchronous waiter. The thread handling your request is not blocked waiting on a slow database call - it gets released to handle other work and resumes once the data is ready.

The Problem It Actually Solves

Without async, a thread that calls a database query sits completely idle for the duration of that call - often 100-300 milliseconds for typical queries. Under load, every concurrent request needs its own thread sitting idle, and you run out of threads fast.

With async, the same thread that started the database call gets returned to the pool immediately after calling await. It goes and handles a different request. When the database responds, the original method resumes often on a different thread entirely. The result is the same hardware handling dramatically more concurrent requests.

Basic Syntax

The async keyword marks a method as asynchronous. The await keyword pauses execution at that point without blocking the thread - it's pausing the method, not the thread. Task represents work that completes at some
point in the future.

A typical async method looks like this: mark the method with async, return Task or Task of some type, and use await wherever you call another async method inside it.

Task vs Task<T> vs async void

Task represents async work with no return value - just a signal of completion. Task<T> represents async work that eventually produces a value of type T. Both of these can be awaited, which is essential.

async void should only be used for actual event handlers - UI button click handlers in WPF or WinForms, for example, which require that exact signature. Outside of event handlers, avoid async void entirely. You cannot await it, which means you cannot know when it completes or catch exceptions it throws. Those exceptions can crash the entire process instead of being caught gracefully.

Running Multiple Async Operations

Sequential awaiting runs operations one after another - if you await three independent calls that each take 100ms, the total wait is 300ms even though none of them depend on each other.

Task.WhenAll runs them concurrently instead. Start all three without awaiting individually, then await Task.WhenAll on all of them together. The total wait becomes roughly the duration of the slowest single operation, not the sum of all three. For any independent async operations, this is a significant and easy performance win.

Common Async Mistakes

The most common mistake is forgetting await entirely - calling an async method without awaiting it returns the Task object itself rather than the data inside it, which is rarely what you want and is an easy typo to miss.

The most dangerous mistake is calling .Result or .Wait() on a Task to force synchronous behavior. This can cause deadlocks in certain contexts, particularly in older ASP.NET applications, and always defeats the entire
purpose of using async in the first place. The fix is simple: await all the way up the call stack rather than blocking partway through.

A subtler mistake is wrapping something in async unnecessarily when there's no actual asynchronous work happening inside - this adds overhead with no benefit.

Part 2 — Delegates and Events

The Analogy

A delegate is like a job posting that describes the exact shape of work needed - "must accept two numbers, must return one number" - without specifying who fills that role. Any method matching that shape can be
plugged in interchangeably.

An event is like a newsletter subscription. The newsletter publisher doesn't know or care who has subscribed. It simply announces "new issue ready" and every subscriber gets notified automatically. The publisher and its subscribers are completely decoupled from each other.

What a Delegate Actually Is

A delegate is a type-safe reference to a method. You define the delegate type once, describing the parameters and return type a matching method must have. Then any method with that exact signature can be
assigned to a variable of that delegate type and invoked through it.

In practice, you almost never declare custom delegate types in modern C#. Three built-in generic delegates cover the overwhelming majority of real-world use:
Func represents a delegate with a return value, Action represents one with no return value, and Predicate always returns a boolean and is typically used for filtering conditions.

Multicast Delegates

A single delegate variable can reference multiple methods at once using the += operator. When invoked, every attached method runs in the order they were added. This is genuinely useful for scenarios like logging the same message to multiple destinations - console, file, and a telemetry service - by combining three separate Action delegates into one.

What an Event Actually Is

An event is essentially a delegate with restricted access. The class that declares the event can raise it, but nothing outside that class can raise it directly - external code can only subscribe or unsubscribe handlers
using += and -=. This protects the publishing class's control over exactly when the notification fires, which is the core difference between a plain delegate field and a proper event.

The standard pattern uses EventHandler or EventHandler<T> as the delegate type, where T is a custom class deriving from EventArgs that carries whatever data subscribers need. Raising the event uses the null-conditional operator before Invoke, which gracefully does nothing if no one has subscribed rather than throwing a null reference exception.

Why Events Instead of Direct Method Calls

Without events, a publishing class needs to know about and directly call every interested party - adding a new subscriber means editing the publisher's code to add another direct call. This tightly couples the publisher to every single consumer of its notifications.

With events, the publisher simply raises the event and has zero knowledge of who is listening or how many subscribers exist. Adding a new subscriber is just one line of subscription code added externally - the publisher class itself never changes. This is loose coupling in its purest practical form.

Events Combined With Async

In real production systems, event handlers are frequently async themselves - an event fires, and the handler needs to do asynchronous work like sending an alert through an external API. This is one of the rare legitimate contexts for async void, since event handler delegate signatures typically can't be changed to return Task.

Where You're Already Using Delegates Without Realizing It

Every LINQ method that takes a lambda is actually accepting a delegate parameter. Where takes a Func<T, bool> - a delegate that takes one item and returns true or false. Select takes a Func<T, TResult> - a delegate that transforms one item into another shape. OrderBy takes a delegate that extracts the sort key. Every single LINQ chain you write is built entirely on the delegate pattern, even though it rarely feels that way while writing it.

ASP.NET Core middleware is built on the same foundation - the next parameter passed into each middleware delegate is itself a delegate pointing to the next piece of middleware in the pipeline.

Key Lessons From Production

Always await all the way up the call stack. Never call .Result or .Wait() on a Task anywhere in application code.
Use Task.WhenAll whenever you have multiple independent async operations it's an easy, safe performance improvement that's frequently overlooked.
Prefer the built-in Func, Action, and Predicate delegate types over declaring custom delegate types. Custom delegates are rarely necessary in modern C#.
Use the null-conditional invoke pattern when raising events - it prevents a null reference exception in the common case where no one has subscribed yet.
Reserve async void exclusively for actual event handler signatures. Everywhere else, use async Task so exceptions propagate correctly and the work can be awaited.
Recognizing that every LINQ lambda is secretly a delegate makes the entire LINQ API click faster - it stops feeling like special syntax and starts feeling like an extension of something you already understand.

Summary

Async/await keeps applications responsive by releasing threads during slow operations instead of blocking them, allowing far more concurrent work on the same hardware.
Delegates provide type-safe references to methods, letting behavior be passed around as data. Events build on delegates to create loosely coupled systems where publishers and subscribers never need direct knowledge
of each other.

Together, these two concepts are the backbone of responsive, maintainable C# applications - showing up everywhere from REST API controllers to UI event handlers to the LINQ queries written dozens of times a
day without a second thought.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=csharp-async-delegates-events-deep-dive

More from the same blog, organized by topic:

Azure: https://www.techstackblog.com/category.html?cat=azure
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
Web fundamentals: https://www.techstackblog.com/category.html?cat=web
Database: https://www.techstackblog.com/category.html?cat=database

Follow for weekly posts on C#, Azure integration, and cloud engineering.

CI/CD, YAML, Azure DevOps and Merge Conflicts: Everything I Learned Deploying to Azure

Manohari Jayachandran — Wed, 17 Jun 2026 17:11:02 +0000

My first production deployment at Blue Yonder was entirely manual. Copy files to the server. Update the config by hand. Restart the service. Call the team to verify it was live. The whole process took 45 minutes, produced a slightly different result every time depending on who ran it, and only two people on the team knew all the steps.

Then we moved to automated pipelines. The same deployment became: push code to Git, wait 4 minutes, done. Same result every single time. Anyone on the team could trigger it. Full audit log of every deployment. Rollback in one command.

CI/CD is not a nice-to-have for serious software delivery. It is the foundation. This post covers everything — YAML syntax, GitHub Actions, Azure DevOps, deployment strategies, merge conflicts, and the security practices that keep pipelines safe.

CI vs CD — The Actual Difference

Most people use CI/CD as one term without knowing where one ends and the other begins.

Continuous Integration is about merging code frequently and automatically verifying it. Every time a developer pushes code, the CI system builds it and runs tests. The goal is to catch problems immediately — within minutes of the bad code being merged, not days later when someone manually tests the feature.

Continuous Deployment takes the verified build from CI and automatically deploys it to one or more environments. Continuous Delivery deploys automatically to staging but requires a human to approve the production deployment. Continuous Deployment goes all the way to production automatically with no human approval.

A complete pipeline looks like this:

Code pushed -> Build -> Unit tests -> Integration tests
-> Deploy to dev -> Deploy to staging -> Manual approval
-> Deploy to production.

TechStack Blog uses a simplified version of this — every push to main builds the C# API, publishes it, and deploys to Azure App Service automatically. No staging environment for a solo blog project, but the same principles apply.

YAML — The Language of Pipelines

YAML (Yet Another Markup Language) is the format used by GitHub Actions, Azure DevOps, and almost every modern CI/CD tool. It uses indentation to show structure and is readable as plain text.

The critical rule: indentation must be consistent and use spaces, never tabs. One wrong indent and the pipeline fails with a cryptic error.

The basic structure of any pipeline has three parts.
The trigger defines when the pipeline runs — on push, on pull request, on a schedule, or manually.
The jobs define what machines do the work and in what order.
The steps define the individual commands each machine runs.

Lists use a dash at the start of each item.
Objects use key-value pairs with a colon.
Nested structure uses consistent indentation.
Secrets and variables are referenced with double curly braces.

Understanding these four rules lets you read any YAML pipeline file regardless of which CI/CD platform wrote it.

GitHub Actions

GitHub Actions is CI/CD built directly into GitHub. Every workflow is a YAML file stored in the .github/workflows/ folder of your repository. When the trigger condition is met — a push, a PR, a schedule — GitHub spins up a fresh virtual machine, runs your steps, and tears the machine down when done.

The TechStack Blog API deployment workflow does eight things in sequence.

It checks out the repository code.
It installs the .NET 8 SDK.
It restores NuGet packages.
It builds the C# project in Release mode.
It runs tests.
It publishes the output to a folder.
It zips that folder.
It logs into Azure using service principal credentials stored as GitHub Secrets and deploys the zip to Azure App Service.

The entire process takes 3-4 minutes. Every push to main triggers it automatically.

The most important concept in GitHub Actions is job dependencies. The deploy job has "needs: build" which means it only runs if the build job succeeds. If the build fails the deployment never happens. This prevents
broken code from reaching Azure.

Secrets in GitHub Actions are stored encrypted and never appear in logs. They are referenced with the ${{ secrets.SECRET_NAME }} syntax. The Azure service principal credentials — client ID, tenant ID, and subscription ID — are stored as secrets so they never appear in the YAML file that is publicly visible in the repository.

Azure DevOps Pipelines

Azure DevOps is Microsoft's enterprise CI/CD platform. It has more features than GitHub Actions and is the standard in large organizations. At Blue Yonder, Azure DevOps managed our integration platform deployments
across multiple environments with formal approval workflows.

The key difference from GitHub Actions is the concept of stages with environments. You define a Production environment in Azure DevOps and configure it to require approval from specific people before any deployment can proceed. When the pipeline reaches the production stage, it pauses and sends an email to the approvers. Only after someone clicks Approve does the deployment continue.

This is the approval gate pattern — critical for any system where a bad deployment has real consequences. GitHub Actions has similar functionality through Environment protection rules, but Azure DevOps makes it more prominent and easier to configure for teams.

Azure DevOps also has variable groups — shared sets of variables that multiple pipelines can reference. Instead of duplicating the same connection string in ten different pipeline files, you define it once in
a variable group and all pipelines inherit it. When the value changes, you update it in one place.

Manual vs Automated Deployment

Automated deployment is the goal but manual deployment has its place. Know when to use each.

Automate everything that runs repeatedly and must produce identical results every time. Application code, configuration changes, dependency updates — these all belong in automated pipelines.

Keep manual control over things that require judgment. Database schema migrations that could lose data. First-time infrastructure provisioning with Terraform or Bicep. Emergency hotfixes that are faster to deploy manually than waiting for a pipeline. Deployments that require physically touching hardware.

The hybrid approach that works in practice: code deployments are fully automated, database migrations are automated with a manual approval step, infrastructure changes are manual with documentation, and production releases require a pipeline approval gate even though the deployment itself is automated.

Deployment Strategies

Blue-Green deployment runs two identical environments. Traffic goes to the blue environment (live). You deploy to the green environment (idle) and test it. When ready, you switch all traffic to green in seconds. Blue becomes the instant rollback target. Azure App Service deployment slots implement this pattern directly — swap slots to go live, swap back to roll back.

Canary deployment sends a small percentage of traffic to the new version first. Start at 5%, monitor for errors, increase to 25%, then 50%, then 100%. If errors appear at any stage, roll back the canary percentage.
Real users test the new version but only a small fraction of them are exposed to any problems.

Rolling deployment updates one server at a time while the others keep serving traffic. No downtime but slower to roll back — you have to wait for the rolling update to complete in reverse.

For a single-server deployment like TechStack Blog, the simplest strategy is stop, replace, start. Acceptable for a blog. Not acceptable for a system that needs zero downtime.

Merge Conflicts

A merge conflict happens when two developers change the same line of the same file and Git cannot automatically decide which change to keep. This is the moment most new developers dread. Once you understand it, conflicts
are completely manageable.

The scenario: main branch has a function returning "Hello". Developer A changes it to "Hello World" and merges first. Developer B changes the same line to "Hi there" and tries to merge. Git sees both changed the same line and does not know which version is correct. Git marks the file and asks you to decide.

What Git puts in the file:


<<<<<<< HEAD
your version of the code here
=======
their version of the code here
>>>>>>> their-branch-name

Everything between the less-than signs and the equals signs is your version. Everything between the equals signs and the greater-than signs is their version.

To resolve: delete both markers, keep whichever code is correct (or combine both), save the file, run git add on the resolved file, then git commit to complete the merge.

VS Code shows conflict markers with clickable buttons — Accept Current Change, Accept Incoming Change, Accept Both Changes. Click the appropriate button, VS Code removes the markers automatically, save and commit.

Preventing Merge Conflicts

Pull before you push every single time. This one habit eliminates the majority of conflicts by keeping your local branch close to the current state of main.

Commit small and commit often. Large commits that change many files across many features create maximum overlap with other developers' work. Small focused commits targeting specific files create minimum overlap.

Keep feature branches short-lived. Branches that live for weeks diverge significantly from main and produce massive conflicts when merged. Aim for branches that live 1-3 days and get merged back through a pull request.

Communicate about shared files. When you know you are making significant changes to a file that others also work in, mention it to the team. Simple coordination prevents most serious conflicts.

Branch Strategies

GitFlow uses long-lived branches for different purposes.

A main branch contains only production-ready code.
A develop branch is the integration point where features are merged before going to production.
Feature branches come off develop and merge back into develop.
Release branches prepare for a production deployment.
Hotfix branches patch production issues directly.

This maps cleanly to CI/CD: develop branch triggers deployment to the dev environment, release branch triggers staging deployment, main branch triggers production deployment with approval.

Trunk-Based Development keeps almost everything in one branch — main (or trunk). Feature branches exist but are short-lived, typically 1-3 days maximum. Feature flags control what users see rather than long-lived branches. Every merge to main can safely deploy to production. This is the approach modern engineering teams use when they want to deploy multiple times per day.

TechStack Blog uses simplified trunk-based: one main branch, everything deploys automatically. Works perfectly for a solo developer project.

Pipeline Security

Never put actual values for secrets in YAML files. A YAML file in a public GitHub repository is visible to everyone. Any secret in that file is compromised the moment you commit it. Use ${{ secrets.NAME }} and
store the actual value in GitHub Secrets or Azure DevOps variable groups.

Pin your action versions. Using actions/checkout@main means your pipeline uses whatever version is current at the time it runs. That version can change without warning and silently break your pipeline or introduce malicious code. Use actions/checkout@v4 for a specific
stable version.

Give your service principal the minimum permissions it needs to deploy. If the pipeline only needs to deploy to one App Service, its Azure role should only allow that — not manage billing, not delete resources, not
create new services.

Use environment protection rules for production. In GitHub Settings, create a Production environment and require one or more specific people to approve before any deployment can proceed.

Key Lessons From Production

Set up CI/CD before writing business logic. Retrofitting a pipeline into an existing project is significantly harder than building it alongside the first commit. The TechStack Blog pipeline was configured on day one.
Keep pipelines fast. If building and deploying takes more than 10 minutes, developers stop waiting for results and start pushing anyway. Cache dependencies, run tests in parallel, and skip unnecessary steps.
Test your rollback before you need it. A rollback plan you have never practiced is not a plan. Every team should do a rollback drill in staging at least once per quarter.
Never let a broken pipeline stay broken. A broken pipeline is ignored. An ignored pipeline means changes go unverified. Fix pipeline failures immediately — treat them with the same urgency as a production outage.

Summary

CI/CD automates the path from code to running software. YAML defines the pipeline steps in a readable, version- controlled format. GitHub Actions brings CI/CD directly into your GitHub workflow with zero additional tooling. Azure DevOps adds enterprise approval gates and environment management for organizations that need them. Merge conflicts are a normal part of collaborative development — understand the markers, resolve deliberately, prevent through good habits. Together these practices make deployment reliable, repeatable, and safe.

The TechStack Blog goes from git push to live in 4 minutes automatically, every time, with no manual steps. That is what CI/CD is for.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=cicd-yaml-azure-devops-deep-dive

Follow for weekly posts on Azure, C#, DevOps, and cloud engineering.

C# Lambda Expressions and LINQ: The Two Features That Changed How I Write Code

Manohari Jayachandran — Mon, 15 Jun 2026 14:48:23 +0000

When I first started writing C# I used foreach loops for everything. Filter a list — foreach loop. Find one item — foreach loop. Transform every element — foreach loop. The code worked but it was verbose, repetitive, and hard to read at a glance.

Lambda expressions and LINQ changed everything. The same operations became one line. The intent became immediately readable. And when I started using Entity Framework Core to query Azure SQL in the TechStack Blog API, LINQ became the way I wrote every single database query without touching raw SQL.

These are not beginner concepts you learn once and forget. They are the foundation of every modern C# codebase. This post covers both deeply — with analogies, real code, and the mistakes that only become clear in production.

Part 1 — Lambda Expressions

The Analogy

Think of a regular method like a full recipe card with a name, an ingredients list, and step-by-step instructions. You write it once, give it a name, and call it by name whenever you need it.

A lambda expression is like a sticky note with a quick instruction written on it — no name, used once right where you need it, then gone. It is a method without a name, written inline exactly where it is used.

What a Lambda Expression Is

A lambda expression has two sides separated by the => arrow operator (pronounced "goes to"):

Left side: the input parameter
Right side: the expression that returns a value

So post => post.IsPublished reads as:
"given a post, return whether IsPublished is true"

The equivalent named method would be:

public bool IsPublished(Post post)
{
    return post.IsPublished == true;
}

The lambda is not better or worse — it is shorter and used inline rather than declared separately and called by name.

Lambda Syntax Types

Expression lambda for a single expression:

x => x * 2

Statement lambda for multiple lines:

x =>
{
    var doubled = x * 2;
    return doubled;
}

No parameters use empty parentheses:

() => DateTime.UtcNow

Multiple parameters use parentheses:

(x, y) => x + y

Func and Action

Lambdas can be stored in variables using two built-in delegate types.

Func has a return value. Func takes the input types first and the return type last:

Func<int, int> doubler = x => x * 2;

Action has no return value (void):

Action<string> printer = message => Console.WriteLine(message);

Once stored in a variable, you call them like regular
methods: doubler(5) returns 10, printer("Hello") prints Hello.

Closures — Captured Variables

Lambdas can capture variables from the surrounding scope. This is called a closure and it is both powerful and a source of subtle bugs.

string techFilter = "Azure";
var azurePosts = posts.Where(p => p.Tech == techFilter);

The lambda captures techFilter from the outer scope. It remembers the variable — not a copy of its value at the time of capture, but the variable itself. If techFilter changes before the lambda executes, the lambda sees the new value.

The classic bug is closures in loops. When you create a lambda inside a loop and use the loop variable, all lambdas end up referencing the same variable — which has its final value after the loop ends. Fix it by capturing a copy:

for (int i = 0; i < 3; i++)
{
    int captured = i; // capture a copy of i right now
    actions.Add(() => Console.WriteLine(captured));
}

Without the int captured = i line, all three lambdas print the same final value of i. With it, each captures its own copy and prints 0, 1, 2 as expected.

Part 2 — LINQ

The Analogy

LINQ is SQL for your C# collections. Just as SQL lets you query a database with SELECT, WHERE, ORDER BY and GROUP BY — LINQ lets you query any list, array, or collection in C# using the same concepts but in C# syntax.

The magic is that LINQ works on everything — in-memory lists, Entity Framework database queries, XML documents, JSON collections. The same syntax, completely different data sources.

Two Syntax Styles

Method syntax uses dot chaining and is the most common in modern C#:

var result = posts
    .Where(p => p.IsPublished)
    .OrderByDescending(p => p.CreatedAt)
    .Select(p => p.Title)
    .ToList();

Query syntax looks like SQL and reads naturally for developers coming from a database background:

var result2 =
    (from p in posts
     where p.IsPublished
     orderby p.CreatedAt descending
     select p.Title)
    .ToList();

Both produce identical results. Method syntax is more flexible and more commonly written in production code. Query syntax can be easier to read or complex joins.

The Essential LINQ Methods

Where filters elements — keeps only those where the predicate returns true:

posts.Where(p => p.IsPublished)
posts.Where(p => p.Tech == "Azure" && p.ReadingTime > 10)

Select transforms each element — projects to a new shape:

posts.Select(p => p.Title)
posts.Select(p => new { p.Title, p.Excerpt })

OrderBy and OrderByDescending sort the results:

posts.OrderBy(p => p.Title)
posts.OrderByDescending(p => p.CreatedAt)

FirstOrDefault finds one element safely — returns null if nothing matches rather than throwing an exception:

posts.FirstOrDefault(p => p.Slug == "my-post")

Always use FirstOrDefault over First in production. Production data is never as clean as you expect and First throws when nothing matches.

Any and All return booleans:

posts.Any(p => p.Tech == "Azure") — true if at least one
posts.All(p => p.IsPublished) — true if every single one

Count with a predicate counts matching elements:

posts.Count(p => p.Tech == "Azure")

Take and Skip enable pagination:

posts.Skip((page - 1) * pageSize).Take(pageSize)

GroupBy groups elements by a key:

posts.GroupBy(p => p.Tech)
     .Select(g => new { Tech = g.Key, Count = g.Count() })

Deferred Execution — The Most Important Concept

This is the source of most LINQ bugs and the concept that trips up even experienced developers.

LINQ queries do not execute when you define them. They execute when you iterate the results.

var query = posts.Where(p => p.Tech == "Azure");
// Nothing has happened yet. No filtering. No looping.

var list = query.ToList();
// NOW the query executes. The filtering happens here.

The practical implication is that data can change between when you define a query and when you execute it. If you add a new Azure post after defining the query but before calling ToList, the new post appears in the results.

With Entity Framework Core, deferred execution means no SQL is generated until you call ToListAsync, FirstOrDefaultAsync, CountAsync, or any other materializing method. This is why every EF Core query ends with one of these calls.

The Most Important Performance Rule

Never call ToList before Where.

This loads your entire database table into memory as a C# list, then filters in C# instead of in SQL. For a table with a million rows this is catastrophic.

Always filter first, materialize last:

Wrong: _context.Posts.ToList().Where(p => p.Tech == "Azure")
Right: _context.Posts.Where(p => p.Tech == "Azure").ToList()

The right version generates a SQL WHERE clause and only returns matching rows from the database. The wrong version loads every row then throws most of them away in memory.

LINQ with Entity Framework Core

This is where LINQ becomes truly powerful. Every LINQ query on a DbSet translates to SQL that runs against your database. You never write raw SQL for standard operations.

The query that powers the TechStack Blog API homepage:

var posts = await _context.Posts
    .AsNoTracking()
    .Where(p => p.IsPublished)
    .OrderByDescending(p => p.CreatedAt)
    .Select(p => new PostDto {
        Id = p.Id,
        Title = p.Title,
        Slug = p.Slug,
        Tech = p.Tech
    })
    .ToListAsync();

EF Core translates this to:

SELECT Id, Title, Slug, Tech
FROM Posts
WHERE IsPublished = 1
ORDER BY CreatedAt DESC

AsNoTracking tells EF Core this is read-only — it skips change tracking and significantly improves performance for queries that will not update data.

Selecting into a DTO inside the query means only the columns you need come from the database. Without the Select, EF Core fetches every column even if you only use two of them.

GroupBy in Practice

GroupBy is the most underused LINQ method. It replaces entire blocks of code that build dictionaries manually with a clean readable pipeline.

Before GroupBy (old style):

var techCounts = new Dictionary<string, int>();
foreach (var post in posts)
{
    if (!techCounts.ContainsKey(post.Tech))
        techCounts[post.Tech] = 0;
    techCounts[post.Tech]++;
}

After GroupBy:

var techCounts = posts
    .GroupBy(p => p.Tech)
    .ToDictionary(g => g.Key, g => g.Count());

Both produce the same dictionary. The GroupBy version is four lines shorter and immediately readable.

SelectMany — Flattening Nested Collections

SelectMany is LINQ's way of flattening a collection of collections into one flat collection.

If each post has a list of tags, SelectMany gives you all tags from all posts as one flat list:

var allTags = posts
    .SelectMany(p => p.Tags)
    .Select(t => t.Name)
    .Distinct()
    .OrderBy(n => n);

Without SelectMany you would need a nested foreach loop to collect all tags from all posts. SelectMany does it in one step.

Key Lessons From Production

Use FirstOrDefault not First everywhere. First throws an exception when nothing matches. In production data is messy and things that should always exist sometimes do not.
Put ToList or ToListAsync at the very end. Deferred execution means the query runs where you materialize the results. Moving ToList earlier changes where the work happens and usually for the worse.
Use AsNoTracking for every read-only query. EF Core tracks every object it loads by default so it can detect changes. For queries where you will never update the data this is wasted overhead. AsNoTracking is a free performance improvement.
Learn GroupBy deeply. Once you see how it replaces manual dictionary building the pattern appears everywhere and you will use it constantly.
Understand the closure-in-loop bug before using lambdas in loops. It does not come up every day but when it does and you do not know about it the debugging is genuinely confusing.

Summary

Lambda expressions give you unnamed inline functions that make code shorter and more expressive. LINQ gives you a consistent query language that works on any collection — lists, arrays, databases, XML. Together
they are the two features that separate readable modern C# from verbose loop-heavy code.

Every endpoint in the TechStack Blog API uses both. The database queries are LINQ. The data transformations are lambdas with Select. The filtering is Where with lambda predicates. Master these two concepts and every other C# pattern becomes easier to understand and implement.

Originally published at TechStack Blog:
https://calm-island-0a7b4b30f.7.azurestaticapps.net/post.html?slug=csharp-lambda-linq-deep-dive

Follow for weekly posts on C#, Azure integration, and cloud engineering.

Azure Application Insights: Monitoring, KQL Queries and Observability in Production

Manohari Jayachandran — Sat, 13 Jun 2026 15:19:42 +0000

At 2am on a Tuesday, an IP address change in Microsoft infrastructure silently broke our entire integration pipeline at Blue Yonder. Messages stopped flowing between Salesforce and ServiceNow. No errors surfaced in the application logs. The systems reported themselves as healthy. But nothing was moving.

It was Azure Application Insights that found it.

The Application Map showed 100% failure rate on the Service Bus node. I clicked the connection line. Saw connection refused errors on the dependency calls. Traced the root cause to the IP change within minutes.
I wrote a Logic App to inspect the dead-letter queue and replay every failed message. Zero data loss. Zero SLA breach.

That incident shaped how I think about observability forever. App Insights is not a monitoring tool you add at the end. It is the foundation you build everything on from day one.

This post covers everything I learned using App Insights in production - the queries, the alerts, the patterns, and the lessons that only come from real incidents.

What App Insights Collects Automatically

The first thing that surprises most engineers is how much App Insights collects with zero configuration. Add one NuGet package and one line in Program.cs and you immediately get:

Every HTTP request your API receives - the URL, method, response code, duration, and whether it succeeded.

Every dependency call your app makes outbound - SQL queries, HTTP calls to external APIs, Service Bus operations, Blob Storage reads. Each one tracked with duration and success status.

Every unhandled exception with the full stack trace, the exact line of code that failed, and all exception properties including inner exceptions.

Every log message you write with ILogger - Information, Warning, Error levels all captured with custom properties.

Performance counters including CPU usage, memory consumption, and request queue length collected automatically on App Service.

Setting It Up in C# ASP.NET Core

Three steps and you are done.

Install the NuGet package:
Microsoft.ApplicationInsights.AspNetCore
Add one line in Program.cs:
builder.Services.AddApplicationInsightsTelemetry(
builder.Configuration["ApplicationInsights:ConnectionString"]
);
Add the connection string to appsettings.json or
Azure App Service Configuration (never hardcode it).

That is it. Every ILogger call in your code now goes to App Insights automatically. No code changes needed in your controllers or services.

For custom events and metrics - tracking business-level events beyond technical telemetry - inject TelemetryClient and call TrackEvent() with a name and custom properties. I used this at Blue Yonder to track every integration completion with the system name and record count as
properties, so I could query processing volumes by system over time.

KQL - The Query Language That Changes Everything

KQL (Kusto Query Language) is what makes App Insights powerful rather than just a log viewer. It reads left to right with pipe operators - each step filters or transforms the result of the previous step.

The basic structure is always the same:
Start with a table name, then pipe through operators like where, project, summarize, order by, and extend.

Once you understand five queries you can write almost any investigation query you need. Here are the five I used most in production:

All failed requests in the last hour:

requests
| where timestamp > ago(1h)
| where success == false
| project timestamp, name, url, resultCode, duration
| order by timestamp desc

This was my first query every morning and after every deployment. If it returned rows, I had work to do.

Slowest API endpoints today:

requests
| where timestamp > ago(24h)
| summarize AvgDuration = avg(duration), Count = count() by name
| order by AvgDuration desc
| take 10

This identified performance regressions immediately after deployments before customers reported them.

All exceptions with full detail:

exceptions
| where timestamp > ago(4h)
| project timestamp, type, outerMessage, innermostMessage, method
| order by timestamp desc

The innermostMessage field is the one you want - it has the root cause, not the wrapper exception.

Dependency failures - what external calls failed:

dependencies
| where timestamp > ago(1h)
| where success == false
| project timestamp, type, target, name, duration, resultCode
| order by timestamp desc

This was how I found the Microsoft IP change. Service Bus dependencies all showing connection refused, all starting at the same timestamp.

Error rate by hour - spot patterns:

requests
| where timestamp > ago(24h)
| summarize Total=count(), Failed=countif(success==false) by bin(timestamp,1h)
| extend ErrorRate = round(Failed*100.0/Total, 2)
| order by timestamp asc

This chart pattern shows you whether failures are random noise or a systematic problem getting worse.

The Queries I Wrote at Blue Yonder

Beyond the standard queries, I built several patterns specific to integration monitoring that I have not seen documented elsewhere.

Cross-system correlation - following one record through every system it touched. Every request in our pipeline carried a CorrelationId custom property. With this query I could trace a single Salesforce case through Logic App orchestration, Function App transformation, Service Bus
messaging, and the final ServiceNow API call - seeing exact timestamps and durations at each step:

union requests, dependencies, traces, exceptions
| where timestamp > ago(24h)
| where tostring(customDimensions["CorrelationId"]) == "your-id"
| project timestamp, itemType, name, message, duration, success
| order by timestamp asc

Token refresh monitoring - tracking the 3-month Salesforce and 6-month ServiceNow credential refresh cycles that were a significant operational risk before I centralized them in Key Vault:

customEvents
| where name == "TokenRefreshed"
| extend System = tostring(customDimensions["System"])
| summarize LastRefresh=max(timestamp), SuccessCount=countif(tobool(customDimensions["Success"])==true) by System

Integration pipeline health - the Monday morning query that showed overnight processing status for every integration flow:

requests
| where timestamp > ago(12h)
| where name contains "Integration"
| summarize Success=countif(success==true), Failed=countif(success==false), AvgDuration=avg(duration) by name
| extend Status = iff(Failed > 0, "DEGRADED", "HEALTHY")
| order by Status asc

Smart Alerts - Stop Watching Dashboards

The real power of App Insights is alerts that find problems for you.

Metric alerts fire when a number crosses a threshold - failed requests greater than 5 in 5 minutes, response time average greater than 2 seconds, exception count greater than 10 per hour.

Log alerts run a KQL query on a schedule and fire if the results meet a condition. This is how I monitored the dead-letter queue - a query that ran every 5 minutes and fired immediately if any messages appeared in the DLQ. In production, a non-empty DLQ is always a signal that
something needs investigation.

Smart detection requires no configuration. App Insights learns your baseline automatically and alerts on anomalies - unusual failure rate spikes, abnormal response time degradation, memory leak patterns.
It caught two issues at Blue Yonder that I would not have noticed from metrics alone.

Live Metrics During Deployments

Live Metrics shows you what is happening with less than one second latency - incoming requests per second, exception rate, dependency call rate, CPU and memory of every running instance.

I had Live Metrics open on a second monitor during every production deployment. If the exception rate spiked within 30 seconds of a deploy I knew immediately to roll back. If it stayed flat for 2 minutes the deployment was clean.

This practice caught one bad deployment at Blue Yonder that would have caused a production incident if we had waited for customer reports. The rollback took 90 seconds. The alternative would have been hours of incident response.

Application Map

The Application Map is the fastest way to understand what broke and where. It shows every component of your system as a node - your API, the SQL database, Service Bus, external APIs - with connection lines showing call volume and failure rate between them.

When the Microsoft IP change broke our pipeline, the Service Bus node on the Application Map turned red with a 100% failure rate. I clicked the connection line between our API and Service Bus. The details pane
showed connection refused with the target IP address. That one click saved 30 minutes of log digging.

Distributed Tracing

Every request in App Insights gets a unique Operation ID that flows automatically through every system it touches. A single user request that goes through APIM, Logic App, Function App, Service Bus, and SQL - all with the same Operation ID.

In Transaction Search, paste the Operation ID and see every step in chronological order with exact timestamps and durations. The full story of one request across your entire distributed system in one view.

The practical implication for code: add a CorrelationId to your custom log entries and custom events. Then you can find every log entry related to one business transaction even when it crosses system boundaries.

Connecting App Insights Across the Azure Stack

App Insights works with every Azure service. Logic Apps through diagnostic settings send all run history to the same Log Analytics workspace you query with KQL. Function Apps with AddApplicationInsightsTelemetry()
track every function execution automatically. APIM connected to App Insights logs every API call with the caller's subscription key. Service Bus diagnostic settings expose message counts and DLQ depth as metrics.

The goal is one workspace where you can query across all these data sources simultaneously. When an incident spans multiple systems - which in integration work they always do - you want one place to look, not five dashboards.

Key Lessons From Production

Set up App Insights before you write business logic. Retrofitting observability into an existing system is ten times harder than building it in from the start.
Use structured logging with named parameters. log.LogInformation("Processing {OrderId}", order.Id) is infinitely more queryable than string concatenation. The named parameter becomes a filterable field in KQL.
Add CorrelationId to everything. Every log entry, every custom event, every Service Bus message property. Cross-system tracing without it is guesswork.
Learn five queries well rather than memorizing dozens. The queries in this post covered 90% of every real incident investigation I ran at Blue Yonder.
Set DLQ alerts before going live. Silent message loss in a Service Bus integration is the hardest production bug to diagnose after the fact. The alert costs 5 minutes to set up. The incident it prevents costs days.
Enable sampling in production. A busy integration platform generates GBs of telemetry per day at full collection. Adaptive sampling preserves all errors and exceptions while reducing successful request volume to stay within cost limits.

App Insights in the TechStack Blog

The C# ASP.NET Core API powering this blog has App Insights enabled. Every visit to techstackblog.com that triggers an API call is tracked - the request duration, the SQL query to Azure SQL, any exceptions. The connection string lives in Azure App Service Configuration, not in the code or GitHub.

If you are reading this post and wondering whether it is being monitored - it is.

Summary

Azure Application Insights gives you complete visibility into every layer of your Azure stack. Automatic telemetry collection means zero-config coverage from day one. KQL gives you the ability to answer any question about your system's behavior. Smart alerts find problems before your customers do. Application Map shows you what broke. Distributed tracing shows you why.

Build it in from day one. Set your alerts. Learn your five queries. Then stop firefighting and start preventing.

Originally published at TechStack Blog:
https://calm-island-0a7b4b30f.7.azurestaticapps.net/post.html?slug=azure-app-insights-deep-dive

Follow for weekly posts on Azure integration, C#, observability, and cloud engineering.

Azure Function Apps in C#: Triggers, Bindings, Durable Functions and Everything I Learned in Production

Manohari Jayachandran — Thu, 11 Jun 2026 12:24:40 +0000

Azure Function Apps are a serverless compute service that runs small focused pieces of C# code in response to events. You write a function, deploy it to Azure, and it runs only when triggered — paying only for the milliseconds it actually executes, not for a server sitting idle 24 hours a day.
I used Function Apps at Blue Yonder as the transformation and processing layer in our integration pipelines. Logic Apps handled orchestration, Service Bus handled messaging, and Function Apps handled the complex C# logic that was too sophisticated for Logic App expressions.

Function App vs Logic App vs API Management
This is the question every Azure engineer faces. Here is the honest answer:
Use Function Apps when you need complex C# business logic, custom data transformation algorithms, high performance compute, or reusable code components across multiple pipelines.
Use Logic Apps when you are connecting existing services visually, the workflow has clear sequential steps, or you need one of the 500+ built-in connectors.
Use API Management when exposing APIs to external consumers, applying rate limiting and authentication, or managing API versioning and documentation.
The real answer for enterprise integrations is use all three together. APIM as the front door, Logic App as the orchestrator, Function App for complex transformations, Service Bus for reliable messaging between them. This is exactly the pattern I built at Blue Yonder.

The Six Trigger Types
A trigger is what causes your function to run. Every function must have exactly one trigger.

HTTP Trigger runs when an HTTP request arrives. Use for REST APIs, webhooks, and callbacks from external systems.
Timer Trigger runs on a schedule using a CRON expression. Use for nightly jobs, hourly reports, and cleanup tasks. The expression "0 0 2 * * *" runs at 2am every day.
Service Bus Trigger runs when a message arrives on a queue or topic subscription. This was my most used trigger at Blue Yonder. It automatically handles retries and dead lettering — your function completing successfully means the message is completed, throwing an exception means it gets retried.
Blob Storage Trigger runs when a file is uploaded to Azure Blob Storage. Use for image processing, file transformation, and document parsing.
Queue Storage Trigger runs when a message arrives in an Azure Storage Queue. Good for simple high-volume task processing at the lowest cost.
Event Grid Trigger runs when an Azure event occurs — like a new user created in Azure AD or a resource deployed in your subscription. Use for reacting to platform-level events.

Input and Output Bindings
Bindings are the most underused feature of Function Apps. They connect your function to other Azure services without writing any connection boilerplate code.
An input binding reads data into your function automatically. An output binding writes data out of your function automatically. You declare what you need in the function signature and Azure handles the connections.
Instead of writing 20 lines of SQL connection code to read a record, you add one attribute to your parameter and Azure injects the data directly. Instead of writing Service Bus SDK code to send a message, you add an output binding and just call AddAsync with your object.
This eliminates entire classes of connection bugs and makes functions dramatically easier to read and test.

Durable Functions — Long Running Workflows
Regular functions run for a maximum of 10 minutes on the Consumption plan. Durable Functions solve this with a pattern that can run for hours, days, or even months.
There are three function types. The Orchestrator coordinates the workflow — calling activity functions in sequence or parallel, handling retries and timeouts, with state automatically checkpointed so it survives restarts. The Activity does the actual work — calling external APIs, querying databases, sending messages. The Client starts the workflow, usually via an HTTP trigger, and returns an instance ID for status checking.
I used Durable Functions at Blue Yonder for integration flows that needed to wait for external system responses — start the flow, call ServiceNow, wait up to 24 hours for a callback, then continue processing. Without Durable Functions this required complex custom state management. With them it was straightforward orchestration code.

Connecting to Azure Key Vault
Never hardcode connection strings in your function code. Use Key Vault references in your application settings instead.
In the Azure Portal under your Function App Configuration, add an application setting with a Key Vault reference as the value. Azure resolves the reference automatically at runtime — your code just reads the setting name as a normal environment variable. Enable Managed Identity on your Function App and grant it the Key Vault Secrets User role. No passwords anywhere in code or config files, ever.

Hosting Plans — Which to Choose
The Consumption plan charges per execution at roughly $0.20 per million calls. It auto-scales automatically but has a 10 minute timeout and 1-3 second cold starts on first call. Perfect for unpredictable traffic and low volume workloads.
The Premium plan costs around $140 per month minimum but eliminates cold starts with pre-warmed instances, has no timeout limit, and supports VNet integration. Use this for production customer-facing functions where latency matters.
The Dedicated plan runs on an existing App Service plan. Use this when you already have App Service infrastructure and want consistent predictable load without the serverless cold start behavior.

Key Lessons From Production

Always use Managed Identity and Key Vault — never hardcode connection strings anywhere.
Service Bus trigger is more reliable than HTTP for processing integration messages — it handles retries, dead lettering, and message locking automatically.
Use Durable Functions for any workflow that might run longer than 10 minutes or needs to wait for external callbacks.
Premium plan eliminates cold starts for customer-facing functions — the Consumption plan cold start is acceptable for background processing but not for real-time user requests.
Keep functions small and focused — one function should do one job. If your function is doing three things, split it into three functions.
Always add local.settings.json to your .gitignore file — it contains your local connection strings and must never be committed to GitHub.

The Complete Azure Integration Stack
This is the architecture that handles enterprise-scale integrations reliably:
External requests enter through Azure API Management which handles authentication, rate limiting, and routing.
Logic Apps orchestrate the business workflow using built-in connectors. Azure Service Bus provides reliable messaging between components with dead letter queues for failures.
Function Apps handle complex C# transformation logic that Logic Apps cannot express.
Azure SQL Database provides persistent storage.
Application Insights monitors every step of the entire stack automatically.
Each layer has one responsibility. No layer does what another layer is designed for. This separation is what makes the architecture maintainable and debuggable at scale.

Summary
Azure Function Apps are the C# powerhouse of the Azure integration stack. Serverless execution means zero infrastructure management. Six trigger types connect to every Azure service. Bindings eliminate boilerplate connection code. Durable Functions handle complex long-running workflows.
Combined with Logic Apps for orchestration, Service Bus for messaging, and APIM for the front door — Function Apps complete the enterprise integration toolkit on Azure.

Originally published at TechStack Blog — https://calm-island-0a7b4b30f.7.azurestaticapps.net/post.html?slug=azure-function-apps-deep-dive
Follow for weekly posts on Azure integration, C#, and cloud engineering.

Azure API Management: Gateway, Policies, Authentication and Everything I Learned in Production

Manohari Jayachandran — Wed, 10 Jun 2026 21:39:43 +0000

Azure API Management (APIM) is a fully managed gateway that sits in front of all your backend APIs. Instead of exposing your raw APIs directly to consumers, every request goes through APIM first. It handles security, rate limiting, transformation, monitoring, and documentation — all in one place.
I used APIM at Blue Yonder as the front door for all integrations on the SIAM platform. Every external system — Salesforce, ServiceNow, third-party vendors — called our APIs through APIM. It gave us one place to control, monitor, and secure everything.

Core Components
API Gateway receives all incoming API calls, applies policies before forwarding to the backend, and returns the response to the caller. This is the actual runtime component that handles every single request.
Developer Portal is an auto-generated documentation website where developers can discover and test your APIs, subscribe for API keys, and get started without calling your team. It is fully customizable with your branding.
Management Plane is the Azure Portal interface where you define APIs, products, policies, and users. You can import APIs directly from OpenAPI specs, WSDL files, Logic Apps, or Function Apps.
Analytics automatically logs every request with response times, error rates, and usage broken down by consumer. Built-in dashboards show you exactly what is happening across all your APIs.

APIs, Products and Subscriptions
Understanding this three-level hierarchy is the key to using APIM correctly.
An API is a group of related operations. For example an Orders API would contain

GET /orders, GET /orders/{id}, POST /orders, and DELETE /orders/{id}.

A Product is a bundle of one or more APIs with its own subscription keys and policies. A Partner Product might contain the Orders API and Inventory API with a limit of 5000 calls per day and require approval to subscribe.
A Subscription is a key pair that grants access to a Product. Every caller gets their own subscription key. You can revoke individual keys without affecting any other consumer — critical for security incidents.
At Blue Yonder we had three products:

Internal Product — no rate limit, no approval needed
Partner Product — 5000 calls per day, requires approval
Public Product — 100 calls per day, open signup

Policies — The Heart of APIM
Policies are rules that run on every request or response. Written in XML, they are applied at four levels — Global, Product, API, or Operation — giving you incredibly fine-grained control.
Every request goes through four policy sections in order:

Inbound — runs before the request reaches your backend
Backend — controls how the backend is called
Outbound — runs before the response reaches the caller
On-Error — runs when any policy throws an exception

Here are the policies I used most in production:
Rate limiting — limits a caller to a set number of calls per time window. Returns 429 Too Many Requests when exceeded.
Quota — a hard cumulative limit over a longer period. Different from rate limiting — this counts total calls over the day rather than calls per minute.
IP filtering — only allow requests from specific IP address ranges. Essential for internal APIs that should never be called from the public internet.
Validate JWT — validates an Azure AD JWT token on every request. This is the most important security policy for external-facing APIs. It checks the token is valid, not expired, and contains the required claims.
Set header — adds or modifies a header on the backend request. We used this to pass internal API keys to backend services without ever exposing them to callers. The caller sends their subscription key. APIM validates it then adds the real internal key before forwarding.
Rewrite URL — maps the external URL to a different internal URL. Callers hit /orders/{id} while the backend receives /v2/orders/{id}. This lets you version your backend without breaking existing callers.
Cache response — caches GET responses for a configurable duration. We cached inventory lookups for 5 minutes which reduced backend load by 60 percent during peak hours.
Transform JSON to XML — converts a JSON request body to XML before forwarding to legacy backends. Modern callers send JSON, APIM handles the transformation transparently.

Authentication Options
APIM supports four authentication methods. You choose based on who is calling and what level of security you need.
Subscription Key is the simplest option. The caller passes a key in the Ocp-Apim-Subscription-Key header. Good for partner and internal system integrations where you control both ends.
OAuth 2.0 with Azure AD is the most secure option for external APIs. The caller gets a JWT token from Azure AD first then passes it as a Bearer token. APIM validates it using the validate-jwt policy. The token contains the caller identity, roles, and permissions. Use this for all user-facing apps and B2B enterprise integrations.
Client Certificate (mTLS) requires the caller to present a certificate instead of a password. APIM validates the certificate thumbprint. We used this at Blue Yonder for banking integrations where the highest security was required.
Basic Authentication passes username and password encoded as Base64. Only use this for legacy systems that support nothing else and always over HTTPS. Avoid for any new integration.

Named Values — Storing Secrets Safely
Named Values are APIM variables that store sensitive values like API keys and connection strings. You reference them in policies using double curly braces without ever hardcoding the actual value.
When you create a Named Value you mark it as secret. The value is encrypted at rest and never visible in the portal after saving. Best practice is to link Named Values directly to Azure Key Vault so secrets rotate automatically without any policy changes.

Versioning and Revisions
Versions handle breaking changes. You run v1 and v2 simultaneously at different URLs. Callers choose which version to use and you retire v1 only after all callers have migrated. No forced upgrades.
Revisions handle non-breaking changes. You create Revision 2 as a work in progress that is not live yet. Make and test your changes safely. Promote to live when ready. Instantly roll back to Revision 1 if something goes wrong.
This is how we deployed all APIM changes at Blue Yonder — zero downtime, zero caller impact, instant rollback capability.

Monitoring and Tracing
Every APIM request automatically logs the timestamp, caller IP, subscription key used, operation called, response time, and HTTP status code.
The most useful debugging tool is request tracing. Add the Ocp-Apim-Trace: true header to any request and the response includes a full trace of every policy step — exactly what data entered each policy, what came out, and how long it took. This saved me hours of debugging at Blue Yonder. You can see precisely which policy transformed what and where a request slowed down or failed.
Connect APIM to Application Insights and every request appears there automatically. Set alerts on error rate thresholds or response time degradation to catch problems before your callers do.

The Full Enterprise Integration Pattern
This is the complete architecture I built at Blue Yonder combining APIM with Logic Apps, Service Bus, and Azure SQL:

`External System
    |
    | HTTPS with JWT token
    v
Azure APIM
    Validates JWT token
    Applies rate limiting
    Adds correlation ID header
    Rewrites URL to internal format
    |
    v
Azure Logic App
    Orchestrates business workflow
    Calls ServiceNow and Salesforce APIs
    |
    v
Azure Service Bus
    Reliable async messaging
    Dead letter queue for failures
    |
    v
Azure App Service API
    Processes the message
    Updates the database
    |
    v
Azure SQL Database`

Each layer has one job. APIM handles the front door. Logic Apps handles orchestration. Service Bus handles reliability. The API handles business logic. SQL handles persistence.

Key Lessons From Production

Always use Named Values for secrets — never hardcode API keys or passwords directly in policy XML.
Apply rate limiting at Product level not Global — different consumers have different needs. Partners get more calls than public users.
Use Revisions for every change — instant rollback has saved production incidents more than once.
Enable Application Insights from day one — you will need those logs the moment something goes wrong in production.
Use the Trace header during development — it shows exactly what every policy does to every request. Invaluable for debugging complex policy chains.
Set up the Developer Portal early — partners and consumers love self-service documentation. It reduces support requests dramatically.
Use validate-jwt for all external APIs — subscription keys alone are not enough. Tokens give you identity, roles, and expiry.
Add circuit breaker on every backend — protect your services from cascade failures when a downstream system goes down.

APIM Tiers
The Consumption tier charges per call with no monthly commitment — perfect for learning and low traffic APIs. The Developer tier costs around $50 per month with full features but no SLA — good for development and testing. Basic at around $150 per month is the entry point for production workloads. Standard at around $700 per month adds VNet support for enterprise use. Premium at around $2800 per month enables multi-region deployment and zone redundancy for global enterprise applications.

Summary
Azure API Management is the professional way to expose APIs in enterprise Azure architectures. One gateway to handle security, rate limiting, transformation, versioning, and monitoring for all your APIs.
Combined with Azure AD for authentication, Key Vault for secrets, Logic Apps for orchestration, and Service Bus for messaging — APIM completes the enterprise integration stack on Azure. If you are building serious integrations on Azure, APIM is not optional. It is the foundation everything else builds on.

Originally published at https://calm-island-0a7b4b30f.7.azurestaticapps.net/post.html?slug=azure-api-management-deep-dive
If you found this useful, follow me for more posts on Azure integration, C#, and cloud engineering.