DEV Community: Manohari Jayachandran

Database Interview Topics Part 1: SQL Joins Explained with Examples

Manohari Jayachandran — Fri, 24 Jul 2026 13:29:41 +0000

Database concepts come up constantly in technical interviews and joins specifically are one of the most commonly asked - and most commonly explained poorly, with abstract definitions and no actual data to look at. This is the first part of a new series covering the database topics that show up most often in interviews: joins, indexing, stored procedures, transactions, and normalization - each as its own focused post rather than one long, exhausting piece covering everything shallowly.

The Sample Data Used Throughout This Post

CUSTOMERS table
id | name
1  | Alex
2  | Priya
3  | Sam
4  | Jordan

ORDERS table
id | customer_id | amount
101| 1           | 50.00
102| 1           | 20.00
103| 2           | 75.00
104| 5           | 30.00   -- customer_id 5 does not exist
                            -- in the Customers table

Notice that Jordan has no orders, and one order references a customer that doesn't exist. These two intentional gaps are what make the differences between join types actually visible in the results below - without them, every join type would return the same rows and the distinctions wouldn't be observable.

INNER JOIN: Only Matching Rows From Both Sides

INNER JOIN returns only the rows where the join condition finds a match in both tables. Anything without a match on either side is dropped entirely.

Think of a school dance where only students who found a partner get counted. Anyone standing alone, on either side of the room, doesn't appear in the final head count at all.

SELECT c.name, o.amount
FROM Customers c
INNER JOIN Orders o ON c.id = o.customer_id;

-- RESULT:
-- name  | amount
-- Alex  | 50.00
-- Alex  | 20.00
-- Priya | 75.00

-- Jordan is gone (no matching order)
-- The order referencing customer_id 5 is gone
-- (that customer doesn't exist)

INNER JOIN is the default join for "give me records that genuinely relate to each other on both sides" - customer orders, employee assignments, product categories - any relationship where an unmatched row on either side isn't meaningful to the result.

LEFT JOIN: Everything From the Left, Matched or Not

LEFT JOIN returns every row from the left, or first-listed, table, regardless of whether a match exists on the right. Where there's no match, the right table's columns come back as NULL.

Think of a class attendance sheet listing every enrolled student, with their exam score next to their name if they took the exam, and simply blank if they didn't. Nobody gets removed from the list for not having taken the exam.

SELECT c.name, o.amount
FROM Customers c
LEFT JOIN Orders o ON c.id = o.customer_id;

-- RESULT:
-- name   | amount
-- Alex   | 50.00
-- Alex   | 20.00
-- Priya  | 75.00
-- Sam    | NULL
-- Jordan | NULL

-- Sam and Jordan appear with a NULL amount - they
-- exist in Customers but have no matching order
-- The orphaned order is still gone - it has no
-- home in the LEFT table

LEFT JOIN is used for "show me all X, including ones with no related Y" - all customers including those with zero orders, all employees including those in no project yet, all products including those never sold. This is genuinely one of the most common real-world join patterns.

RIGHT JOIN: The Mirror of LEFT, Rarely Used in Practice

RIGHT JOIN is the exact mirror of LEFT JOIN - it keeps every row from the right table, with NULLs on the left where there's no match.

SELECT c.name, o.amount
FROM Customers c
RIGHT JOIN Orders o ON c.id = o.customer_id;

-- RESULT:
-- name  | amount
-- Alex  | 50.00
-- Alex  | 20.00
-- Priya | 75.00
-- NULL  | 30.00

-- The orphaned order now appears, with a NULL
-- customer name - it exists in Orders but has no
-- matching customer
-- Sam and Jordan are gone - they have no matching order

RIGHT JOIN is rarely used in practice because any RIGHT JOIN can be rewritten as a LEFT JOIN simply by swapping the order the tables are listed in. Because of this, most teams and style guides standardize on always using LEFT JOIN for consistency and readability, and RIGHT JOIN shows up mainly in code written by someone who didn't reorder the tables, or in generated SQL from a tool.

FULL OUTER JOIN: Everything From Both Sides

FULL OUTER JOIN returns every row from both tables, matched or not. Where a row on either side has no match, the other side's columns come back as NULL.

SELECT c.name, o.amount
FROM Customers c
FULL OUTER JOIN Orders o ON c.id = o.customer_id;

-- RESULT:
-- name   | amount
-- Alex   | 50.00
-- Alex   | 20.00
-- Priya  | 75.00
-- Sam    | NULL
-- Jordan | NULL
-- NULL   | 30.00

-- Everyone and everything shows up - matched pairs,
-- unmatched customers, AND the orphaned order

FULL OUTER JOIN is used for data integrity checks specifically - finding customers with no orders and orders with no valid customer in a single query is a genuinely common real use case, especially when auditing a dataset for referential integrity problems after a migration or a bulk import.

CROSS JOIN: Every Combination of Every Row

CROSS JOIN pairs every row in one table with every row in the other table, with no matching condition at all. A table with 10 rows crossed with a table with 10 rows produces 100 result rows.

Think of a restaurant's build-your-own-meal menu, where every size option gets paired with every topping option to enumerate all possible combinations. This is deliberate, exhaustive pairing, not a relationship between matching records.

SELECT s.size, t.topping
FROM Sizes s
CROSS JOIN Toppings t;

-- If Sizes has 3 rows (Small, Medium, Large) and
-- Toppings has 4 rows (Cheese, Pepperoni, Mushroom,
-- Olive), this returns 12 rows - every size paired
-- with every topping

CROSS JOIN is used deliberately for generating all possible combinations of two independent sets - size, color, and style combinations for a product catalog, or a calendar grid pairing every day with every hour slot. It also happens by accident - forgetting a WHERE clause or join condition entirely silently turns what should have been an INNER JOIN into a CROSS JOIN, producing a result set far larger than intended. This is a genuinely common and expensive mistake on large tables.

SELF JOIN: A Table Joined to Itself

SELF JOIN joins a table to itself, treating it as if it were two separate tables, typically to compare rows within the same table to each other.

Think of a company directory listing every employee alongside their manager's name, where the manager is also just another employee in that same directory, not a separate list of manager-type people.

-- EMPLOYEES table
-- id | name  | manager_id
-- 1  | Dana  | NULL
-- 2  | Alex  | 1
-- 3  | Priya | 1
-- 4  | Sam   | 2

SELECT e.name AS employee, m.name AS manager
FROM Employees e
LEFT JOIN Employees m ON e.manager_id = m.id;

-- RESULT:
-- employee | manager
-- Dana     | NULL
-- Alex     | Dana
-- Priya    | Dana
-- Sam      | Alex

-- The SAME table (Employees) is used twice in one
-- query, aliased as "e" and "m" to distinguish the
-- two roles it's playing

SELF JOIN is used for any hierarchical or paired relationship stored within a single table - employee and manager chains, category and subcategory trees, or finding pairs of rows that share some attribute, like two products in the same category.

Choosing the Right Join

Needing only records that genuinely match on both sides calls for INNER JOIN. Needing everything from one specific side, matched or not, calls for LEFT JOIN, reordering tables rather than reaching for RIGHT JOIN. Needing everything from both sides, to check for gaps on either end, calls for FULL OUTER JOIN. Needing every possible combination of two independent sets, on purpose, calls for CROSS JOIN. Needing to compare rows within the same table to each other calls for SELF JOIN.

Key Lessons

INNER JOIN is the default most people mean when they just say "join" - only rows with a match on both sides survive.

LEFT JOIN is genuinely one of the most common real-world join patterns - "show me all X including ones with no related Y" comes up constantly in practice.

RIGHT JOIN can always be rewritten as a LEFT JOIN by swapping table order, which is why most teams standardize on LEFT JOIN for consistency.

FULL OUTER JOIN is the right tool specifically for finding gaps on both sides of a relationship at once, such as during a data integrity audit.

CROSS JOIN is either a deliberate tool for generating combinations, or a costly accident from a missing WHERE clause - knowing which one is actually intended matters a great deal.

SELF JOIN is how hierarchical or paired data stored in a single table gets compared to itself, using the same table aliased twice in one query.

What's Next

Part 2 of this series covers indexing - clustered versus non-clustered indexes, composite indexes, and when an index actually makes a query slower instead of faster.

Summary

Every SQL join answers the same underlying question differently: which rows survive when two tables don't perfectly line up. INNER JOIN keeps only what matches. LEFT and RIGHT JOIN keep everything from one specific side. FULL OUTER JOIN keeps everything from both. CROSS JOIN ignores matching entirely and pairs everything with everything. SELF JOIN compares a table to itself. Knowing which one produces which result, not just the syntax, is what actually gets tested in an interview, and what actually matters when writing a query against real data with real gaps in it.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=database-joins-explained

More from TechStack Blog:
Database: https://www.techstackblog.com/category.html?cat=database
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

System Design Fundamentals: The Components Every Real System Is Built From

Manohari Jayachandran — Wed, 22 Jul 2026 14:08:36 +0000

System design interviews ask a very small set of recurring questions dressed up in different scenarios - design a URL shortener, design a chat app, design a rate limiter. Underneath nearly all of them is the same handful of building blocks, combined differently depending on the specific problem. This post covers those building blocks individually - what each one is, an analogy, an example, and how they combine - so the interview stops being about memorizing famous architectures and starts being about reasoning from a shared set of first principles.

Most system design content jumps straight to "here's how to design Twitter," which teaches a specific answer without teaching the reasoning that produced it. Understanding each component on its own - what problem it solves, what it costs, when it's the wrong tool - is what actually transfers to a new, unfamiliar problem in an interview or in production work. This post deliberately stays at that component level.

Component 1: Load Balancer

A load balancer sits in front of multiple servers and distributes incoming requests across them, so no single server gets overwhelmed while others sit idle.

The Analogy: Think of a host at a busy restaurant. Customers don't walk in and pick their own table - the host looks at which servers have capacity and seats accordingly, so one waiter isn't drowning in tables while three others stand around. A load balancer does the same thing for incoming requests and backend servers.

Without a load balancer, a client connects directly to a single server - that server becomes a single point of failure, and its individual capacity becomes the entire system's capacity ceiling. With a load balancer in front of several servers, traffic spreads across all of them, and if one server goes down, the load balancer simply stops routing to it while traffic continues across the remaining servers.

Common distribution strategies include round robin, where requests rotate evenly across servers in order - simple, and it works well when servers are similar and requests are roughly similar in cost. Least connections routes new requests to whichever server currently has the fewest active connections, which works better when request processing time varies significantly. Health checks have the load balancer periodically ping each server, automatically removing any server that stops responding from rotation until it recovers.

How it stands alone vs. as part of a whole system: On its own, a load balancer solves exactly one problem - distributing traffic across multiple identical or similar servers. It does not solve data consistency, does not make individual requests faster, and provides no benefit at all with only one server behind it. Its real value only appears once there are multiple servers that need traffic spread across them - which is precisely why it's usually one of the first components added when a single server can no longer handle load alone.

Component 2: Cache

A cache is a smaller, faster storage layer that keeps a copy of frequently accessed data, so repeat requests can be served without going back to the slower, authoritative source every time.

The Analogy: Think of keeping frequently used spices on the counter instead of in a pantry down the hall. Walking to the pantry every single time is correct but slow; keeping a copy of the things reached for constantly, right at hand, trades a small amount of staleness risk - the pantry might get restocked with a fresher jar you don't know about yet - for a large amount of speed.

Without a cache, every single request pays the full cost of a database round trip, even for data that hasn't changed since the last request five seconds ago. With a cache, the application checks the cache first: a cache hit means the data was found and gets returned immediately without touching the database at all, while a cache miss means the data wasn't cached, gets fetched from the database, and then gets stored in the cache for next time.

The real cost of caching is staleness. If the underlying data changes but the cache still holds the old value, the cache now serves incorrect data until it expires or is explicitly invalidated. A few common strategies manage this: TTL, or time to live, lets cached data automatically expire after a set duration - simple, but data can be stale for up to that entire duration. Write-through updates the cache and the database at the same time on every write - the cache stays consistent, but every write becomes slightly more expensive. Explicit invalidation has application code actively remove or update the specific cache entry the moment underlying data changes - the most accurate approach, but it requires the application to remember to do this correctly everywhere that data can possibly change.

How it stands alone vs. as part of a whole system: A cache alone speeds up reads specifically - it does nothing for writes, and it introduces a genuine new failure mode, serving stale data, that didn't exist before. As part of a whole system, caching is usually layered at multiple levels simultaneously - a CDN caching static assets, an in-memory cache caching frequent database query results, and a browser cache on the client side - each solving the same underlying problem at a different point in the request path.

Component 3: Message Queue

A message queue sits between a producer, something creating work, and a consumer, something processing that work, holding messages until the consumer is ready, so the two sides don't need to move at the same pace or even be running at the same time.

The Analogy: This is the same analogy covered in more depth in an earlier post on this blog about Azure Service Bus - a restaurant order slip. The waiter doesn't wait next to the stove for a dish to finish cooking; the order becomes a slip that queues behind other orders, and whichever cook is free picks it up next. The waiter and the cook move at their own pace, decoupled by the slip sitting between them.

Without a queue, a producer calling a consumer directly means that if the consumer is slow or temporarily down, the producer either fails outright or blocks waiting - the two are tightly coupled in time. With a queue between them, the producer drops a message and moves on immediately, and the consumer picks up messages whenever it's ready, at its own pace. Neither side needs the other to be available or fast at the same moment.

Azure Service Bus, covered in an earlier post on this blog, is a real production implementation of exactly this pattern - queues for a single producer and single consumer, topics for one producer reaching many independent consumers, and a dead-letter queue specifically for messages that fail processing repeatedly, so a bad message doesn't block every healthy message behind it.

How it stands alone vs. as part of a whole system: A queue alone doesn't process anything - it only holds messages until something consumes them, meaning at least one consumer must exist and actually be running for the queue to be useful at all. As part of a whole system, queues are the standard way to connect a fast, user-facing action like placing an order to slower background work like sending a confirmation email, updating inventory, or logging analytics, without making the user wait for all of that slower work to finish first.

Component 4: Database - SQL vs NoSQL

The database is the persistent storage layer where a system's actual data lives, queried and updated over the system's lifetime. The SQL versus NoSQL choice is really a question of which storage shape matches the actual shape of the data and its access patterns.

The Analogy: This is the same analogy covered in more depth in an earlier post on this blog - a filing cabinet, representing SQL and its fixed-schema rows, versus a box of index cards, representing NoSQL and its flexible-shape documents. The filing cabinet enforces that every folder has the same fields, in the same order - useful when relationships between data matter and consistency is critical. The index card box allows each card to carry different fields entirely - useful when the shape of the data varies or changes frequently, and rigid structure would slow things down rather than help.

Choose SQL, the relational option, when data has a consistent, well-defined shape, when relationships between entities matter through foreign keys and joins across tables, and when strong consistency and transactions genuinely matter - a bank transfer either fully succeeds or fully fails, never half-completes. Choose NoSQL - document, key-value, or wide-column stores - when data shape varies significantly between records, when horizontal scale across many servers matters more than strict relational consistency, and when the access pattern is simple, mostly key-based lookups rather than complex joins.

An earlier post on this blog compared Azure SQL, Cosmos DB, and Azure Table Storage directly as a real example of this decision - Azure SQL for this blog's own Posts table, since it has a consistent, relational shape, Cosmos DB for operational and log data with genuinely variable shape, and Table Storage for high-volume, simple key-based lookups where cost matters more than query power.

How it stands alone vs. as part of a whole system: A database alone is just storage - it doesn't solve traffic distribution, doesn't make repeat reads fast, and doesn't decouple slow processing from fast requests. As part of a whole system, the database usually sits behind a cache for read speed, is fed by queues for write-heavy background processing, and is the one component every other piece in the system ultimately exists to protect from excessive direct load.

Component 5: CDN (Content Delivery Network)

A CDN is a globally distributed network of servers that cache and serve content from a location physically closer to the person requesting it, rather than every request traveling all the way to one central server.

The Analogy: Think of a chain of regional warehouses instead of one central warehouse. Shipping a product from a warehouse in the same region as the customer is faster than shipping everything from one central location on the other side of the country - the product itself is identical, only the distance it travels changes.

Without a CDN, a request from a user in Australia to a server in the United States travels the full physical distance every time, adding real, unavoidable latency. With a CDN, that same user's request is served by a nearby edge server holding a cached copy, and the response comes from a server much closer physically, cutting latency substantially for content that doesn't change per request.

How it stands alone vs. as part of a whole system: A CDN is only useful for content that can actually be cached - static assets like images, CSS, JavaScript, or video, not personalized or frequently-changing data specific to one user. As part of a whole system, a CDN typically handles the static-asset portion of a request while the load balancer, cache, database, and queue handle the dynamic, personalized portion - splitting the request path so each component only handles the kind of traffic it's actually good at handling.

Putting It All Together: One Request Path

A realistic combined request path looks something like this.

A user requests a page.
Static assets - images, CSS, JavaScript - get served directly from the CDN, fast and close to the user.
The dynamic portion of the request hits the load balancer, which routes it to one of several application servers.
That application server checks the cache first: on a cache hit, it returns the result immediately; on a cache miss, it continues to the database.
The application server queries the database for the actual data, then stores the result in the cache for next time.
Any slow, non-urgent follow-up work - sending an email, logging analytics, updating a search index - gets published to a message queue instead of being done inline, so the user gets their response immediately while a separate consumer processes the queue at its own pace.

Every component in that path solves a different problem. None of them substitute for each other, and a real system rarely needs only one.

Key Lessons

Each component solves one specific problem - load balancers distribute traffic, caches speed up reads, queues decouple timing between producer and consumer, databases persist data, and CDNs shorten physical distance.

None of these components is free - a load balancer adds a hop, a cache adds a staleness risk, a queue adds a processing delay, and a CDN adds cache-invalidation complexity for content that does change.

The right question for any of these components is never "should I use this" in the abstract, but "what specific problem in this system does this solve, and is that problem actually present."

Real systems combine several of these components along a single request path, each handling the part it's actually good at, rather than any single component trying to do everything.

This same reasoning already appears across this blog's own Azure posts - Service Bus as a message queue, Cosmos DB and Table Storage as NoSQL choices, Azure SQL as the relational choice - system design vocabulary and specific cloud service choices are the same underlying ideas expressed at different levels of abstraction.

What's Next

Future System Design posts on this blog will apply these same components to specific, realistic scenarios, including a walkthrough of designing a resilient integration platform, drawing on real experience connecting Salesforce and ServiceNow at Blue Yonder.

Summary

System design interviews, and production architecture, both draw from the same small set of building blocks: load balancers to distribute traffic, caches to speed up repeat reads, message queues to decouple producers from consumers, databases to persist data in a shape that matches its actual structure, and CDNs to shorten the physical distance between content and the people requesting it. None of these is a default choice - each earns its place by solving a specific problem that's genuinely present in a given system. Understanding what problem each one solves, individually, is what makes it possible to reason through an unfamiliar system design question rather than just recalling a memorized architecture.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=system-design-fundamentals-components

Related reading on TechStack Blog:
Azure Service Bus: https://www.techstackblog.com/post.html?slug=azure-service-bus-deep-dive
Cosmos DB and Blob Storage: https://www.techstackblog.com/post.html?slug=azure-cosmos-db-blob-storage

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
Azure: https://www.techstackblog.com/category.html?cat=azure

Design Patterns in C# Part 3: Behavioral Patterns - Strategy, Observer, Command, State, and Template Method

Manohari Jayachandran — Mon, 20 Jul 2026 18:57:09 +0000

This is Part 3, the final part of a three-part design patterns series built for interview prep. Part 1 covered Creational patterns - how objects get created. Part 2 covered Structural patterns - how objects and classes are composed into larger structures. This closing part covers Behavioral patterns - how objects communicate and share responsibility with each other. Same format throughout the series: the problem each pattern solves, an analogy, a before-and-after code example, and honest guidance on when it's actually worth the added complexity.

Design Patterns in C#, Part 3 of 3 — Behavioral patterns close out the series. Thirteen patterns total, all with real C# and honest tradeoffs.

Behavioral patterns include Strategy, Observer, Command, State, Template Method, Iterator, and Chain of Responsibility. This post covers the five that come up most often in real interviews and real code: Strategy, Observer, Command, State, and Template Method.

Pattern 1: Strategy

The problem Strategy solves is defining a family of interchangeable algorithms, encapsulating each one separately, and letting the algorithm be swapped at runtime without the calling code changing at all.

Think of different routes to the same destination - driving, walking, or public transit. The destination stays the same, and "get me there" stays the same request, but the actual method of travel can be swapped independently of that request. Strategy applies the same idea to algorithms: the calling code asks for a result, and which specific algorithm produces that result can change freely.

This is genuinely the same underlying idea covered twice already in this series under different names - an IDiscount interface in an earlier Open/Closed Principle post, and a custom IComparer<T> in an earlier Advanced Generics post. Strategy is simply the formal design pattern name for that same pattern.

// The strategy interface
public interface IShippingStrategy
{
    decimal CalculateCost(decimal weight, decimal distance);
}

public class StandardShipping : IShippingStrategy
{
    public decimal CalculateCost(decimal weight, decimal distance)
        => weight * 0.5m + distance * 0.1m;
}

public class ExpressShipping : IShippingStrategy
{
    public decimal CalculateCost(decimal weight, decimal distance)
        => (weight * 0.5m + distance * 0.1m) * 2.5m;
}

public class FreightShipping : IShippingStrategy
{
    public decimal CalculateCost(decimal weight, decimal distance)
        => weight > 100 ? weight * 0.3m : weight * 0.5m;
}

// The calling code depends only on the interface -
// it never changes regardless of which strategy is used
public class ShippingCalculator
{
    private readonly IShippingStrategy _strategy;

    public ShippingCalculator(IShippingStrategy strategy)
        => _strategy = strategy;

    public decimal Calculate(decimal weight, decimal distance)
        => _strategy.CalculateCost(weight, distance);
}

// Swapping the algorithm is just swapping which
// strategy gets injected - ShippingCalculator itself
// never needs to change
var standard = new ShippingCalculator(new StandardShipping());
var express = new ShippingCalculator(new ExpressShipping());

Console.WriteLine(standard.Calculate(10, 50));
Console.WriteLine(express.Calculate(10, 50));

Strategy earns its place once there are genuinely multiple interchangeable algorithms for the same task, and the choice between them needs to stay flexible - configurable at runtime, or extensible without touching existing code. For exactly one algorithm with no realistic alternative on the horizon, introducing an interface and a strategy class is unnecessary ceremony around code that could just be a plain method.

Pattern 2: Observer

The problem Observer solves is defining a one-to-many relationship between objects, so that when one object's state changes, all of its dependents are notified automatically, without the object doing the notifying needing to know anything about who is listening.

Think of a YouTube channel and its subscribers. The channel publishes a new video, and every subscriber gets notified - the channel has no idea how many subscribers exist, who they are, or what each one does in response to the notification. Someone can subscribe or unsubscribe at any time without the channel's own behavior changing at all. Observer is exactly this relationship in code.

// The observer interface - anything that wants to
// react to changes implements this
public interface IOrderObserver
{
    void OnOrderPlaced(string orderId, decimal amount);
}

// Concrete observers - each reacts independently
public class EmailNotifier : IOrderObserver
{
    public void OnOrderPlaced(string orderId, decimal amount)
        => Console.WriteLine($"Email sent for order {orderId}");
}

public class InventoryUpdater : IOrderObserver
{
    public void OnOrderPlaced(string orderId, decimal amount)
        => Console.WriteLine($"Inventory updated for order {orderId}");
}

public class AnalyticsTracker : IOrderObserver
{
    public void OnOrderPlaced(string orderId, decimal amount)
        => Console.WriteLine($"Analytics event logged: {amount:C}");
}

// The subject - maintains a list of observers and
// notifies all of them, without knowing what any
// individual observer actually does
public class OrderService
{
    private readonly List<IOrderObserver> _observers = new();

    public void Subscribe(IOrderObserver observer)
        => _observers.Add(observer);

    public void Unsubscribe(IOrderObserver observer)
        => _observers.Remove(observer);

    public void PlaceOrder(string orderId, decimal amount)
    {
        Console.WriteLine($"Order {orderId} placed");
        // Notify every subscriber - OrderService has
        // no idea what any of them actually do
        foreach (var observer in _observers)
            observer.OnOrderPlaced(orderId, amount);
    }
}

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

// One call triggers all three observers independently
orderService.PlaceOrder("ORD-001", 49.99m);

// Adding a fourth observer requires zero changes
// to OrderService itself
orderService.Subscribe(new AnalyticsTracker());

This is the same underlying idea as an Azure Service Bus Topic with multiple subscriptions, covered in an earlier post in this blog's Azure series - one publisher, many independent subscribers, each reacting without the publisher knowing or caring who they are. Observer is that same pattern applied in-process rather than across distributed systems.

Observer earns its place when multiple, genuinely independent parts of a system need to react to the same event, and the set of things reacting to it may grow or change over time. C#'s built-in event keyword and delegates already implement a lightweight version of this pattern natively - reach for a full custom Observer implementation mainly when the built-in event model doesn't fit, such as needing dynamic subscribe and unsubscribe management beyond what a simple event handles cleanly.

Five behavioral patterns, five different answers to the same question — how should these objects actually talk to each other?

Pattern 3: Command

The problem Command solves is turning a request or an action into a standalone object, so that request can be queued, logged, delayed, passed around, or undone - things that are difficult or impossible to do with a plain, immediate method call.

Think of a restaurant order slip. A waiter doesn't walk into the kitchen and cook the dish personally on the spot - they write the order onto a slip, which becomes a physical object that can be handed off, queued behind other orders, or handled by whichever cook is free. The order slip is the request, turned into an object, decoupled from who executes it and when.

// The command interface
public interface ICommand
{
    void Execute();
    void Undo();
}

// A simple receiver - the thing commands act upon
public class TextDocument
{
    private readonly StringBuilder _content = new();

    public void Append(string text) => _content.Append(text);
    public void RemoveLast(int length)
        => _content.Length = Math.Max(0, _content.Length - length);

    public string Content => _content.ToString();
}

// A concrete command - captures everything needed
// to execute AND undo one specific action
public class AppendTextCommand : ICommand
{
    private readonly TextDocument _document;
    private readonly string _text;

    public AppendTextCommand(TextDocument document, string text)
    {
        _document = document;
        _text = text;
    }

    public void Execute() => _document.Append(_text);
    public void Undo() => _document.RemoveLast(_text.Length);
}

// An invoker - maintains history, enabling undo
// without needing to know what any command actually does
public class CommandHistory
{
    private readonly Stack<ICommand> _history = new();

    public void ExecuteCommand(ICommand command)
    {
        command.Execute();
        _history.Push(command);
    }

    public void UndoLast()
    {
        if (_history.Count > 0)
            _history.Pop().Undo();
    }
}

var document = new TextDocument();
var history = new CommandHistory();

history.ExecuteCommand(new AppendTextCommand(document, "Hello"));
history.ExecuteCommand(new AppendTextCommand(document, " World"));

Console.WriteLine(document.Content); // "Hello World"

history.UndoLast();
Console.WriteLine(document.Content); // "Hello"

Command earns its place when a request genuinely needs to be treated as a first-class object - queued for later execution, logged for auditing, transmitted somewhere else, or undone. For a simple, immediate action with no need for any of those capabilities, a direct method call is simpler and Command adds ceremony without solving a real problem.

Pattern 4: State

The problem State solves is letting an object change its own behavior when its internal state changes, so the object appears to change its class at runtime, without a large if/else or switch statement checking "what state am I currently in" scattered throughout the codebase.

Think of a traffic light. The same physical object behaves completely differently depending on which state it's currently in - red means stop, green means go, yellow means prepare to stop - and it transitions through a defined sequence of those states over time. The light doesn't have one giant method with an if/else for every color; each state's behavior is genuinely distinct.

// The state interface
public interface IOrderState
{
    void Next(OrderContext context);
    string StatusName { get; }
}

// Each concrete state knows what state comes next,
// and what its own status name is - the logic for
// each state lives in exactly one place
public class PendingState : IOrderState
{
    public string StatusName => "Pending";
    public void Next(OrderContext context)
        => context.SetState(new ShippedState());
}

public class ShippedState : IOrderState
{
    public string StatusName => "Shipped";
    public void Next(OrderContext context)
        => context.SetState(new DeliveredState());
}

public class DeliveredState : IOrderState
{
    public string StatusName => "Delivered";
    public void Next(OrderContext context)
        => Console.WriteLine("Order already delivered - no next state");
}

// The context - delegates behavior to its
// current state object entirely
public class OrderContext
{
    private IOrderState _state = new PendingState();

    public void SetState(IOrderState state) => _state = state;
    public string CurrentStatus => _state.StatusName;

    public void Advance() => _state.Next(this);
}

var order = new OrderContext();
Console.WriteLine(order.CurrentStatus); // Pending

order.Advance();
Console.WriteLine(order.CurrentStatus); // Shipped

order.Advance();
Console.WriteLine(order.CurrentStatus); // Delivered

// WITHOUT State, this would typically be one method
// with a switch on a status enum, repeated everywhere
// the order's behavior needs to vary by status -
// State moves each state's specific logic into its
// own class instead

State earns its place when an object has several genuinely distinct states, each with meaningfully different behavior, and the transitions between them follow real rules. For two states with a trivial difference in behavior, a simple boolean flag and an if statement is often more direct - State's real value shows up once the number of states and the complexity of behavior per state both grow past what a flag or a simple enum switch can comfortably express.

Pattern 5: Template Method

The problem Template Method solves is defining the skeleton of an algorithm in a base class - the fixed sequence of steps - while letting subclasses override specific individual steps without changing the overall structure or order.

Think of a recipe template for making a hot beverage. The overall sequence is always the same - boil water, brew, pour into a cup, add condiments - but the specific brewing step and the specific condiments differ between tea and coffee. The recipe's structure stays fixed; only certain steps within it vary by beverage.

// The abstract base class defines the fixed
// algorithm skeleton
public abstract class BeverageTemplate
{
    // The template method - defines the FIXED sequence
    public void Prepare()
    {
        BoilWater();
        Brew();
        PourInCup();
        AddCondiments();
    }

    // Steps common to every beverage - implemented once
    private void BoilWater() => Console.WriteLine("Boiling water");
    private void PourInCup() => Console.WriteLine("Pouring into cup");

    // Steps that vary by beverage - left abstract,
    // subclasses MUST provide these
    protected abstract void Brew();
    protected abstract void AddCondiments();
}

public class Tea : BeverageTemplate
{
    protected override void Brew()
        => Console.WriteLine("Steeping tea bag");

    protected override void AddCondiments()
        => Console.WriteLine("Adding lemon");
}

public class Coffee : BeverageTemplate
{
    protected override void Brew()
        => Console.WriteLine("Brewing coffee grounds");

    protected override void AddCondiments()
        => Console.WriteLine("Adding milk and sugar");
}

// The overall SEQUENCE is guaranteed identical for
// both beverages - only the specific steps differ
BeverageTemplate tea = new Tea();
tea.Prepare();

BeverageTemplate coffee = new Coffee();
coffee.Prepare();

This same idea already appeared earlier in this series without being named yet - the NotificationCreator class in Part 1's Factory Method section used exactly this pattern, with a base class method calling an abstract method that subclasses fill in. Template Method and Factory Method frequently show up together in the same class hierarchy in real code.

Template Method earns its place when several related classes share the same overall sequence of steps, but differ in the specific implementation of one or more of those steps - and it's genuinely important that the sequence itself can't be reordered or skipped by a subclass. For classes with only superficially similar behavior and no real shared sequence, forcing them into a common template can create an awkward, overly rigid hierarchy instead of solving a real problem.

Key Lessons

Strategy makes an algorithm swappable at runtime through a shared interface - the same underlying idea already seen twice earlier in this series as IDiscount and a custom IComparer<T>, just under its formal design pattern name.

Observer lets multiple independent parts of a system react to the same event without the publisher knowing who's listening - conceptually the same relationship as an Azure Service Bus Topic, applied in-process instead of across distributed systems.

Command turns a request into an object, which is what actually makes queuing, logging, delaying, and undo possible - a direct method call can't do any of those things on its own.

State moves state-specific behavior into its own class per state, replacing a scattered if/else or switch on "what state am I in" with each state owning its own logic.

Template Method fixes the overall sequence of an algorithm in a base class while leaving specific steps for subclasses to fill in - the parent controls order, subclasses control detail.

The Series, In Full

This closes out the three-part design patterns series. Part 1 covered Creational patterns - Singleton, Factory Method, Builder, Abstract Factory. Part 2 covered Structural patterns - Adapter, Decorator, Facade, Composite. Part 3 covered Behavioral patterns - Strategy, Observer, Command, State, Template Method. Thirteen patterns total, each with the problem it solves, an analogy, real C# code, and honest guidance on when it's actually worth using, not just when it exists as an option.

Summary

Behavioral patterns solve one consistent underlying question - how should these objects actually communicate and share responsibility - in five different ways depending on the specific shape of the problem. Strategy swaps an algorithm without touching the caller. Observer lets many independent parts react to one event. Command turns a request into something that can be queued, logged, or undone. State moves state-specific behavior into dedicated classes. Template Method fixes a sequence while leaving specific steps open. As with every pattern across this series, each one adds real indirection that only earns its place once the specific problem it solves is genuinely present in the code, not applied by default just because the pattern exists.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=design-patterns-behavioral-csharp

Part 1 of this series (Creational patterns): https://www.techstackblog.com/post.html?slug=design-patterns-creational-csharp
Part 2 of this series (Structural patterns): https://www.techstackblog.com/post.html?slug=design-patterns-structural-csharp

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Design Patterns in C# Part 2: Structural Patterns - Adapter, Decorator, Facade, and Composite

Manohari Jayachandran — Thu, 16 Jul 2026 15:14:32 +0000

This is Part 2 of a three-part design patterns series built for interview prep. Part 1 covered Creational patterns - how objects get created. This part covers Structural patterns - how objects and classes are composed into larger structures. Same format throughout: the problem each pattern solves, an analogy, a before-and-after code example, and honest guidance on when it's actually worth the added complexity.

Design Patterns in C#, Part 2 of 3 — Structural patterns this time, covering how objects and classes compose into larger structures.

Structural patterns include Adapter, Decorator, Facade, Composite, Proxy, and Bridge. This post covers the four that come up most often in real interviews and real code: Adapter, Decorator, Facade, and Composite.

Pattern 1: Adapter

The problem Adapter solves is making two interfaces that were never designed to work together actually work together, without modifying either one.

Think of a physical power plug adapter. A US laptop charger and a European wall socket are both perfectly functional on their own, but their shapes are incompatible. Nobody rewires the wall or rebuilds the charger - a small adapter sits between them, translating one shape into the other. Adapter does the same thing in code: it translates one interface into another without changing either side.

// The interface your code already expects
public interface IPaymentProcessor
{
    void ProcessPayment(decimal amount);
}

// A third-party library with an incompatible interface
// you cannot modify - this is someone else's code
public class LegacyPaymentGateway
{
    public void MakeTransaction(double amountInCents)
    {
        Console.WriteLine($"Processing {amountInCents} cents");
    }
}

// WITHOUT Adapter - the rest of the codebase has to
// know about LegacyPaymentGateway's specific method
// signature and unit conventions directly
public class CheckoutService
{
    private readonly LegacyPaymentGateway _gateway = new();

    public void Checkout(decimal amount)
    {
        // every caller needs to remember to convert
        // dollars to cents, and call MakeTransaction
        // specifically - tightly coupled to this one
        // library's exact shape
        _gateway.MakeTransaction((double)(amount * 100));
    }
}

// WITH Adapter - the incompatibility is isolated
// to one small class
public class LegacyPaymentAdapter : IPaymentProcessor
{
    private readonly LegacyPaymentGateway _gateway;

    public LegacyPaymentAdapter(LegacyPaymentGateway gateway)
        => _gateway = gateway;

    public void ProcessPayment(decimal amount)
    {
        // the unit conversion and method name
        // mismatch lives HERE, in exactly one place
        double amountInCents = (double)(amount * 100);
        _gateway.MakeTransaction(amountInCents);
    }
}

// The rest of the codebase depends only on
// IPaymentProcessor - it never knows LegacyPaymentGateway
// exists at all
public class CheckoutService
{
    private readonly IPaymentProcessor _processor;

    public CheckoutService(IPaymentProcessor processor)
        => _processor = processor;

    public void Checkout(decimal amount)
        => _processor.ProcessPayment(amount);
}

var adapter = new LegacyPaymentAdapter(new LegacyPaymentGateway());
var checkout = new CheckoutService(adapter);
checkout.Checkout(49.99m);

Adapter earns its place specifically around third-party libraries, legacy code, or any external dependency whose interface doesn't match what the rest of the codebase expects and can't be changed directly. It's not worth introducing between two pieces of code that are both already under direct control - in that case, simply changing one interface to match the other is the more direct fix, with no adapter layer needed at all.

Pattern 2: Decorator

The problem Decorator solves is adding behavior to a single object instance dynamically, without modifying its class, without affecting other instances of that same class, and without relying on subclassing.

Think of a plain coffee, with milk added, then a shot of caramel added on top of that. Each addition wraps the drink before it, adding its own contribution, without needing a separate class for every possible combination - CoffeeWithMilk, CoffeeWithCaramel, CoffeeWithMilkAndCaramel, and so on infinitely. Decorator wraps objects the same way, layer by layer, at runtime.

// The base interface
public interface ICoffee
{
    decimal Cost();
    string Description();
}

public class PlainCoffee : ICoffee
{
    public decimal Cost() => 2.00m;
    public string Description() => "Coffee";
}

// WITHOUT Decorator - a new subclass for every
// possible combination of add-ons
public class CoffeeWithMilk : PlainCoffee { /* ... */ }
public class CoffeeWithCaramel : PlainCoffee { /* ... */ }
public class CoffeeWithMilkAndCaramel : PlainCoffee { /* ... */ }
// Adding a third add-on option means the number of
// subclasses needed grows combinatorially

// WITH Decorator - each add-on is a small wrapper
// class that can be combined at runtime, in any order
public abstract class CoffeeDecorator : ICoffee
{
    protected readonly ICoffee _coffee;
    protected CoffeeDecorator(ICoffee coffee)
        => _coffee = coffee;

    public virtual decimal Cost() => _coffee.Cost();
    public virtual string Description()
        => _coffee.Description();
}

public class MilkDecorator : CoffeeDecorator
{
    public MilkDecorator(ICoffee coffee) : base(coffee) { }

    public override decimal Cost() => _coffee.Cost() + 0.50m;
    public override string Description()
        => _coffee.Description() + " + milk";
}

public class CaramelDecorator : CoffeeDecorator
{
    public CaramelDecorator(ICoffee coffee) : base(coffee) { }

    public override decimal Cost() => _coffee.Cost() + 0.75m;
    public override string Description()
        => _coffee.Description() + " + caramel";
}

// Combine any way, at runtime, without a single
// new subclass for the combination
ICoffee order = new CaramelDecorator(
    new MilkDecorator(new PlainCoffee())
);

Console.WriteLine(order.Description()); // Coffee + milk + caramel
Console.WriteLine(order.Cost());        // 3.25

This pattern is not just a textbook exercise - it's how the .NET Stream classes actually work. new GZipStream(new FileStream(path, FileMode.Open), CompressionMode.Compress) wraps a FileStream with compression behavior, and more decorators like encryption or buffering can wrap that further, each layer adding one capability without changing any of the classes underneath.

Decorator earns its place when behavior needs to be added or removed from individual object instances at runtime, in combinations that would otherwise require an unmanageable number of subclasses. For a fixed, small set of variations known entirely at compile time, straightforward inheritance or simple composition without the full decorator pattern is often simpler and easier to follow.

Four structural patterns, four different answers to the same question — how should these pieces actually fit together?

Pattern 3: Facade

The problem Facade solves is providing one simple, unified interface to a subsystem made up of many complex, interacting parts, so calling code doesn't need to understand or coordinate all of those parts directly.

Think of a car's ignition. Turning the key, or pressing the start button, triggers fuel injection, spark timing, starter motor engagement, and a dozen other coordinated subsystems - the driver never manages any of that directly. One simple action hides a genuinely complicated system underneath. Facade provides that same single, simple entry point in code.

// A genuinely complex subsystem with several
// interacting parts - this complexity is real
// and does not go away, it just gets hidden
public class InventorySystem
{
    public bool CheckStock(string sku, int qty)
        => true; // simplified
}

public class PaymentSystem
{
    public bool ChargeCard(string cardToken, decimal amount)
        => true; // simplified
}

public class ShippingSystem
{
    public string ScheduleDelivery(string address)
        => "TRACK123"; // simplified
}

public class NotificationSystem
{
    public void SendConfirmation(string email, string trackingNumber)
        => Console.WriteLine($"Confirmation sent: {trackingNumber}");
}

// WITHOUT Facade - calling code has to know about
// and correctly coordinate all four systems itself
public void PlaceOrderWithoutFacade(
    string sku, int qty, string cardToken,
    decimal amount, string address, string email)
{
    var inventory = new InventorySystem();
    var payment = new PaymentSystem();
    var shipping = new ShippingSystem();
    var notification = new NotificationSystem();

    if (inventory.CheckStock(sku, qty))
    {
        if (payment.ChargeCard(cardToken, amount))
        {
            var tracking = shipping.ScheduleDelivery(address);
            notification.SendConfirmation(email, tracking);
        }
    }
    // this coordination logic now has to be repeated
    // correctly everywhere an order gets placed
}

// WITH Facade - one simple entry point
public class OrderFacade
{
    private readonly InventorySystem _inventory = new();
    private readonly PaymentSystem _payment = new();
    private readonly ShippingSystem _shipping = new();
    private readonly NotificationSystem _notification = new();

    public bool PlaceOrder(
        string sku, int qty, string cardToken,
        decimal amount, string address, string email)
    {
        if (!_inventory.CheckStock(sku, qty))
            return false;

        if (!_payment.ChargeCard(cardToken, amount))
            return false;

        var tracking = _shipping.ScheduleDelivery(address);
        _notification.SendConfirmation(email, tracking);
        return true;
    }
}

// Calling code is now trivially simple, and the
// coordination logic exists in exactly one place
var facade = new OrderFacade();
facade.PlaceOrder("SKU-001", 1, "tok_abc", 49.99m,
    "123 Main St", "customer@example.com");

Facade earns its place whenever calling code repeatedly needs to coordinate several subsystems in the same sequence - centralizing that coordination in one place prevents the same multi-step logic from being duplicated, and inevitably drifting out of sync, across multiple call sites. It's not about making the underlying subsystem less complex - that complexity is still there - it's about giving callers a simple, correct way to use it without needing to understand all of it directly.

Pattern 4: Composite

The problem Composite solves is treating a single object and a group of objects through the exact same interface, so calling code doesn't need separate logic for "one item" versus "a collection of items."

Think of a file system. A folder can contain files, and it can also contain other folders, which themselves contain files or more folders, arbitrarily deep. When calculating how much space a folder uses, the calculation works identically whether a given item turns out to be a single file or an entire nested folder - each one just needs to be able to answer "how big are you." Composite is exactly this: treating individual objects and groups of objects through one shared interface.

// The shared interface - both leaves and
// composites implement this
public interface IFileSystemItem
{
    string Name { get; }
    long GetSize();
}

// Leaf - a single file, no children
public class FileItem : IFileSystemItem
{
    public string Name { get; }
    private readonly long _size;

    public FileItem(string name, long size)
    {
        Name = name;
        _size = size;
    }

    public long GetSize() => _size;
}

// Composite - a folder, which can contain
// other IFileSystemItems (files OR folders)
public class FolderItem : IFileSystemItem
{
    public string Name { get; }
    private readonly List<IFileSystemItem> _children = new();

    public FolderItem(string name) => Name = name;

    public void Add(IFileSystemItem item)
        => _children.Add(item);

    // The size of a folder is just the sum of
    // whatever its children report - it does not
    // matter whether each child is a file or
    // another folder, the interface is identical
    public long GetSize()
        => _children.Sum(child => child.GetSize());
}

// Building a nested structure
var root = new FolderItem("root");
var docs = new FolderItem("documents");
docs.Add(new FileItem("resume.pdf", 500));
docs.Add(new FileItem("cover-letter.pdf", 200));

var photos = new FolderItem("photos");
photos.Add(new FileItem("vacation.jpg", 3000));

root.Add(docs);
root.Add(photos);
root.Add(new FileItem("notes.txt", 50));

// One call, correctly recurses through the ENTIRE
// nested structure - no special-casing files vs
// folders anywhere in this calling code
Console.WriteLine(root.GetSize()); // 3750

Composite earns its place specifically when a domain is genuinely hierarchical - things that contain other things of the same conceptual type, arbitrarily deep - like file systems, UI component trees, or organizational charts. For a flat, non-nested collection of items with no "contains other items of the same type" relationship, Composite adds a layer of abstraction that isn't solving any real problem, and a plain list is simpler and more honest about the actual shape of the data.

Key Lessons

Adapter isolates an incompatibility to one small class, and earns its place specifically around external dependencies that can't be modified directly - not between two pieces of code already under direct control.

Decorator adds behavior to individual object instances at runtime, avoiding a combinatorial explosion of subclasses - .NET's own Stream classes are a real, built-in example of this pattern in daily use.

Facade centralizes coordination logic for a complex subsystem into one simple entry point, without making the underlying subsystem itself any less complex.

Composite lets calling code treat a single item and a nested group of items identically, and earns its place specifically for genuinely hierarchical domains, not for flat collections with no real containment relationship.

Every structural pattern covered here is solving a coupling or duplication problem that becomes real friction at some scale - none of them should be reached for preemptively before that friction actually shows up.

What's Next

Part 3 covers Behavioral patterns - Strategy, Observer, Command, State, and Template Method - the patterns concerned with how objects communicate and share responsibility with each other. This closes out the series.

Summary

Structural patterns solve one consistent underlying question - how should these pieces actually fit together - in four different ways depending on the specific shape of the problem. Adapter reconciles two incompatible interfaces. Decorator adds behavior to individual instances without subclass explosion. Facade simplifies the calling code's relationship to a complex subsystem. Composite treats individual items and nested groups through one shared interface. As with the creational patterns covered in Part 1, each of these adds real indirection that only pays for itself once the specific problem it solves is genuinely present in the code.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=design-patterns-structural-csharp

Part 1 of this series (Creational patterns): https://www.techstackblog.com/post.html?slug=design-patterns-creational-csharp

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Design Patterns in C# Part 1: Creational Patterns - Singleton, Factory Method, Builder, and Abstract Factory

Manohari Jayachandran — Mon, 13 Jul 2026 13:19:54 +0000

Design patterns come up constantly in technical interviews, and get explained inconsistently almost everywhere - either as abstract UML diagrams with no real code, or as a wall of all twenty-three GoF (Gang Of Four) patterns covered so shallowly that none of them actually stick.

This is the first post in a three-part series covering the patterns that genuinely come up in interviews and in production code, organized by category, with a consistent format for each: the problem it solves, an analogy, a before-and-after code example, and honest guidance on when it's actually worth the added complexity, not just when it exists as an option.

What a Design Pattern Actually Is

A design pattern is a reusable, named solution to a problem that shows up repeatedly in object-oriented code. It is not a library, not a specific piece of code to copy and paste, and not tied to any single language - it is a shape of solution, described generally enough to apply across many different contexts. Knowing the name of a pattern is genuinely useful in a team setting, because saying "let's use a Factory here" communicates an entire design decision in three words to anyone who already knows what that means.

Design Patterns in C#, Part 1 of 3 — Creational patterns first, Structural and Behavioral to follow. The patterns that actually come up in interviews, not all 23.

The Three Categories

Design patterns traditionally split into three categories. Creational patterns are concerned with how objects get created - Singleton, Factory Method, Abstract Factory, Builder, and Prototype all fall here. Structural patterns are concerned with how objects and classes are composed into larger structures - Adapter, Decorator, Facade, Composite, Proxy, and Bridge fall here. Behavioral patterns are concerned with how objects communicate and share responsibility - Strategy, Observer, Command, State, Template Method, Iterator, and Chain of Responsibility fall here.

This post covers Creational patterns specifically - the four that come up most often in real interviews and real code: Singleton, Factory Method, Builder, and Abstract Factory.

Four creational patterns, four different answers to the same question — how should this object actually get created?

Pattern 1: Singleton

The problem Singleton solves is ensuring a class has exactly one instance throughout the application's lifetime, with a single globally accessible point to reach it - typically for something genuinely singular by nature, like application-wide configuration or a shared connection pool.

Think of a country's government. There is exactly one at a time, and any department that needs to interact with "the government" reaches the same one - there is no mechanism for a second, competing government to exist alongside it. Singleton enforces that same one-and-only-one guarantee in code.

// WITHOUT Singleton - nothing stops multiple instances
public class AppConfiguration
{
    public string ConnectionString { get; set; }
    public AppConfiguration()
    {
        // expensive loading from file/environment
    }
}

// Nothing prevents this - each call creates a
// separate instance, each doing the expensive load again
var config1 = new AppConfiguration();
var config2 = new AppConfiguration();
// config1 and config2 are NOT the same object

// WITH Singleton - exactly one instance, ever
public sealed class AppConfiguration
{
    private static readonly Lazy<AppConfiguration> _instance =
        new(() => new AppConfiguration());

    public static AppConfiguration Instance => _instance.Value;

    public string ConnectionString { get; private set; }

    // private constructor - nobody outside this class
    // can call "new AppConfiguration()"
    private AppConfiguration()
    {
        ConnectionString = LoadFromEnvironment();
    }

    private string LoadFromEnvironment()
        => Environment.GetEnvironmentVariable("DB_CONNECTION")
           ?? "default-connection-string";
}

// Every call anywhere in the app gets the SAME instance
var config = AppConfiguration.Instance;
var sameConfig = AppConfiguration.Instance;
// config and sameConfig ARE the same object

// Lazy<T> makes this thread-safe automatically - two
// threads calling Instance simultaneously will still
// only ever construct ONE AppConfiguration

Singleton is more controversial than most tutorials present it as being. It introduces global state, which makes unit testing genuinely harder - a test that depends on Singleton state can leak that state into the next test, causing flaky, order-dependent failures. In modern C#, dependency injection with a singleton lifetime registration in ASP.NET Core's built-in container achieves the same one-instance guarantee without the static-access downsides - the instance is still created once, but it's injected rather than reached through a static property, which keeps code testable. Reach for the classic Singleton pattern sparingly, and prefer DI-managed singleton lifetime instead whenever a framework already offers it.

Pattern 2: Factory Method

The problem Factory Method solves is creating objects without specifying the exact concrete class in the calling code - letting a subclass, or a parameter, decide which concrete type actually gets instantiated.

Think of a restaurant kitchen. A customer doesn't need to know how a dish is prepared - they order "pasta," and the kitchen decides internally which specific process makes that pasta, while the ordering code never touches the specific preparation steps. Factory Method works the same way: calling code asks for a type of thing, and a factory method decides which concrete class actually fulfills that request.

// WITHOUT Factory Method - calling code is tightly
// coupled to every concrete notification type
public class NotificationSender
{
    public void Send(string type, string message)
    {
        if (type == "Email")
        {
            var email = new EmailNotification();
            email.Send(message);
        }
        else if (type == "SMS")
        {
            var sms = new SmsNotification();
            sms.Send(message);
        }
        // every new notification type means editing
        // this method - an Open/Closed Principle
        // violation as a bonus problem
    }
}

// WITH Factory Method
public abstract class Notification
{
    public abstract void Send(string message);
}

public class EmailNotification : Notification
{
    public override void Send(string message)
        => Console.WriteLine($"Email: {message}");
}

public class SmsNotification : Notification
{
    public override void Send(string message)
        => Console.WriteLine($"SMS: {message}");
}

// The factory method - the one place that knows
// how to create each concrete type
public abstract class NotificationCreator
{
    public abstract Notification CreateNotification();

    // Template-style usage of the factory method
    public void Notify(string message)
    {
        var notification = CreateNotification();
        notification.Send(message);
    }
}

public class EmailNotificationCreator : NotificationCreator
{
    public override Notification CreateNotification()
        => new EmailNotification();
}

public class SmsNotificationCreator : NotificationCreator
{
    public override Notification CreateNotification()
        => new SmsNotification();
}

// Calling code depends only on the abstraction
NotificationCreator creator = new EmailNotificationCreator();
creator.Notify("Your order has shipped");

// Adding a new notification type = one new class.
// Nothing that already works needs to change.

Factory Method earns its place once there are genuinely multiple concrete types that share a common interface, and the decision of which one to create needs to stay flexible or extensible. For a fixed, small, unchanging set of two types that will realistically never grow, a simple if/else or switch statement can actually be more readable - the same tradeoff covered in an earlier Open/Closed Principle post applies here: the pattern pays off once new cases keep appearing, not automatically from day one.

Pattern 3: Builder

The problem Builder solves is constructing a complex object step by step, particularly one with many optional parameters, without resorting to a constructor with an unreadable number of positional arguments.

Think of ordering a custom sandwich at a deli. Nobody hands the person behind the counter a single sentence listing every possible ingredient in a fixed order, half of them "none." Instead, each choice gets specified step by step - bread, then protein, then toppings, then whether to toast it - and the sandwich comes together incrementally. Builder applies that same step-by-step, readable construction to objects with a lot of optional configuration.

// WITHOUT Builder - the classic "telescoping
// constructor" problem
public class Report
{
    public Report(string title, string subtitle,
        string author, bool includeCharts,
        string footer, bool includePageNumbers,
        string watermark, string format)
    {
        // ... assign all eight fields
    }
}

// What does "true, null, false" mean here?
// Nobody can tell without checking the constructor
var report = new Report(
    "Q4 Report", null, null, true,
    null, false, null, "PDF"
);

// WITH Builder - readable at the call site
public class Report
{
    public string Title { get; set; }
    public string Subtitle { get; set; }
    public string Author { get; set; }
    public bool IncludeCharts { get; set; }
    public string Format { get; set; }
}

public class ReportBuilder
{
    private readonly Report _report = new();

    public ReportBuilder WithTitle(string title)
    {
        _report.Title = title;
        return this;
    }

    public ReportBuilder WithSubtitle(string subtitle)
    {
        _report.Subtitle = subtitle;
        return this;
    }

    public ReportBuilder WithAuthor(string author)
    {
        _report.Author = author;
        return this;
    }

    public ReportBuilder IncludeCharts()
    {
        _report.IncludeCharts = true;
        return this;
    }

    public ReportBuilder AsFormat(string format)
    {
        _report.Format = format;
        return this;
    }

    public Report Build() => _report;
}

// Every line self-documents what is being set -
// no positional guessing required
var report = new ReportBuilder()
    .WithTitle("Q4 Report")
    .WithAuthor("Manohari")
    .IncludeCharts()
    .AsFormat("PDF")
    .Build();

Builder earns its place once an object has enough optional fields that a constructor becomes genuinely hard to read at the call site - a rough rule of thumb is four or more optional parameters. C#'s object initializer syntax already solves much of this same problem natively for simple cases, so Builder's real value shows up when construction needs actual step-by-step logic, validation between steps, or a fluent API that guides the caller through a specific required sequence - not just as a fancier way to set properties that object initializers already handle well.

Pattern 4: Abstract Factory

The problem Abstract Factory solves is creating families of related objects that need to stay consistent with each other, without the calling code specifying their concrete classes directly.

Think of furnishing a room in a specific style - Victorian or Modern. Choosing "Victorian" should consistently produce a Victorian chair, a Victorian table, and a Victorian lamp together, not a Victorian chair paired with a Modern lamp by accident. Abstract Factory guarantees that an entire family of related objects stays consistent, because one factory is responsible for the whole family rather than each piece being created independently.

// The abstract product interfaces
public interface IButton
{
    void Render();
}

public interface ICheckbox
{
    void Render();
}

// Concrete products - Windows family
public class WindowsButton : IButton
{
    public void Render() => Console.WriteLine("Windows button");
}

public class WindowsCheckbox : ICheckbox
{
    public void Render() => Console.WriteLine("Windows checkbox");
}

// Concrete products - macOS family
public class MacButton : IButton
{
    public void Render() => Console.WriteLine("Mac button");
}

public class MacCheckbox : ICheckbox
{
    public void Render() => Console.WriteLine("Mac checkbox");
}

// The abstract factory - produces a FAMILY of
// related products
public interface IUiFactory
{
    IButton CreateButton();
    ICheckbox CreateCheckbox();
}

public class WindowsUiFactory : IUiFactory
{
    public IButton CreateButton() => new WindowsButton();
    public ICheckbox CreateCheckbox() => new WindowsCheckbox();
}

public class MacUiFactory : IUiFactory
{
    public IButton CreateButton() => new MacButton();
    public ICheckbox CreateCheckbox() => new MacCheckbox();
}

// Calling code depends only on IUiFactory - it never
// touches WindowsButton or MacButton directly, and it
// is IMPOSSIBLE to accidentally mix a Windows button
// with a Mac checkbox
public class Application
{
    private readonly IUiFactory _factory;

    public Application(IUiFactory factory)
        => _factory = factory;

    public void RenderUi()
    {
        var button = _factory.CreateButton();
        var checkbox = _factory.CreateCheckbox();
        button.Render();
        checkbox.Render();
    }
}

// Swapping the entire family is one line
var app = new Application(new WindowsUiFactory());
app.RenderUi();
// "Windows button" and "Windows checkbox" - guaranteed
// to always be a matched pair

Abstract Factory is worth the added complexity specifically when there are genuinely multiple related products that must be created together consistently, and multiple families of that same set exist - Windows versus Mac UI components, or different cloud provider SDKs behind a common interface, are realistic examples. For a single product with no "family" concept at all, that's Factory Method's job instead - reaching for Abstract Factory when Factory Method would do is a common source of unnecessary complexity in real codebases.

Factory Method vs Abstract Factory

This is the distinction that trips people up most often. Factory Method creates one product, and subclassing decides which concrete type gets created. Abstract Factory creates a family of related products, and composition - injecting a specific factory - decides which family, while guaranteeing the products within that family stay consistent with each other.

A useful test for telling them apart: if adding a new "thing" means adding one new method to create it, that's Factory Method territory. If adding a new "thing" means several related objects need to be created together and stay consistent, that's Abstract Factory territory.

Key Lessons

Singleton guarantees exactly one instance, but introduces global state that makes unit testing harder - prefer DI-managed singleton lifetime over the classic static-access pattern wherever a framework already offers it.

Factory Method decouples calling code from concrete types, and pays off once new types keep getting added - a fixed, small, unchanging set may not need it at all.

Builder solves the telescoping constructor problem for objects with many optional parameters, though object initializer syntax already covers simpler cases natively in C#.

Abstract Factory guarantees a family of related objects stays consistent with each other, and is worth reaching for only when there genuinely are multiple related products and multiple families - not for a single product with no family concept.

Every pattern covered here has a real cost in added complexity and indirection, and that cost should be weighed against the actual problem being solved rather than applied by default just because the pattern exists.

What's Next

Part 2 of this series covers Structural patterns - Adapter, Decorator, Facade, and Composite - the patterns concerned with how objects and classes combine into larger structures. Part 3 covers Behavioral patterns - Strategy, Observer, Command, State, and Template Method - the patterns concerned with how objects communicate and share responsibility with each other.

Summary

Creational patterns solve one consistent underlying question - how should an object actually get created - in four different ways depending on the specific shape of the problem. Singleton guarantees exactly one instance. Factory Method lets a subclass decide the concrete type. Builder makes complex, optional-heavy construction readable. Abstract Factory guarantees an entire family of related objects stays consistent. None of these patterns is free - each adds a layer of indirection that only pays for itself once the problem it solves is actually present in the code, not preemptively.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=design-patterns-creational-csharp

More from TechStack Blog: CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Azure Monitoring in Practice: Application Insights and the KQL Queries

Manohari Jayachandran — Fri, 10 Jul 2026 14:05:12 +0000

The first Application Insights post on this blog the App Insights post covered what it is and how to wire it up - the setup half. This post covers the other half, the one most tutorials skip: what to actually type into the query box once something is broken and there are three minutes to find out why. KQL was used for exactly this kind of troubleshooting and reporting on an Azure integration platform at Blue Yonder - these are the queries that got real use in production, not a generic KQL syntax tour.

The Tables That Matter

Application Insights stores telemetry across several tables, and nearly every troubleshooting query starts by picking one of them and filtering or aggregating it. The requests table holds every incoming HTTP request, success or failure, with duration. The dependencies table holds every outgoing call an application makes - database calls, external API calls, storage calls. The exceptions table holds unhandled exceptions along with their stack traces. The traces table holds custom log messages, typically whatever gets written through ILogger. The customEvents table holds custom application events defined by the developer.

Query 1: Failed Requests by Status Code

The first question after "something is broken" is almost always "what is actually failing, and how often."

requests
| where timestamp > ago(1h)
| where success == false
| summarize FailureCount = count() by resultCode, name
| order by FailureCount desc

This query looks at the last hour of requests, filters down to only the failed ones, and groups the results by both status code and operation name together. Grouping by operation name matters here specifically, because "500 errors" alone doesn't say which endpoint is actually failing - two completely different endpoints could both be throwing 500s for entirely unrelated reasons, and lumping them together hides that. Sorting by failure count descending puts the most frequent problem at the top of the results. This is the query worth running first, every time, because it tells you where to look next rather than requiring a guess.

Query 2: Slow Requests Using Percentile, Not a Flat Threshold

A common mistake is filtering for "requests over one second" as if that number means the same thing for every endpoint in an application. A percentile-based query finds genuine outliers relative to each endpoint's own normal behavior instead of applying one arbitrary number across everything.

requests
| where timestamp > ago(1h)
| summarize
    P50 = percentile(duration, 50),
    P95 = percentile(duration, 95),
    P99 = percentile(duration, 99),
    Count = count()
  by name
| order by P95 desc

This groups requests by operation name and calculates the 50th, 95th, and 99th percentile duration for each one, then sorts so the endpoints with the worst tail latency appear first. The reasoning behind using percentiles instead of a flat threshold is worth spelling out: an endpoint that is normally 200 milliseconds and occasionally spikes to 800 milliseconds has a real P95 problem worth investigating, since something is clearly going wrong some percentage of the time. An endpoint that is normally 900 milliseconds and stays consistently there might simply be a naturally heavier operation by design, not necessarily broken at all. A flat "over one second" filter cannot distinguish between these two very different situations, but percentile-based analysis can.

Query 3: Grouping Exceptions So Ten Thousand Rows Become Five Problems

exceptions
| where timestamp > ago(24h)
| summarize
    Count = count(),
    LastSeen = max(timestamp)
  by type, outerMessage
| order by Count desc
| take 20

This groups every exception by its type and message together, rather than by type alone - a NullReferenceException thrown in one method represents a genuinely different problem than the same exception type thrown somewhere else entirely, and grouping by type alone would incorrectly merge those into one bucket. The query counts how many times each distinct problem occurred and shows the most recent occurrence, which tells you whether something is actively happening right now or happened once several days ago and hasn't recurred since. Limiting the result to the top twenty is usually more than sufficient to surface the real problems. A full day of production exceptions is often thousands of individual rows that collapse down to five or six genuinely distinct issues once grouped this way - scrolling through raw exception rows one at a time is a dramatically slower way to arrive at the same information.

Query 4: Isolating Dependency Failures From Application Failures

This is the query that saves the most real debugging time in practice. A dependency failure and an application failure look identical from the outside - an API simply returned an error either way - and this query is what actually tells the two apart.

dependencies
| where timestamp > ago(1h)
| where success == false
| summarize FailureCount = count() by target, type, resultCode
| order by FailureCount desc

This looks specifically at outgoing calls an application made - not requests coming into the application, but calls going out to something else - and groups them by which target system was called, what kind of dependency it was (SQL, HTTP, Azure Storage, and so on), and the result code returned. This surfaces failures that were actually caused by something being called, rather than a bug in the calling code itself. In a real production troubleshooting scenario, an API endpoint returning 500 errors looks identical whether the underlying bug lives in the endpoint's own code or in a downstream system that endpoint depends on. Running this dependency query alongside the failed-requests query from earlier immediately reveals whether request failures line up in time with a dependency also failing during that same window - if an external system's API was returning errors during that exact period, the actual problem was never in the calling application's code at all.

Query 5: Joining Requests and Dependencies to Trace a Specific Failure

requests
| where timestamp > ago(1h)
| where success == false
| where name == "POST /api/orders"
| join kind=inner (
    dependencies
    | where success == false
  ) on operation_Id
| project
    timestamp,
    requestName = name,
    dependencyTarget = target,
    dependencyType = type,
    resultCode1

This takes failed requests to one specific endpoint and joins them to any failed dependency calls that occurred as part of that same request, using operation_Id - a shared identifier that links a request to everything it triggered downstream. The result shows exactly which downstream call failed for each individual failed request. This is the query for the specific situation of "this one endpoint is failing, and I need to know exactly what it's calling that's actually breaking" - joining on operation_Id this way is considerably faster than manually correlating timestamps across two separate query results by hand.

Query 6: A Basic Availability Percentage Over a Rolling Window

requests
| where timestamp > ago(24h)
| summarize
    Total = count(),
    Failed = countif(success == false)
| extend AvailabilityPercent =
    round(100.0 * (Total - Failed) / Total, 2)
| project Total, Failed, AvailabilityPercent

This counts total requests and failed requests over a 24-hour window and calculates a simple availability percentage from the two. It works well as a quick sanity check before diving into the more detailed queries above - answering the basic question of whether this is a minor blip or a genuine outage before spending time on deeper investigation. Extending this into a day-over-day trend is a small change: wrapping the same logic in a bin(timestamp, 1d) grouping instead of a single flat summarize produces a daily trend line instead of one static number.

A Starter Query for a Custom Dashboard

requests
| where timestamp > ago(7d)
| summarize
    RequestCount = count(),
    FailureCount = countif(success == false),
    P95Duration = percentile(duration, 95)
  by bin(timestamp, 1h), name
| order by timestamp desc

This is the query behind a genuinely useful monitoring dashboard panel - request volume, failure count, and P95 latency, bucketed hourly, broken down per endpoint, over the last week. Pinning this result as a chart on an Azure Dashboard turns it into a real at-a-glance health view rather than something that has to be remembered and manually queried whenever a concern comes up.

Key Lessons

Starting troubleshooting with the failed-requests query is worth doing as a habit, since it points toward where to look next rather than requiring a guess about where the problem might be.

Percentile-based duration queries find genuine outliers in a way a flat threshold like "over one second" simply cannot, because a flat number has no way to distinguish a real problem from an endpoint that is naturally heavier by design.

Grouping exceptions by type and message together, rather than type alone, is what actually collapses a large volume of raw exception rows into a handful of real, distinct problems worth investigating.

Dependency failures and application failures look identical from the outside, and querying the dependencies table specifically, rather than assuming the bug lives in application code, is what tells the two apart.

operation_Id is the key that links a request to every dependency call it triggered, which is what turns a vague "this endpoint is failing" into a specific, actionable "this endpoint is failing because of this particular downstream call."

Summary

Wiring up Application Insights is the easy half of the work. Knowing what to actually query once something breaks is the skill that matters in day-to-day practice. These six queries cover situations that come up constantly in real production troubleshooting - failed requests, slow requests, grouped exceptions, dependency failures, tracing one specific failure end to end, and a basic availability check. Keeping a working version of each one saved somewhere accessible, ready to paste in and adjust the time window, turns "something is broken, where do I even start" into a noticeably shorter investigation.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-monitoring-kql-queries

Related reading on TechStack Blog: https://www.techstackblog.com/post.html?slug=azure-app-insights-deep-dive

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

Azure Service Bus: Topics, Subscriptions, and Dead Letter Queues

Manohari Jayachandran — Fri, 10 Jul 2026 01:41:32 +0000

Azure Service Bus is an enterprise-grade cloud messaging service. It decouples applications so they do not need to be online at the same time to communicate. Instead of calling each other directly, services send messages to Service Bus and other services pick them up when ready. Service Bus was used extensively at Blue Yonder to connect Logic Apps, Function Apps, and external systems like Salesforce and ServiceNow - it was the backbone of every reliable integration built there.

Why Messaging Instead of Direct API Calls

A direct API call creates tight coupling: System A calls System B over HTTP, and if B is down, A fails immediately; if B is slow, A waits and blocks. Service Bus replaces that direct call with loose coupling instead - System A sends a message to Service Bus, and System B reads it whenever it's ready. This means B can be temporarily down and the message simply waits safely, A never blocks since it's fire-and-forget, multiple systems can read the same message independently, and every message leaves a full audit trail.

Service Bus core concepts — a queue for one consumer, a topic that fans out to multiple independent subscriptions, and a dead-letter queue for anything that fails repeatedly.

Queues vs Topics

A queue is one sender, one receiver - a message goes in one end, exactly one consumer reads it, and once read the message is gone. This fits scenarios where one system should process each message exactly once, like an Order Service sending work to a Fulfillment Service through a queue, where each order gets processed by exactly one worker.

A topic is one sender, many receivers - a message is published once, and every subscriber attached to that topic gets their own independent copy. This fits scenarios where multiple systems need to react to the same event, like an Order Service publishing to a topic where an Inventory subscriber, a Notification subscriber, and an Analytics subscriber each independently receive the same order event.

Subscriptions and Filters

Each topic subscription can have filters so it only receives the messages it actually cares about, which is extremely powerful for routing in enterprise integrations. On a topic named order-events, a subscription called high-priority-orders might filter on Priority equals High and receive only high priority orders. A subscription called international-orders might filter on Region not equal to US and receive only non-US orders. A subscription called all-orders with no filter at all receives every single order event published to that topic.

Dead Letter Queue

The Dead Letter Queue, or DLQ, is one of the most important concepts in Service Bus. When a message cannot be processed successfully after the maximum number of retries, Service Bus automatically moves it to the DLQ instead of losing it forever.

In the normal flow, a producer sends a message to a queue, the consumer processes it successfully, and the message is deleted after that successful processing. In the failed message flow, a producer sends a message, the consumer throws an exception, retry one fails, retry two fails, retry three fails and hits the maximum retry count, and the message is then moved to the Dead Letter Queue while the original queue becomes unblocked for everything behind it. The DLQ itself lives at a predictable path - for a queue named myqueue, the dead letter path is myqueue/$DeadLetterQueue.

This matters enormously in production for several concrete reasons: messages are never silently lost, failed messages do not block healthy messages behind them in the queue, the exact failure can be inspected directly, the underlying issue can be fixed and the message reprocessed, and there's a full audit trail available for compliance purposes.

Sending Messages in C

var client = new ServiceBusClient(connectionString);
var sender = client.CreateSender("order-topic");

var message = new ServiceBusMessage(
    JsonSerializer.Serialize(new {
        OrderId = "ORD-001",
        Priority = "High",
        Region = "EU"
    })
);

message.Subject = "OrderCreated";
message.ApplicationProperties["Priority"] = "High";
message.ApplicationProperties["Region"] = "EU";
message.MessageId = Guid.NewGuid().ToString();

await sender.SendMessageAsync(message);

Receiving Messages in C

var processor = client.CreateProcessor("myqueue");

processor.ProcessMessageAsync += async args =>
{
    var body = args.Message.Body.ToString();
    var order = JsonSerializer.Deserialize(body);

    await ProcessOrderAsync(order);

    // Tell Service Bus: processed successfully
    // Service Bus deletes it from the queue
    await args.CompleteMessageAsync(args.Message);
};

processor.ProcessErrorAsync += async args =>
{
    Console.WriteLine("Error: " + args.Exception);
    // Message automatically retried then dead-lettered
};

await processor.StartProcessingAsync();

The ProcessMessageAsync handler receives each message, processes it, and calls CompleteMessageAsync to tell Service Bus the message was handled successfully so it gets removed from the queue. The ProcessErrorAsync handler catches processing failures - Service Bus handles the retry logic automatically and moves the message to the dead letter queue once retries are exhausted, without any extra code required to make that happen.

Reading from the Dead Letter Queue

var receiver = client.CreateReceiver(
    "myqueue",
    new ServiceBusReceiverOptions {
        SubQueue = SubQueue.DeadLetter
    }
);

var messages = await receiver.ReceiveMessagesAsync(10);
foreach (var msg in messages)
{
    Console.WriteLine("DLQ Message: " + msg.Body);
    Console.WriteLine("Reason: " + msg.DeadLetterReason);
    Console.WriteLine("Error: " + msg.DeadLetterErrorDescription);

    // Fix the issue then complete or resubmit
    await receiver.CompleteMessageAsync(msg);
}

Setting SubQueue to SubQueue.DeadLetter on the receiver options points that receiver specifically at the dead letter queue rather than the main queue. Each dead-lettered message carries a DeadLetterReason and a DeadLetterErrorDescription, which together explain exactly why that message failed - genuinely useful information when deciding whether to fix and resubmit it or discard it entirely.

Message Sessions - Ordered Processing

Sessions guarantee that messages sharing the same SessionId are processed in order by the same consumer, which is critical for workflows where order genuinely matters. Setting message.SessionId to a customer ID means all messages for that same customer route to the same session, get processed in order by the same consumer instance, while other consumers handle other customers' sessions entirely in parallel. At Blue Yonder, this pattern was used with SessionId set to an IntegrationFlowId, so all messages belonging to one integration run were processed in sequence by the same Logic App instance rather than potentially arriving out of order.

Service Bus with Logic Apps

This is the most common pattern in enterprise Azure integration - a Logic App triggers on new Service Bus messages and orchestrates the workflow from there. In a typical pattern, a Logic App triggers when a message is received on a queue named incoming-orders, then parses the message body, checks a condition on the Priority field, calls the ServiceNow API based on that condition, and finally completes the message to remove it from the queue.

A second common pattern is fan-out with topics: a Logic App publishes a single message to a topic, and three separate subscriptions each trigger their own independent Logic App - one for inventory, one for notifications, one for analytics - all reacting to that same published message without any of them needing to know about the others.

Monitoring Service Bus

In the Azure Portal, under a Service Bus namespace and the specific queue or topic, the key metrics worth watching are Active Messages (waiting to be processed), Dead Letter Count (failed messages needing investigation), Incoming Messages (the rate messages are arriving), and Outgoing Messages (the rate messages are being processed). Sensible alert thresholds worth setting are a Dead Letter Count greater than zero, and Active Messages greater than some reasonable backlog threshold like 1000, depending on expected normal volume.

Service Bus vs Storage Queue

Service Bus is the right choice for enterprise messaging that needs ordering guarantees, topics and subscriptions, sessions, transactions, or dead lettering, and for anything connecting to Logic Apps or Function Apps. Storage Queue is the right choice for a simple task queue, very high volume at the lowest possible cost, where basic retry behavior is genuinely enough and none of Service Bus's richer features are actually needed.

Key Lessons From Production

Check the Dead Letter Queue daily in production - it's the single most reliable early warning signal that something is going wrong.
Set MessageId explicitly to prevent duplicate processing of the same logical message.
Use CorrelationId to trace a single message's journey across multiple connected systems.
Topics with subscriptions consistently beat maintaining multiple separate queues for the same kind of fan-out scenario.
Sessions are essential specifically when the order of processing matters - skipping them in an order-sensitive workflow is a common source of subtle bugs.
Store connection strings in Key Vault, never directly in code.
Use the Standard tier for development and the Premium tier for production workloads needing VNET isolation.

Summary

Azure Service Bus is the most reliable way to connect distributed systems on Azure. Queues handle point-to-point delivery, Topics handle publish-subscribe delivery to multiple independent consumers, Dead Letter Queues ensure a message is never silently lost, and Sessions provide ordered processing when sequence genuinely matters. Combined with Logic Apps and Function Apps, these pieces form the complete Azure integration stack that real enterprise systems are built on.

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

SOLID Principles Explained: The Five Rules That Make Code Easier to Change

Manohari Jayachandran — Wed, 08 Jul 2026 14:44:11 +0000

SOLID is five design principles that show up in nearly every senior software engineering interview, and gets asked about far more often than it gets properly explained. Most explanations state what each letter stands for and move on. This post goes one level deeper for each principle: the plain-English meaning, an analogy, a real C# example of the violation, and the refactored fix - the actual code smell each principle is designed to catch, not just the definition.

SOLID applies to any object-oriented language. The examples here are in C#, but the underlying reasoning transfers directly to Java, TypeScript, Python, or anything else built around classes and interfaces.

S — Single Responsibility Principle

A class should have one reason to change.

This is commonly misquoted as "a class should do one thing" or "a class should have one method," which is not quite right and leads to unnecessarily fragmented code. A class can have several methods and still follow this principle perfectly well, as long as every method exists to serve one single, cohesive responsibility. The actual test is: if a change request comes in, does it map to exactly one reason, or could two unrelated business changes both force an edit to the same class for
completely different reasons?

Think of a restaurant kitchen. A single station handles one job - the grill station only grills, the salad station only assembles salads. If one station tried to grill, plate desserts, and manage the wine list all at once, changing how desserts are plated would risk breaking something on the grill line, even though the two have nothing to do with each other. Single Responsibility is keeping each station focused on the one thing that station is actually responsible for.

The violation, and why it hurts:

// Violates SRP - this class has at least three
// separate reasons to change: how an invoice is
// calculated, how it's formatted for printing, and
// how it's saved to the database
public class Invoice
{
    public decimal CalculateTotal(List<LineItem> items)
    {
        return items.Sum(i => i.Price * i.Quantity);
    }

    public string FormatForPrint(Invoice invoice)
    {
        return $"Invoice Total: ${invoice.Total:F2}\n" +
               $"Items: {invoice.Items.Count}";
    }

    public void SaveToDatabase(Invoice invoice)
    {
        // direct SQL connection code here
        using var connection = new SqlConnection(_connString);
        connection.Open();
        // ... save logic
    }
}

// A change to the print FORMAT (marketing wants a new
// receipt layout) has no business relationship to a
// change in how totals are CALCULATED, or how invoices
// are SAVED - but all three live in one class, and a
// bug introduced while editing one can silently break
// the others

The fix - separating by actual reason to change:

// Each class now has exactly one reason to change
public class InvoiceCalculator
{
    public decimal CalculateTotal(List<LineItem> items)
    {
        return items.Sum(i => i.Price * i.Quantity);
    }
}

public class InvoicePrinter
{
    public string FormatForPrint(Invoice invoice)
    {
        return $"Invoice Total: ${invoice.Total:F2}\n" +
               $"Items: {invoice.Items.Count}";
    }
}

public class InvoiceRepository
{
    private readonly string _connString;

    public InvoiceRepository(string connString)
    {
        _connString = connString;
    }

    public void Save(Invoice invoice)
    {
        using var connection = new SqlConnection(_connString);
        connection.Open();
        // ... save logic
    }
}

// A print format change now only touches InvoicePrinter.
// A calculation change now only touches InvoiceCalculator.
// Neither can accidentally break the other.

O — Open/Closed Principle

Software entities should be open for extension, but closed for modification.

New behavior should be addable without editing code that already works and is already tested. The most common real violation is a growing switch statement or if/else chain that needs a new branch every time a new case shows up - each new case means reopening code that was previously finished, tested, and working, with the risk of breaking an existing case while adding a new one.

Think of a power strip. Adding a new device means plugging it into an open socket - it does not require opening up the strip itself and rewiring it. The strip is "closed" against modification but "open" for extension through its sockets. Every new case in a growing switch statement is the equivalent of opening the power strip itself just to add one more device.

The violation:

// Every new discount type means editing this method
// and re-testing every existing case along with it
public class DiscountCalculator
{
    public decimal ApplyDiscount(string discountType,
        decimal amount)
    {
        switch (discountType)
        {
            case "Percentage":
                return amount * 0.9m;
            case "FixedAmount":
                return amount - 10m;
            case "BuyOneGetOne":
                return amount * 0.5m;
            // Adding "LoyaltyPoints" discount next month
            // means opening this method again
            default:
                return amount;
        }
    }
}

The fix - polymorphism instead of branching:

public interface IDiscount
{
    decimal Apply(decimal amount);
}

public class PercentageDiscount : IDiscount
{
    private readonly decimal _percentage;
    public PercentageDiscount(decimal percentage)
        => _percentage = percentage;

    public decimal Apply(decimal amount)
        => amount * (1 - _percentage);
}

public class FixedAmountDiscount : IDiscount
{
    private readonly decimal _amount;
    public FixedAmountDiscount(decimal amount)
        => _amount = amount;

    public decimal Apply(decimal amount)
        => amount - _amount;
}

public class BuyOneGetOneDiscount : IDiscount
{
    public decimal Apply(decimal amount) => amount * 0.5m;
}

// Adding LoyaltyPointsDiscount next month means writing
// ONE NEW CLASS. Nothing that already works gets touched.
public class LoyaltyPointsDiscount : IDiscount
{
    private readonly int _points;
    public LoyaltyPointsDiscount(int points) => _points = points;

    public decimal Apply(decimal amount)
        => amount - (_points * 0.01m);
}

public class DiscountCalculator
{
    public decimal ApplyDiscount(IDiscount discount,
        decimal amount)
        => discount.Apply(amount);
}

// Usage
var calculator = new DiscountCalculator();
var total = calculator.ApplyDiscount(
    new PercentageDiscount(0.1m), 100m);  // 90

L — Liskov Substitution Principle

Objects of a superclass should be replaceable with objects of any subclass without breaking the correctness of the program.

This is the SOLID principle most explanations get slightly wrong by stopping at "subclasses should properly inherit from their base class." The actual requirement is stricter: code written against the base type must behave correctly no matter which specific subtype it actually receives at runtime, without needing to know or check which one it got.

Think of a universal remote's power button. Pressing "power" should turn on whatever device the remote is paired with - a TV, a soundbar, a projector - without the person pressing the button needing to know or care which device it actually is. If pressing power on one particular device did something completely unexpected (muted the volume instead of turning on), that device would violate the substitution expectation, even if it technically "inherited" from the same remote-compatible interface.

The classic violation - Square inheriting from Rectangle:

public class Rectangle
{
    public virtual int Width  { get; set; }
    public virtual int Height { get; set; }

    public int Area() => Width * Height;
}

// Looks reasonable - a Square IS-A Rectangle
// mathematically, so inheritance seems natural
public class Square : Rectangle
{
    public override int Width
    {
        get => base.Width;
        set { base.Width = value; base.Height = value; }
    }

    public override int Height
    {
        get => base.Height;
        set { base.Height = value; base.Width = value; }
    }
}

// This code is written against Rectangle and expects
// setting Width and Height independently to work
public void Resize(Rectangle rect)
{
    rect.Width = 5;
    rect.Height = 10;

    // For a real Rectangle: Area() == 50, as expected
    // For a Square substituted in: setting Height also
    // silently changed Width, so Area() == 100, NOT 50

    Console.WriteLine(rect.Area());
}

// Passing a Square here breaks the caller's expectation
// silently - this is a genuine LSP violation, even
// though Square "inherited properly" in a syntax sense
Resize(new Square());

The fix - do not force an inheritance relationship where
the substitution guarantee cannot actually hold:

// Model the actual shared behavior via an interface
// rather than forcing Square to inherit from Rectangle
public interface IShape
{
    int Area();
}

public class Rectangle : IShape
{
    public int Width  { get; set; }
    public int Height { get; set; }
    public int Area() => Width * Height;
}

public class Square : IShape
{
    public int Side { get; set; }
    public int Area() => Side * Side;
}

// Code written against IShape only ever calls Area(),
// so both types can be substituted safely - there is
// no independent Width/Height setter contract to violate
public void PrintArea(IShape shape)
{
    Console.WriteLine(shape.Area());
}

PrintArea(new Rectangle { Width = 5, Height = 10 }); // 50
PrintArea(new Square { Side = 5 });                   // 25

I — Interface Segregation Principle

No client should be forced to depend on methods it does not use.

Fat interfaces - ones with many methods bundled together - quietly punish every class that implements them, even implementations that only ever need a small subset of those methods. The usual symptom is a method body that throws NotImplementedException or does nothing, purely to satisfy an interface contract that does not actually apply to that implementer.

Think of a Swiss Army knife with fifteen tools bolted into one handle. If someone only ever needs the blade, they still carry the weight and bulk of the corkscrew, the saw, and the toothpick, whether or not those tools are ever used. Interface Segregation is choosing to carry several small, purpose-built tools instead, so nobody carries functionality they never asked for.

The violation:

// One fat interface trying to cover every worker type
public interface IWorker
{
    void Work();
    void Eat();
    void Sleep();
}

public class HumanWorker : IWorker
{
    public void Work()  => Console.WriteLine("Working");
    public void Eat()   => Console.WriteLine("Eating lunch");
    public void Sleep() => Console.WriteLine("Resting");
}

// A robot worker is forced to implement Eat() and
// Sleep(), neither of which makes any sense for it
public class RobotWorker : IWorker
{
    public void Work() => Console.WriteLine("Working");

    public void Eat()
        => throw new NotImplementedException(
            "Robots don't eat");

    public void Sleep()
        => throw new NotImplementedException(
            "Robots don't sleep");
}

// Any code calling Eat() or Sleep() on an IWorker
// now risks a runtime exception depending on which
// concrete type it actually received

The fix - smaller, purpose-specific interfaces:

public interface IWorkable { void Work();  }
public interface IFeedable { void Eat();   }
public interface ISleepable { void Sleep(); }

// Human implements all three - genuinely needs all three
public class HumanWorker : IWorkable, IFeedable, ISleepable
{
    public void Work()  => Console.WriteLine("Working");
    public void Eat()   => Console.WriteLine("Eating lunch");
    public void Sleep() => Console.WriteLine("Resting");
}

// Robot implements only what actually applies to it -
// no forced empty or throwing implementations
public class RobotWorker : IWorkable
{
    public void Work() => Console.WriteLine("Working");
}

// Code that only cares about work capability depends
// only on IWorkable - it never even knows Eat() or
// Sleep() exist as concepts, and neither implementer
// is forced to fake behavior it doesn't have
public void AssignTask(IWorkable worker)
{
    worker.Work();
}

AssignTask(new HumanWorker());
AssignTask(new RobotWorker());

D — Dependency Inversion Principle

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

This is the principle behind nearly every "inject an interface, not a concrete class" pattern in modern software. Without it, high-level business logic ends up directly wired to specific low-level implementation details - a specific database, a specific email provider, a specific file system - and swapping any of those out later means editing the high-level code itself.

Think of a wall power socket. A lamp does not wire itself directly into the electrical grid's specific generator - it plugs into a standard socket, and the socket is the abstraction that both the lamp (high-level) and the power plant (low-level) depend on. The lamp works identically whether the electricity behind that socket comes from a coal plant, a solar farm, or a generator - because neither side depends on the other directly, both depend on the socket standard.

The violation:

// OrderService (high-level business logic) is directly
// wired to SqlOrderRepository (a low-level, specific
// implementation detail)
public class SqlOrderRepository
{
    public void Save(Order order)
    {
        // direct SQL Server specific code
    }
}

public class OrderService
{
    private readonly SqlOrderRepository _repository;

    public OrderService()
    {
        // OrderService is now permanently wired to
        // SQL Server specifically - switching to
        // Cosmos DB later means editing THIS class
        _repository = new SqlOrderRepository();
    }

    public void PlaceOrder(Order order)
    {
        // business logic
        _repository.Save(order);
    }
}

The fix - both sides depend on an abstraction instead:

// The abstraction both sides depend on
public interface IOrderRepository
{
    void Save(Order order);
}

// Low-level detail depends on the abstraction
public class SqlOrderRepository : IOrderRepository
{
    public void Save(Order order)
    {
        // SQL Server specific code
    }
}

// A second implementation can be added without
// touching OrderService at all
public class CosmosOrderRepository : IOrderRepository
{
    public void Save(Order order)
    {
        // Cosmos DB specific code
    }
}

// High-level module now depends only on the abstraction,
// not on any specific low-level implementation
public class OrderService
{
    private readonly IOrderRepository _repository;

    // The concrete implementation is injected from
    // outside - OrderService never needs to know or
    // care which one it actually received
    public OrderService(IOrderRepository repository)
    {
        _repository = repository;
    }

    public void PlaceOrder(Order order)
    {
        // business logic
        _repository.Save(order);
    }
}

// Usage - swap the implementation with zero changes
// to OrderService itself
var sqlService = new OrderService(new SqlOrderRepository());
var cosmosService = new OrderService(new CosmosOrderRepository());

This is exactly the mechanism behind ASP.NET Core's built-in dependency injection container - registering IOrderRepository against a concrete implementation in Program.cs, then having it injected automatically into
any constructor that asks for the interface, is Dependency Inversion applied at the framework level.

How the Five Principles Reinforce Each Other

These principles are not five unrelated rules - they support each other in practice. A class that violates Single Responsibility is often also harder to keep Open/Closed, because a class doing several unrelated things tends to need modification for more unrelated reasons. A fat interface that violates Interface Segregation often also makes Liskov Substitution harder to guarantee, because implementers are forced to fake methods that don't genuinely apply to them, and code depending on the interface can no longer trust that every implementation behaves consistently. Dependency Inversion is frequently what makes Open/Closed actually achievable in real code - injecting an interface is what allows new behavior to be added by writing a new implementation rather than modifying existing code.

Key Lessons

Single Responsibility is about one reason to change, not one method - a class can have several methods and still be well-designed if they all serve the same responsibility.
Open/Closed is most often violated by a growing switch statement or if/else chain - polymorphism through an interface is the standard fix.
Liskov Substitution requires that code written against a base type work correctly with any subtype, without needing to check which one it got - the classic Square/Rectangle example shows how syntactically correct inheritance can still violate this.
Interface Segregation is violated by fat interfaces that force implementers to fake methods that don't apply to them - smaller, purpose-specific interfaces are the fix.
Dependency Inversion is the reasoning behind constructor injection of interfaces rather than concrete classes - both high-level and low-level code depend on the same abstraction, and neither depends on the other directly.

Summary

SOLID is five related principles for keeping object-oriented code changeable without breaking what already works. Single Responsibility limits what forces a class to change. Open/Closed enables new behavior without editing tested code. Liskov Substitution ensures polymorphism is actually trustworthy rather than just syntactically valid. Interface Segregation prevents fat interfaces from forcing fake implementations. Dependency Inversion decouples high-level logic from low-level details through shared abstractions. Understanding the specific code smell each principle is designed to catch - not just the acronym - is what makes the difference between reciting SOLID in an interview and actually applying it in a real codebase.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=solid-principles-explained

More from TechStack Blog:
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals
C# / .NET: https://www.techstackblog.com/category.html?cat=csharp

Azure Logic Apps vs Function Apps: Choosing the Right Tool for the Integration

Manohari Jayachandran — Mon, 06 Jul 2026 16:37:50 +0000

Two Azure services can look nearly identical on paper. Both connect systems. Both can call an external API, transform data along the way, and handle errors when something goes wrong. Both appear in almost every Azure integration architecture diagram. Logic Apps and Function Apps are not interchangeable though - an integration platform connecting Salesforce and ServiceNow at my company used both side by side, each doing a job the other one did worse. This post is the actual decision framework behind that choice, not just a feature comparison table.

What Each One Actually Is

Azure Logic Apps is a low-code, visual workflow service. Workflows are built by connecting triggers and actions - prebuilt connectors for hundreds of services (Salesforce, ServiceNow, SQL, Service Bus, Office 365, and many more) - in a designer that produces a JSON workflow definition underneath. Azure Functions is serverless compute - actual code, written in C#, Python, JavaScript, or other supported languages, that runs in response to a trigger and can do anything general-purpose code can do.

The distinction that actually matters day to day:

Logic Apps orchestrates and connects; 
Functions computes and transforms.

Both can technically do a bit of the other's job, which is exactly where the confusion about choosing between them comes from.

When the Visual Designer Is a Genuine Advantage

The Logic Apps designer is a real advantage, not just a demo-friendly feature, in a few specific situations. Business stakeholders who are not developers can often read a Logic App workflow diagram and understand what it does - genuinely useful when a workflow needs sign-off from someone outside engineering, or when a non-developer occasionally needs to adjust a schedule or a threshold without a deployment. Connector-heavy integrations, where most of the work is "get data from Salesforce, format it, send it to ServiceNow, handle the response," play directly to the designer's strength - dragging in a Salesforce connector and a ServiceNow connector is meaningfully faster than writing and testing an HTTP client against each API by hand, especially when Microsoft has already
built and maintains the connector's authentication and pagination handling.

Built-in retry policies are also a real, concrete advantage. Every action in a Logic App has a configurable retry policy - exponential backoff, fixed interval, number of retries - available directly in the designer with no code required. For an integration that calls a flaky external API, this alone can be worth choosing Logic Apps over hand-rolling retry logic in a Function.

When the Designer Becomes a Liability

The same visual workflow that helps a business stakeholder becomes a genuine liability once the logic gets complex. Nested conditions, loops within loops, and complex data transformations expressed through the designer's expression language become difficult to read, difficult to code review meaningfully (reviewing a JSON diff of a workflow definition is a poor substitute for reviewing readable code), and difficult to unit test in the way a C# method can be unit tested directly.

Complex data transformation is a common point where teams discover this the hard way. Logic Apps' expression language can technically do string manipulation, array transformation, and conditional logic, but it becomes substantially harder to write, read, and debug than the equivalent C# would be. A common, sound pattern is a Logic App that handles the connector orchestration and calls out to a Function App specifically for any transformation logic more complex than basic field mapping.

Where Custom Code Wins Even for "Simple" Logic

Some logic that sounds simple in a planning conversation turns out to be a poor fit for the designer in practice. Validation logic with several interdependent conditions - "if the record type is X and the status is Y, unless field Z is also set, in which case..." - reads far more clearly as a C# method with early returns than as nested condition actions in a designer canvas. Anything requiring a real data structure beyond simple key-value pairs - building a tree, deduplicating a list by a custom equality rule, sorting by multiple criteria - is native, testable code in a Function and awkward or impossible to express cleanly in the designer's expression language.

Testability is the difference that matters most in practice. A Function App's logic can be unit tested directly, in isolation, the same way any other C# code is tested. Testing a Logic App workflow's actual logic requires either running the whole workflow end to end against test data or exporting and testing pieces of the expression language in a more indirect way - meaningfully slower feedback during development.

A Concrete Example: The Same Step, Built Both Ways

Consider one integration step: a new Salesforce case comes in, and if its priority is High and it does not already have a matching open incident in ServiceNow, create one.

Built as a Logic App, this is a trigger on the Salesforce connector, a Condition action checking priority equals High, a ServiceNow connector action querying for an existing open incident matching the case ID, another Condition action checking whether that query returned zero results, and finally a ServiceNow connector action creating the incident. Five to six actions, each billed individually under Consumption pricing, entirely visual, readable by someone unfamiliar with code, and configurable retry policies available on every connector action without
writing anything.

Built as a Function App, the same logic is a single function: an HTTP or Service Bus trigger receives the case data, a few lines of C# check the priority field directly, an HTTP call queries ServiceNow's API for an existing incident, an if statement checks the result count, and another HTTP call creates the incident if needed. One execution billed as a unit under Consumption pricing, code that can be unit tested directly, and retry logic that must be written explicitly - typically with a library like Polly for exponential backoff - rather than configured through a UI.

Neither version is objectively better. 
The Logic App version is faster to build and more transparent to a 
non-developer reviewer. 
The Function App version is faster to test properly, easier to extend 
with more complex conditions later, and bills as one unit of execution
rather than several.

Cost Models - A Real, Concrete Difference

Under Consumption-based pricing, Logic Apps bills per action executed within a workflow run. A workflow with five actions per execution is billed for five actions every single time it runs - the example above, at five to six actions per run, accumulates costs proportional to both the number of runs and the number of actions inside each run.

Azure Functions under Consumption pricing bills based on execution count, execution duration, and memory consumption - a single function execution containing equivalent logic to that five-action Logic App workflow is billed as one execution, regardless of how many internal steps the code performs.

At low volume, this distinction rarely matters enough to drive the decision. At high volume - thousands or millions of executions per day - the per-action billing model of Logic Apps can meaningfully exceed the cost of the equivalent logic consolidated into a single Function execution. This is a genuine, quantifiable reason some teams migrate high-volume Logic App workflows into Functions once volume grows, independent of any maintainability argument.

Error Handling and Retry - Different Defaults

Logic Apps ships with retry policies configurable per action directly in the designer - exponential interval, fixed interval, or no retry, with a configurable count and interval, applied to individual connector actions without writing code. Scope actions with a configured "Run After" setting provide a visual equivalent of try/catch, routing to alternate actions based on whether a preceding action succeeded, failed, timed out, or was skipped.

Azure Functions has no equivalent built-in retry configuration for arbitrary code - retry logic for an HTTP call or a database operation must be written explicitly, commonly using a library like Polly to define retry policies, circuit breakers, and timeout policies in code. This requires more upfront work but offers finer- grained control - a retry policy in code can incorporate arbitrary logic (retry only on specific HTTP status codes, back off differently based on the type of failure) that would be awkward to express through a designer's retry configuration UI.

Orchestrating Rather Than Choosing

A pattern worth knowing explicitly: many real integration platforms do not choose Logic Apps or Functions exclusively - they use Logic Apps to orchestrate calls to one or more Function Apps. The Logic App handles the connector-level integration (triggering on an event from Salesforce, formatting the initial payload, handling the overall retry and error routing at the workflow level) and delegates any genuinely complex transformation or validation logic to a Function App called as an action
within that workflow.

This pattern captures a meaningful share of the benefit of both: the connector ecosystem and visual retry/error handling of Logic Apps, combined with the testability and expressive power of real code for the parts of the integration that actually need it. This was closer to how my company's integration platform was actually structured in practice - not a single tool chosen exclusively, but each tool used where its particular strengths applied.

A Simple Decision Framework

Choose Logic Apps when the integration is primarily connector orchestration - moving data between systems that already have good Logic Apps connectors, with light transformation, where built-in retry and visual transparency to non-developers add real value.

Choose Function Apps when the integration involves non-trivial branching logic, complex data transformation, custom validation with several interdependent conditions, or genuine need for unit testing the logic directly.

Choose both together, with Logic Apps orchestrating calls to Functions, when an integration needs the connector ecosystem and visual workflow of Logic Apps for the overall flow, but specific steps within that flow are complex enough to warrant real code.

Key Lessons

Logic Apps and Function Apps solve overlapping but genuinely different problems - the choice is not about which is "better" in the abstract, but which fits the actual shape of a specific integration.
The visual designer is a real advantage for connector-heavy, business-stakeholder-visible workflows, and a real liability once logic gets complex enough that code review and unit testing become important.
Cost models differ concretely - per-action billing in Logic Apps versus per-execution billing in Functions - and this becomes a real factor at meaningful volume, not just a minor footnote.
Built-in retry policies in Logic Apps require no code but offer less fine-grained control than a library like Polly gives inside a Function.
Using Logic Apps to orchestrate Function Apps, rather than choosing one tool exclusively, is a common and often correct real-world pattern.

Summary

Logic Apps and Function Apps are frequently presented as competing choices, but the more accurate framing is that they solve different parts of the same problem well. Logic Apps excels at connector orchestration, visual transparency, and configuration-driven retry handling. Function Apps excels at complex logic, genuine testability, and fine-grained control over execution and error handling. Understanding which parts of a given integration actually need which strengths - and being willing to combine both in a single architecture - is the practical skill that matters more than picking a single favorite tool.

Originally published at TechStack Blog:
https://www.techstackblog.com/post.html?slug=azure-logic-apps-vs-function-apps

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

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.