DEV Community: Manohari Jayachandran

C# Coding Interview Prep Part 2: LINQ, Generics, Delegates, Interfaces, Garbage Collection, and IEnumerable vs IQueryable

Manohari Jayachandran — Fri, 14 Aug 2026 01:38:49 +0000

Part 1 covered the basics - variables, strings, collections, control flow, methods. This part covers the concepts that separate "I can write C#" from "I understand what's actually happening underneath" - the topics that come up constantly in real coding interviews and rarely get explained clearly in one place. Same format as Part 1 throughout: a plain-English explanation, an analogy, a real code example, and a practice question for every topic.

Topic 1: LINQ and Deferred Execution

LINQ, Language Integrated Query, lets you query collections using a consistent, readable syntax. The critical concept most people miss: LINQ queries do not execute when defined - they execute when iterated with foreach or materialized with ToList, Count, or First.

Think of writing a shopping list versus actually going to the store. Defining a LINQ query is writing the list - nothing happens yet. The query only actually runs the moment you walk into the store and start picking items off the shelf, which is iterating the results.

var posts = GetAllPosts(); // List<Post>

// This line does NOT query anything yet - it just
// builds up a description of what to do
var query = posts.Where(p => p.IsPublished);

// The query actually EXECUTES here, when iterated
foreach (var post in query) { }

// Or when materialized
var list = query.ToList();   // executes now
var count = query.Count();   // executes now

// Why this matters - data can change between
// definition and execution
posts.Add(new Post { IsPublished = true, Title = "New" });
var results = query.ToList();  // includes the new post,
                                 // because the query only
                                 // ran just now, AFTER the add

// Common LINQ methods
var published = posts.Where(p => p.IsPublished);
var titles = posts.Select(p => p.Title);
var sorted = posts.OrderByDescending(p => p.CreatedAt);
var first = posts.FirstOrDefault(p => p.Slug == "csharp-basics");
var grouped = posts.GroupBy(p => p.Tech);
var any = posts.Any(p => p.Tech == "Azure");
var total = posts.Sum(p => p.ReadingTime);

Practice question: Write a LINQ query that groups a list of posts by their Tech tag, then returns only the groups with more than 2 posts.

Topic 2: IEnumerable vs IQueryable

This is the distinction that matters enormously once Entity Framework is involved. IEnumerable represents an in-memory sequence - once data is loaded, filtering happens in application memory. IQueryable represents a query that can be translated into another language, SQL for a database, and executed at the source, with the actual filtering happening there instead.

Think of IEnumerable as receiving an entire filing cabinet's contents shipped to your desk, then sorting through the papers yourself. IQueryable is like sending instructions to the filing clerk - "bring me only the folders from 2026" - so the clerk does the filtering before anything is even shipped to you.

// IQueryable - this does NOT hit the database yet,
// it builds an expression tree describing the query
IQueryable<Post> query = dbContext.Posts
    .Where(p => p.IsPublished);

// Still IQueryable - EF Core keeps building the SQL
query = query.Where(p => p.Tech == "Azure");

// NOW it executes - EF Core translates the WHOLE
// thing into ONE SQL query, filtering happens
// IN THE DATABASE
var results = query.ToList();
// SQL: SELECT * FROM Posts
//      WHERE IsPublished = 1 AND Tech = 'Azure'

// THE MISTAKE - calling ToList() too early
IEnumerable<Post> earlyList = dbContext.Posts.ToList();
// ^ This ALREADY hit the database and loaded
//   EVERY post into memory, no filtering applied yet

var filtered = earlyList.Where(p => p.Tech == "Azure");
// This filtering now happens IN MEMORY, in C#,
// AFTER all posts were already pulled from SQL -
// far more data transferred than necessary

// The rule: keep building your query with IQueryable
// as long as possible, call ToList()/ToListAsync()
// LAST, once every filter is already applied

Practice question: Given a method that accepts IQueryable as a parameter, explain what happens differently if that method internally calls .ToList() before applying additional filters, versus applying filters first and calling .ToList() last.

Topic 3: Generics

Generics let you write one class or method that works safely across many types, without duplicating code for each type or giving up compile-time type checking by using object.

// Generic class - T is decided at the moment of use
public class Box<T>
{
    private T _item;
    public void Store(T item) => _item = item;
    public T Retrieve() => _item;
}

var postBox = new Box<Post>();
var numberBox = new Box<int>();

// Generic method
public T GetFirstOrDefault<T>(List<T> items)
{
    return items.Count > 0 ? items[0] : default(T);
}

// Constraints - restricting what T can be
public class Repository<T> where T : class, new()
{
    public T CreateNew() => new T();
    // class = T must be a reference type
    // new() = T must have a parameterless constructor,
    //         which is what makes "new T()" legal here
}

public T GetMax<T>(List<T> items) where T : IComparable<T>
{
    T max = items[0];
    foreach (var item in items)
        if (item.CompareTo(max) > 0) max = item;
    return max;
    // IComparable<T> constraint is what makes
    // .CompareTo() legal to call here
}

Practice question: Write a generic method Swap that takes two ref parameters of type T and swaps their values.

Topic 4: Delegates and Events

A delegate is a type-safe reference to a method - it lets you pass behavior around as if it were data. Events build on delegates to create a publish-subscribe relationship where a publisher notifies subscribers without knowing who they are.

// Built-in delegate types cover almost every case
Func<int, int, int> add = (a, b) => a + b;   // has a return value
Action<string> log = msg => Console.WriteLine(msg); // no return value
Predicate<int> isEven = n => n % 2 == 0;      // always returns bool

Console.WriteLine(add(3, 4));  // 7
log("Hello");

// Every LINQ lambda is secretly a delegate
posts.Where(p => p.IsPublished);  // this lambda IS a
                                     // Func<Post, bool>

// Events - a delegate only the publisher can raise
public class PostPublisher
{
    public event EventHandler<string> PostPublished;

    public void Publish(string title)
    {
        PostPublished?.Invoke(this, title);
        // ?. prevents a crash if nobody subscribed
    }
}

var publisher = new PostPublisher();
publisher.PostPublished += (sender, title) =>
    Console.WriteLine($"Published: {title}");

publisher.Publish("New Post");  // triggers the subscriber

Practice question: What's the actual difference between a delegate and an event? Why can't code outside the publisher class directly call PostPublished.Invoke()?

Topic 5: Interfaces vs Abstract Classes

Both define a contract other classes must fulfill, but an interface has no implementation of its own, traditionally, and a class can implement many interfaces, while an abstract class can provide shared, partial implementation, and a class can inherit from only one.

public interface IShape
{
    double GetArea();  // no implementation - a pure contract
}

public abstract class ShapeBase
{
    public string Name { get; set; }

    // Shared, concrete implementation every subclass gets for free
    public void PrintName() => Console.WriteLine(Name);

    // Abstract member - subclasses MUST provide this
    public abstract double GetArea();
}

public class Circle : ShapeBase, IShape
{
    public double Radius { get; set; }
    public override double GetArea() => Math.PI * Radius * Radius;
}

// A class can implement MANY interfaces
public class Employee : IWorkable, IFeedable, IRestable { }

// But only ONE base class
public class Manager : Employee /* cannot also : Contractor */ { }

Reach for an interface when unrelated classes need to fulfill the same contract with no shared code - a Circle and a Square both have an area but share nothing else. Reach for an abstract class when related classes genuinely share common implementation, not just a shape.

Practice question: Design a small example, interface or abstract class, for a payment system with CreditCardPayment and PayPalPayment - explain which you'd choose and why.

Topic 6: Garbage Collection

.NET automatically manages memory - you don't manually free objects. The garbage collector, GC, periodically identifies objects no longer reachable from your running code and reclaims their memory. It organizes objects into generations to make this efficient.

Generation 0 is where newly created objects start. They're collected very frequently and cheaply, since most objects die young - a temporary variable inside a method, for instance. Generation 1 holds objects that survived a Generation 0 collection, a middle ground collected less often. Generation 2 holds long-lived objects, like a Singleton or a cache, something alive for the app's whole lifetime, collected rarely and expensively when it happens.

This generational design exists because most objects are genuinely short-lived - checking Generation 0 constantly and Generation 2 rarely is far more efficient than treating every object identically.

// IDisposable - for resources the GC does NOT
// know how to clean up on its own (file handles,
// database connections, network sockets)
public class FileLogger : IDisposable
{
    private StreamWriter _writer;

    public FileLogger(string path)
        => _writer = new StreamWriter(path);

    public void Log(string message) => _writer.WriteLine(message);

    public void Dispose()
    {
        _writer?.Dispose();  // release the file handle
                              // DETERMINISTICALLY, not
                              // whenever GC happens to run
    }
}

// using statement - guarantees Dispose() is called,
// even if an exception occurs
using (var logger = new FileLogger("log.txt"))
{
    logger.Log("Application started");
}  // Dispose() called automatically HERE

// Modern C# - using declaration, disposes at end of scope
using var logger2 = new FileLogger("log.txt");
logger2.Log("Started");

A finalizer, written as a destructor-style method, does eventually run before an object's memory is reclaimed, but "eventually" could be a long time, since it depends on GC timing, not your code's timing - a file handle held open for an unpredictable extra period is a real problem. IDisposable with a using block releases the resource deterministically, the moment you're actually done with it.

Practice question: Why would a class holding a database connection want to implement IDisposable rather than relying purely on the garbage collector and a finalizer?

Topic 7: Exception Handling in Depth

Beyond basic try/catch, real production code needs custom exception types, exception filters, and correct rethrowing that preserves the original stack trace.

// Custom exceptions - carry meaningful, specific
// information beyond a generic Exception
public class InsufficientFundsException : Exception
{
    public decimal RequestedAmount { get; }
    public decimal AvailableBalance { get; }

    public InsufficientFundsException(
        decimal requested, decimal available)
        : base($"Cannot withdraw {requested:C}, only {available:C} available")
    {
        RequestedAmount = requested;
        AvailableBalance = available;
    }
}

// Exception filters - catch only under a specific
// condition, without catching and immediately
// rethrowing everything else
try
{
    CallExternalApi();
}
catch (HttpRequestException ex) when (ex.Message.Contains("timeout"))
{
    // only handles TIMEOUT-related HTTP failures,
    // other HttpRequestExceptions pass through uncaught
    RetryRequest();
}

// Rethrowing CORRECTLY - preserves the original
// stack trace, showing where the error ACTUALLY
// originated
try
{
    DoSomething();
}
catch (Exception ex)
{
    LogError(ex);
    throw;              // CORRECT - preserves original
                          // stack trace

    // throw ex;         // WRONG - resets the stack
                          // trace to HERE, hiding
                          // where it actually happened
}

// finally always runs, exception or not
try { RiskyOperation(); }
finally { CleanUp(); }  // always executes

Practice question: What is the practical difference between throw; and throw ex; inside a catch block? Write a short example showing why this matters when debugging a production error.

Topic 8: Boxing and Unboxing

Boxing wraps a value type - int, bool, struct - inside an object on the heap, so it can be treated as a reference type. Unboxing extracts the value type back out. Both have a genuine, measurable performance cost - a real heap allocation happens on every box.

int number = 42;

// Boxing - value type wrapped in an object,
// a REAL heap allocation happens here
object boxed = number;

// Unboxing - extracting the value back out,
// requires an explicit cast
int unboxed = (int)boxed;

// Where this quietly happens without you noticing -
// non-generic collections
ArrayList list = new ArrayList();
list.Add(42);        // BOXES the int automatically
int value = (int)list[0];  // UNBOXES it back

// Generic collections AVOID this entirely - this is
// a real, meaningful reason List<T> beats ArrayList
List<int> genericList = new List<int>();
genericList.Add(42);  // stored directly as int,
                        // NO boxing at all

Practice question: Explain why storing a million integers in an ArrayList is slower and uses more memory than storing them in a List.

Topic 9: Equality - ==, Equals, and GetHashCode

C# has multiple ways to check equality, and they don't always agree - understanding when each applies, and why they can disagree, is a genuinely common interview probe.

// For value types, == and Equals() check VALUE equality
int a = 5, b = 5;
Console.WriteLine(a == b);        // true
Console.WriteLine(a.Equals(b));   // true

// For reference types (by default, unless overridden),
// == and Equals() check REFERENCE equality - are these
// the SAME object in memory, not just "look the same"
var post1 = new Post { Title = "Hello" };
var post2 = new Post { Title = "Hello" };
Console.WriteLine(post1 == post2);        // false -
                                            // different objects
Console.WriteLine(post1.Equals(post2));   // false - same
                                            // default behavior

// string is a SPECIAL CASE - == is overridden to
// check VALUE equality even though string is a
// reference type
string s1 = "hello";
string s2 = "hello";
Console.WriteLine(s1 == s2);  // true - value equality,
                                // special-cased for string

// Overriding equality for your own class
public class Post
{
    public string Slug { get; set; }

    public override bool Equals(object obj)
    {
        if (obj is not Post other) return false;
        return Slug == other.Slug;
    }

    // MUST override GetHashCode consistently with
    // Equals, or Dictionary/HashSet lookups silently
    // break - two "equal" objects must produce the
    // SAME hash code
    public override int GetHashCode() => Slug?.GetHashCode() ?? 0;
}

// ReferenceEquals - explicitly checks "same object
// in memory", ignoring any Equals override
Console.WriteLine(ReferenceEquals(post1, post2));  // false

Practice question: Why does overriding Equals() without also overriding GetHashCode() cause a class to behave incorrectly when used as a Dictionary key?

Topic 10: Extension Methods

Extension methods let you add new methods to an existing type, including types you don't own like built-in .NET types, without modifying the original class or using inheritance.

// Defining an extension method - static class,
// static method, "this" before the first parameter
public static class StringExtensions
{
    public static bool IsValidSlug(this string input)
    {
        return !string.IsNullOrWhiteSpace(input)
            && input == input.ToLower()
            && !input.Contains(" ");
    }
}

// Calling it - looks exactly like a real instance method,
// even though string itself was never modified
string slug = "csharp-basics";
bool valid = slug.IsValidSlug();  // true

// This is EXACTLY how all the built-in LINQ methods
// work - Where, Select, OrderBy are all extension
// methods on IEnumerable<T>, defined in the Enumerable
// class, not actual members of List<T> itself

Practice question: Write an extension method TruncateWithEllipsis(this string input, int maxLength) that shortens a string to a max length and appends "..." if it was actually truncated.

Topic 11: Stack, Queue, and LinkedList

Beyond List, Dictionary, and HashSet, a few more built-in collections come up specifically for order-of-operations problems in interviews.

// Stack<T> - Last In, First Out (LIFO)
var undoHistory = new Stack<string>();
undoHistory.Push("Action 1");
undoHistory.Push("Action 2");
string lastAction = undoHistory.Pop();  // "Action 2" -
                                          // most recent

// Queue<T> - First In, First Out (FIFO)
var taskQueue = new Queue<string>();
taskQueue.Enqueue("Task 1");
taskQueue.Enqueue("Task 2");
string nextTask = taskQueue.Dequeue();  // "Task 1" -
                                          // first one in

// LinkedList<T> - doubly-linked list, efficient
// insertion/removal at any point WITHOUT shifting
// every other element, unlike List<T>, which shifts
// elements when inserting in the middle
var linked = new LinkedList<int>();
linked.AddLast(1);
linked.AddLast(2);
linked.AddFirst(0);
// Genuinely useful when frequent insertion/removal
// in the middle of a sequence matters more than
// indexed random access

Practice question: Using a Stack, write a method that checks whether a string of parentheses like "(())" or "(()" is properly balanced.

Topic 12: String Formatting

Beyond basic interpolation, C# offers format specifiers for numbers, dates, and custom types, worth knowing for anything display-facing.

decimal price = 1234.5m;
DateTime date = DateTime.Now;

Console.WriteLine($"{price:C}");      // $1,234.50
Console.WriteLine($"{price:N2}");     // 1,234.50
Console.WriteLine($"{date:yyyy-MM-dd}"); // 2026-08-13
Console.WriteLine($"{date:MMMM dd, yyyy}"); // August 13, 2026

// Alignment and padding in interpolation
string name = "Alex";
Console.WriteLine($"{name,10}");   // right-aligned, 10 wide
Console.WriteLine($"{name,-10}|"); // left-aligned, 10 wide

// ToString overrides for custom types
public class Post
{
    public string Title { get; set; }
    public override string ToString() => $"Post: {Title}";
}
var post = new Post { Title = "Hello" };
Console.WriteLine(post);  // "Post: Hello" - uses the override

Practice question: Given a decimal representing a price, write code that formats it as currency with exactly 2 decimal places, and explain the difference between the "C" and "N" format specifiers.

Key Lessons

LINQ queries use deferred execution - they run when iterated or materialized, ToList or Count, not when defined, which explains a lot of "unexpected" behavior around data changing mid-query.

IQueryable lets filtering happen at the source, SQL for EF Core, while IEnumerable means the data is already loaded and filtering happens in memory - calling ToList() too early is a genuine, common performance mistake.

Generic constraints - where T : class, new(), IComparable - are what let you safely call specific operations inside a generic method.

Garbage collection uses generations - short-lived objects, Generation 0, are collected cheaply and often; long-lived objects, Generation 2, rarely and expensively - IDisposable with using gives deterministic cleanup for unmanaged resources.

Overriding Equals() without GetHashCode() breaks Dictionary and HashSet lookups silently - the two must stay consistent.

Boxing has a real, measurable cost - generic collections like List avoid it entirely, which is a genuine reason to prefer them over legacy non-generic collections.

What's Next

Part 3 covers advanced concepts - async/await and Task in depth, Task.WhenAll and Task.WhenAny, CancellationToken, ConcurrentDictionary and thread-safe collections, reflection, and memory and performance considerations.

Summary

These mid-level concepts are where C# knowledge genuinely starts to separate candidates in interviews, not because they're obscure, but because they require understanding the mechanism underneath, not just the syntax on top. LINQ's deferred execution, the IEnumerable and IQueryable split, generic constraints, garbage collection generations, and correct equality overrides all reward the same kind of thinking: knowing not just what a line of code does, but when it actually runs and why.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-interview-prep-midlevel-part2

Part 1 of this series (Basics): https://www.techstackblog.com/post.html?slug=csharp-interview-prep-basics-part1

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

C# Coding Interview Prep Part 1: Variables, Strings, Arrays, Lists, Dictionaries, and Every Basic Building Block

Manohari Jayachandran — Wed, 12 Aug 2026 13:15:07 +0000

This is a refresher built while preparing for C# coding interviews, and shared as a resource, because a genuinely comprehensive, practice-oriented guide is hard to find in one place. This series doesn't skip the basics to get to the "interesting" parts - the basics are exactly what trips people up under interview pressure, when a simple question about arrays suddenly requires recalling details nobody thinks about in day-to-day coding. Every topic in this series follows the same format: a plain-English explanation, an analogy, a code example, and a practice question at the end, so this can genuinely be used to test yourself, not just read passively.

This is Part 1 of three. Part 1 covers the _basics _- variables, data types, strings, arrays, List, Dictionary, HashSet, tuples, value vs reference types, operators, control flow, loops, methods, enums, structs vs classes, nullable types, type conversion, and basic exception handling. Part 2 covers mid-level concepts - LINQ, generics, delegates and events, interfaces vs abstract classes, and exception handling in depth. Part 3 covers _advanced _concepts - async and Task, reflection, memory management and garbage collection, design patterns in practice, and performance considerations.

Topic 1: Variables and Data Types

A variable is a named storage location holding a value of a specific type. C# is statically typed - once a variable is declared with a type, it can only ever hold values of that type, or something compatible with it.

Think of a labeled storage box. A box labeled "int" can only hold integers - trying to put a sentence in it doesn't work, the same way a shoebox labeled for shoes doesn't neatly fit a stack of books.

// Value types - the actual data lives directly
// in the variable
int age = 30;
double price = 19.99;
bool isPublished = true;
char grade = 'A';
decimal exactMoney = 19.99m;  // decimal for money -
                               // no floating point
                               // rounding errors

// var - the compiler infers the type at compile
// time, this is still statically typed, NOT dynamic
var name = "Alex";  // compiler infers string

// Reference types - the variable holds a reference
// (address) to where the actual data lives
string title = "C# Basics";
int[] numbers = { 1, 2, 3 };
Post post = new Post();

// Constants - value is fixed at compile time,
// cannot ever change
const double Pi = 3.14159;

// Nullable value types - value types normally
// cannot be null, this opts in
int? nullableAge = null;

Practice question: What is the difference between const and readonly in C#? Write one example of each.

Topic 2: Strings and String Methods

A string is a sequence of characters, and in C# it's a reference type - but with a critical twist: strings are immutable. Once created, a string's actual content in memory never changes. Every operation that appears to modify a string actually creates a brand new string.

Think of a printed book page. You cannot erase and rewrite a word on a printed page - if you want different text, you print an entirely new page. Modifying a string works the same way: the old string still exists in memory until garbage collected, and a new one is created for the result.

string greeting = "Hello";
string name = "Manohari";

// Concatenation - creates a NEW string, does not
// modify 'greeting'
string message = greeting + ", " + name;

// String interpolation - cleaner syntax, same result
string message2 = $"{greeting}, {name}";

// Common string methods
string text = "  C# Interview Prep  ";
Console.WriteLine(text.Trim());           // "C# Interview Prep"
Console.WriteLine(text.ToUpper());        // "  C# INTERVIEW PREP  "
Console.WriteLine(text.Contains("Prep")); // true
Console.WriteLine(text.Replace("C#", "CSharp"));
Console.WriteLine(text.Split(' ').Length);
Console.WriteLine(text.Substring(2, 4));  // extracts a portion
Console.WriteLine(text.IndexOf("Prep"));  // position found at

// String comparison - == checks VALUE equality
// for strings specifically (special-cased), not
// reference equality
string a = "hello";
string b = "hello";
Console.WriteLine(a == b);         // true - value equality
Console.WriteLine(a.Equals(b));    // true - same result

// StringBuilder - for heavy concatenation, avoid
// creating thousands of throwaway strings in a loop
var sb = new StringBuilder();
for (int i = 0; i < 1000; i++)
{
    sb.Append(i).Append(", ");
}
string result = sb.ToString();

Practice question: Write a method that reverses a string without using any built-in reverse method.

Topic 3: Arrays

An array is a fixed-size, ordered collection of elements of the same type. The size is set at creation and cannot change afterward - to "resize," a new array must be created and the old data copied over.

Think of a row of numbered parking spaces painted onto pavement. The number of spaces is fixed the moment the lot is built - adding more spaces means literally repaving with a new, larger layout, not just adding to the existing one.

// Declaration and initialization
int[] numbers = { 1, 2, 3, 4, 5 };
string[] names = new string[3];  // size 3, all null initially
names[0] = "Alex";
names[1] = "Priya";
names[2] = "Sam";

// Accessing and modifying
Console.WriteLine(numbers[0]);   // 1
numbers[0] = 100;                // arrays ARE mutable in
                                  // content, just fixed size

// Iterating
foreach (var n in numbers)
{
    Console.WriteLine(n);
}

// Multi-dimensional array
int[,] grid = new int[3, 3];
grid[0, 0] = 1;
grid[1, 1] = 5;

// Jagged array - array of arrays, each inner
// array can be a different length
int[][] jagged = new int[3][];
jagged[0] = new int[] { 1, 2 };
jagged[1] = new int[] { 1, 2, 3, 4 };

// Common Array methods
Array.Sort(numbers);
Array.Reverse(numbers);
int index = Array.IndexOf(numbers, 100);
bool found = Array.Exists(numbers, n => n > 50);

Practice question: Given an integer array, write a method that finds the second largest number without sorting the entire array.

Topic 4: List

List is a resizable, ordered collection - the generic, flexible alternative to a fixed-size array. Internally it's backed by an array that gets replaced with a larger one automatically as items are added beyond current capacity.

Think of an expandable file folder versus a fixed shoebox. As more documents come in, the expandable folder just grows - you never have to buy a new one and manually move everything over, even though internally that's conceptually similar to what List does behind the scenes automatically.

var posts = new List<string>();

posts.Add("First Post");
posts.Add("Second Post");
posts.Insert(0, "Inserted at start");

posts.Remove("First Post");     // removes by value
posts.RemoveAt(0);               // removes by index

bool exists = posts.Contains("Second Post");
int index = posts.IndexOf("Second Post");

Console.WriteLine(posts.Count);  // current item count

// Iterating
foreach (var post in posts)
{
    Console.WriteLine(post);
}

// Converting between List and Array
int[] array = { 1, 2, 3 };
List<int> fromArray = array.ToList();
int[] backToArray = fromArray.ToArray();

// Sorting and searching
var numbers = new List<int> { 5, 2, 8, 1 };
numbers.Sort();
numbers.Sort((a, b) => b.CompareTo(a));  // descending,
                                            // custom comparer

Practice question: Write a method that removes all duplicate values from a List while preserving the original order.

Topic 5: Dictionary

A Dictionary stores key-value pairs and provides fast, close-to-O(1) lookup by key, using a hash table internally. Every key must be unique.

Think of a labeled filing cabinet drawer system, where every drawer has exactly one unique name on it. Finding "the invoices drawer" doesn't require checking every drawer one by one - you go directly to the one labeled correctly.

var postsBySlug = new Dictionary<string, string>();

postsBySlug["csharp-basics"] = "C# Basics Post";
postsBySlug["csharp-linq"] = "LINQ Deep Dive";

// Safe lookup - does not throw if key is missing
if (postsBySlug.TryGetValue("csharp-basics", out var title))
{
    Console.WriteLine(title);
}

// Direct access - throws KeyNotFoundException if missing
string result = postsBySlug["csharp-basics"];

bool hasKey = postsBySlug.ContainsKey("csharp-linq");
postsBySlug.Remove("csharp-linq");

// Iterating - gives KeyValuePair<TKey,TValue>
foreach (var kvp in postsBySlug)
{
    Console.WriteLine($"{kvp.Key}: {kvp.Value}");
}

// Just keys or just values
foreach (var key in postsBySlug.Keys) { }
foreach (var value in postsBySlug.Values) { }

// Update or add in one call
postsBySlug["csharp-basics"] = "Updated Title";  // overwrites

Practice question: Given an array of words, write a method using a Dictionary that counts how many times each word appears.

Topic 6: HashSet

A HashSet stores unique values only, with no guaranteed order, and provides fast O(1) average lookup for "does this exist" checks - much faster than checking a List with Contains for large collections.

Think of a guest list at the door of an event, where a bouncer just needs to answer "is this name already checked in" as fast as possible - not caring about the order names were added, just whether a given name is present at all.

var uniqueTags = new HashSet<string>();

uniqueTags.Add("Azure");
uniqueTags.Add("C#");
uniqueTags.Add("Azure");  // silently ignored - duplicate

Console.WriteLine(uniqueTags.Count);  // 2

bool hasAzure = uniqueTags.Contains("Azure");  // O(1) check

// Set operations
var setA = new HashSet<int> { 1, 2, 3, 4 };
var setB = new HashSet<int> { 3, 4, 5, 6 };

setA.IntersectWith(setB);  // setA becomes {3, 4}
// UnionWith, ExceptWith also available

Practice question: Given two integer arrays, write a method that returns only the numbers that appear in both arrays, using a HashSet.

Topic 7: Tuples

A tuple bundles multiple values together into one object without needing to define a custom class. Modern C# tuples support named elements, making them readable at the point of use.

Think of a small labeled tray carrying a few different items together - a tray with "coffee" and "muffin" compartments lets you carry both at once without needing a whole custom carrying case built just for that specific combination.

// Named tuple
(string Name, int Age) person = ("Alex", 30);
Console.WriteLine(person.Name);  // "Alex"
Console.WriteLine(person.Age);   // 30

// Returning multiple values from a method
(int Min, int Max) FindMinMax(int[] numbers)
{
    return (numbers.Min(), numbers.Max());
}

var result = FindMinMax(new[] { 5, 2, 8, 1 });
Console.WriteLine($"Min: {result.Min}, Max: {result.Max}");

// Deconstruction
var (min, max) = FindMinMax(new[] { 5, 2, 8, 1 });
Console.WriteLine(min);
Console.WriteLine(max);

// Tuple vs custom class - when to use which
// Tuple: quick, internal, 2-3 short-lived values
// Class: the shape has real meaning, gets passed
// around broadly, or needs its own behavior/methods

Practice question: Write a method that takes a list of numbers and returns a tuple containing the sum, average, and count in one call.

Topic 8: Value Types vs Reference Types

This is one of the most frequently tested distinctions in C# interviews. Value types - int, bool, double, struct - store their actual data directly in the variable. Reference types - class, array, string, List, Dictionary - store a reference, a memory address, to where the actual data lives on the heap. The variable itself just holds that address.

Think of a value type as writing a number directly on a sticky note - the note is the data. A reference type is like writing a house address on a sticky note - the note points to where the actual house is, and copying the note just copies the address, not the house itself.

// Value type - assignment COPIES the actual value
int a = 5;
int b = a;   // b gets its OWN copy of 5
b = 10;
Console.WriteLine(a);  // still 5 - a was never touched

// Reference type - assignment copies the REFERENCE,
// both variables point to the SAME object
var list1 = new List<int> { 1, 2, 3 };
var list2 = list1;   // list2 points to the SAME list
list2.Add(4);
Console.WriteLine(list1.Count);  // 4 - list1 sees the
                                   // change too, because
                                   // it's the same object

// Passing to methods - same rule applies
void ModifyValue(int x) { x = 100; }
void ModifyReference(List<int> list) { list.Add(999); }

int number = 5;
ModifyValue(number);
Console.WriteLine(number);  // still 5

var myList = new List<int> { 1, 2 };
ModifyReference(myList);
Console.WriteLine(myList.Count);  // 3 - the SAME list
                                    // object was modified

// string is a special case - reference type, but
// immutable, so it BEHAVES like a value type in
// most practical situations
string s1 = "hello";
string s2 = s1;
s2 = s2 + " world";  // creates a NEW string for s2
Console.WriteLine(s1);  // still "hello" - unaffected

Practice question: Without running the code, predict the output: create a struct Point with a public int X, create var p1 = new Point with X set to 1, assign var p2 = p1, then set p2.X to 99. What is p1.X afterward, and why?

Topic 9: Operators

Operators perform operations on values - arithmetic, comparison, logical, and a few special ones worth knowing well for interviews specifically.

// Arithmetic
int sum = 5 + 3;
int remainder = 10 % 3;   // modulo - remainder after division

// Comparison
bool isEqual = (5 == 5);
bool isGreater = (5 > 3);

// Logical
bool result = true && false;   // AND
bool result2 = true || false;  // OR
bool result3 = !true;           // NOT

// Null-coalescing - returns left if not null,
// otherwise returns right
string name = null;
string display = name ?? "Unknown";  // "Unknown"

// Null-conditional - safely accesses a member,
// returns null instead of throwing if the object
// itself is null
Post post = null;
string title = post?.Title;  // null, no exception thrown

// Null-coalescing assignment
string cachedValue = null;
cachedValue ??= "default";  // assigns only if currently null

// Ternary conditional
int age = 20;
string category = age >= 18 ? "Adult" : "Minor";

// Increment/decrement
int count = 0;
count++;      // post-increment
++count;      // pre-increment - subtle difference in
              // expressions, same end result standalone

Practice question: What is the difference between x++ and ++x when used inside a larger expression, like int y = x++ + 1 versus int y = ++x + 1? Write out what each assigns to x and y given x starts at 5.

Topic 10: Control Flow - if, else, switch

Control flow statements decide which code actually runs based on conditions.

int score = 85;

// if / else if / else
if (score >= 90)
{
    Console.WriteLine("A");
}
else if (score >= 80)
{
    Console.WriteLine("B");
}
else
{
    Console.WriteLine("C or below");
}

// switch statement
string grade;
switch (true)
{
    case bool _ when score >= 90:
        grade = "A";
        break;
    case bool _ when score >= 80:
        grade = "B";
        break;
    default:
        grade = "C or below";
        break;
}

// switch expression (modern C#, more concise)
string grade2 = score switch
{
    >= 90 => "A",
    >= 80 => "B",
    _ => "C or below"
};

// Pattern matching in switch
object value = 42;
string description = value switch
{
    int i when i > 0 => "positive integer",
    int i when i < 0 => "negative integer",
    string s => $"a string: {s}",
    null => "null value",
    _ => "something else"
};

Practice question: Write a method using a switch expression that takes an integer representing a day of the week (1-7) and returns whether it's a "Weekday" or "Weekend".

Topic 11: Loops

Loops repeat a block of code, either a fixed number of times, while a condition holds, or once per element in a collection.

// for loop - when you know the iteration count
// or need the index
for (int i = 0; i < 5; i++)
{
    Console.WriteLine(i);
}

// while loop - condition checked BEFORE each iteration
int count = 0;
while (count < 5)
{
    Console.WriteLine(count);
    count++;
}

// do-while - condition checked AFTER each iteration,
// so the body ALWAYS runs at least once
int x = 10;
do
{
    Console.WriteLine(x);
    x++;
} while (x < 5);  // runs once even though condition
                    // is false from the start

// foreach - iterates every element in a collection,
// no manual index management
var posts = new List<string> { "A", "B", "C" };
foreach (var post in posts)
{
    Console.WriteLine(post);
}

// break and continue
for (int i = 0; i < 10; i++)
{
    if (i == 3) continue;  // skip this iteration
    if (i == 7) break;     // exit the loop entirely
    Console.WriteLine(i);
}

Practice question: Write a program using a loop that prints the Fibonacci sequence up to the 10th number.

Topic 12: Methods and Parameters

A method is a named, reusable block of code. Parameters pass data into a method; a return type defines what comes back out.

// Basic method
int Add(int a, int b)
{
    return a + b;
}

// Optional parameters - must come after required ones
void Greet(string name, string greeting = "Hello")
{
    Console.WriteLine($"{greeting}, {name}");
}
Greet("Alex");               // uses default "Hello"
Greet("Alex", "Hi");         // overrides default

// Named arguments - can be passed in any order
Greet(greeting: "Hey", name: "Alex");

// params - accepts a variable number of arguments
int Sum(params int[] numbers)
{
    int total = 0;
    foreach (var n in numbers) total += n;
    return total;
}
Sum(1, 2, 3);        // works
Sum(1, 2, 3, 4, 5);  // also works, any count

// ref - passes by REFERENCE, method can modify
// the caller's actual variable
void Double(ref int number)
{
    number = number * 2;
}
int value = 5;
Double(ref value);
Console.WriteLine(value);  // 10 - actually changed

// out - similar to ref, but the method MUST assign
// a value before returning, commonly used for
// "try" pattern methods
bool TryParse(string input, out int result)
{
    return int.TryParse(input, out result);
}

// Method overloading - same name, different
// parameter signatures
int Multiply(int a, int b) => a * b;
double Multiply(double a, double b) => a * b;

Practice question: What is the actual difference between ref and out parameters? Write a method using each that demonstrates the difference.

Topic 13: Enums

An enum defines a named set of related constant values, making code more readable than using raw numbers or strings for a fixed set of options.

public enum OrderStatus
{
    Pending,     // 0 by default
    Processing,  // 1
    Shipped,     // 2
    Delivered    // 3
}

var status = OrderStatus.Processing;
Console.WriteLine(status);          // "Processing"
Console.WriteLine((int)status);      // 1

// Assigning explicit values
public enum HttpStatusCode
{
    Ok = 200,
    NotFound = 404,
    ServerError = 500
}

// Converting from an int
var code = (HttpStatusCode)404;
Console.WriteLine(code);  // NotFound

// Parsing from a string
var parsed = Enum.Parse<OrderStatus>("Shipped");

// Switching on an enum
string GetMessage(OrderStatus status) => status switch
{
    OrderStatus.Pending => "Order received",
    OrderStatus.Shipped => "On its way",
    OrderStatus.Delivered => "Completed",
    _ => "Unknown status"
};

Practice question: Create an enum for days of the week, and write a method that returns true if a given day is a weekend.

Topic 14: Structs vs Classes

Both structs and classes group related data and behavior together, but a struct is a value type, copied on assignment, while a class is a reference type, shared on assignment - the same fundamental distinction as value types versus reference types, applied to your own custom types.

// struct - value type, typically small, simple data
public struct Point
{
    public int X;
    public int Y;
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1;       // COPIES the values
p2.X = 99;
Console.WriteLine(p1.X);  // still 1 - p1 untouched

// class - reference type, typically larger objects
// with behavior, identity, and mutable state over time
public class Post
{
    public string Title;
    public int ViewCount;
}

var post1 = new Post { Title = "Hello", ViewCount = 0 };
var post2 = post1;  // SHARES the same object
post2.ViewCount = 5;
Console.WriteLine(post1.ViewCount);  // 5 - same object

Use a struct for small, immutable-feeling data with no real identity - a Point, a Color, a Money amount. Use a class for anything with real identity, larger data, or behavior that changes over the object's lifetime - a Post, a Customer, a Service. Most day-to-day domain modeling uses classes; structs are the exception, reached for deliberately.

Practice question: Explain why using a struct for a large object with 15 fields would generally be a bad idea, based on what you know about value type copying.

Topic 15: Nullable Types

Value types - int, bool, DateTime - cannot normally hold null; they always have some default value. Nullable value types, written as int?, opt into allowing null, useful for representing "no value provided" distinctly from an actual zero or false.

int? age = null;
int regularAge = 0;  // 0 is a real value,
                       // different from "no value"

if (age.HasValue)
{
    Console.WriteLine(age.Value);
}

// GetValueOrDefault - safe access with a fallback
int actualAge = age.GetValueOrDefault(18);

// Null-coalescing works here too
int displayAge = age ?? 18;

// Nullable reference types (C# 8+) - a compiler
// feature (not a runtime type change) that WARNS
// when a reference type that should never be null
// might actually be null
string? nullableName = null;   // explicitly allowed
string nonNullableName = "Alex"; // compiler warns if
                                   // this is ever assigned
                                   // null somewhere

Practice question: Why might a nullable int? be a better choice than a regular int for a "discount percentage" field on an order, where most orders have no discount at all?

Topic 16: Type Conversion and Casting

Converting a value from one type to another - sometimes safe and implicit, sometimes requiring an explicit cast, and sometimes needing a parsing method entirely.

// Implicit conversion - safe, no data loss possible,
// compiler does it automatically
int number = 100;
double asDouble = number;  // int fits safely into double

// Explicit conversion (casting) - REQUIRED when data
// loss is possible, forces you to acknowledge the risk
double price = 19.99;
int roundedDown = (int)price;  // 19 - truncates,
                                 // does not round

// Parsing strings to numbers
string input = "42";
int parsed = int.Parse(input);        // throws if invalid
bool success = int.TryParse(input, out int result);
                                        // safe, returns
                                        // false instead of
                                        // throwing

// Convert class - handles more conversions, including
// null handling
string text = Convert.ToString(42);
int fromString = Convert.ToInt32("42");

// as vs cast for reference types
object obj = "hello";
string s1 = (string)obj;      // throws if obj isn't
                                // actually a string
string s2 = obj as string;    // returns null instead
                                // of throwing if it fails

// is keyword with pattern matching
if (obj is string str)
{
    Console.WriteLine(str.Length);
}

Practice question: What is the actual difference between int.Parse() and int.TryParse()? When would you genuinely prefer one over the other?

Topic 17: Basic Exception Handling

Exceptions represent errors that occur during execution. try/catch lets code handle an error gracefully instead of crashing the entire program.

try
{
    int result = 10 / int.Parse("0");
}
catch (DivideByZeroException ex)
{
    Console.WriteLine($"Cannot divide by zero: {ex.Message}");
}
catch (FormatException ex)
{
    Console.WriteLine($"Invalid number format: {ex.Message}");
}
catch (Exception ex)
{
    // Generic catch-all - should be LAST, since more
    // specific catches above it would never be reached
    // if this came first
    Console.WriteLine($"Unexpected error: {ex.Message}");
}
finally
{
    // ALWAYS runs, whether an exception occurred or not -
    // used for cleanup (closing files, connections, etc.)
    Console.WriteLine("Cleanup runs here regardless");
}

// Throwing your own exceptions
void ValidateAge(int age)
{
    if (age < 0)
    {
        throw new ArgumentException("Age cannot be negative", nameof(age));
    }
}

// Custom exception types
public class InsufficientFundsException : Exception
{
    public InsufficientFundsException(string message) : base(message) { }
}

Practice question: Write a method that safely divides two numbers, catching a divide-by-zero error and returning 0 instead of letting the exception propagate.

Key Lessons

Value types copy on assignment; reference types share the same underlying object - this single distinction explains a huge share of "unexpected" C# behavior.

Arrays are fixed size; List resizes automatically - default to List unless the size is genuinely fixed and known.

Dictionary gives fast key-based lookup; HashSet gives fast existence checks with no duplicates.

Strings are immutable - every apparent modification creates a new string, which is exactly why StringBuilder exists for heavy concatenation.

ref and out both pass by reference, but out requires the method to assign a value before returning, commonly used in the TryParse pattern.

Structs and classes mirror the value versus reference type distinction for your own custom types - most everyday modeling uses classes.

What's Next

Part 2 covers mid-level concepts - LINQ, generics, delegates and events, interfaces versus abstract classes, and exception handling in real depth.

Summary

Every C# codebase, no matter how advanced, is built from these same basic pieces - variables and types, strings, collections, control flow, methods, and basic error handling. Interview questions on these topics aren't testing whether you've memorized syntax - they're testing whether the underlying model, value versus reference, mutable versus immutable, fixed versus resizable, is genuinely internalized, since that's what actually predicts whether unfamiliar code will behave the way you expect it to.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=csharp-interview-prep-basics-part1

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

Authentication vs Authorization: Basic Auth, Sessions, OAuth, OIDC, JWT, SSO, and RBAC vs ABAC Explained

Manohari Jayachandran — Fri, 07 Aug 2026 21:50:04 +0000

Authentication and authorization get used almost interchangeably in casual conversation, and confused constantly in interviews, despite being genuinely different questions with different mechanisms answering each one. This post draws that line clearly first, then covers every major method under each - Basic Auth, Sessions, OAuth, OAuth 2.0, OpenID Connect, JWT, SSO, and how authorization decisions actually get made via RBAC and ABAC - with analogies, real examples, and how each one shows up in Azure specifically.

The One-Sentence Distinction

Authentication proves who you are. Authorization proves what you're allowed to do. These are checked separately, even when they happen back to back. A user can be fully, successfully authenticated and still get a 403 Forbidden trying to access something they're not authorized for.

Think of a concert venue. Showing your ticket at the door proves you're a legitimate attendee - that's authentication. Once inside, your wristband color determines whether you can access the VIP lounge or only the general floor - that's authorization. Having a valid ticket says nothing about which areas you're allowed into - those are two separate checks, at two separate points, even though they happen close together.

Basic Auth: The Oldest, Simplest Method

Basic Auth combines a username and password, base64-encodes them together, and sends the result in the Authorization header on every single request.

-- The credentials "alex:mypassword" become:
Authorization: Basic YWxleDpteXBhc3N3b3Jk

-- Base64 is ENCODING, not ENCRYPTION - it is
-- trivially reversible by anyone who intercepts it.
-- This ONLY becomes safe over HTTPS, where the
-- transport layer itself is encrypted.

Think of writing your password on a postcard instead of sealing it in an envelope. Base64 makes it slightly less immediately readable at a glance, but anyone who actually picks it up can read it in seconds. HTTPS is the sealed, tamper-evident courier bag around that postcard - without it, Basic Auth is genuinely dangerous.

Basic Auth still shows up in internal tooling, simple server-to-server calls behind a firewall, or as a stopgap for low-risk endpoints. It's rarely appropriate for anything user-facing or handling sensitive data, since credentials are resent on every single request rather than exchanged once for a limited-scope token.

A Quick, Clarification: API Keys vs Basic Auth vs Subscription Keys

These three terms get used almost interchangeably in casual conversation, but they're not quite the same thing, and mixing them up causes real confusion in practice.

Basic Auth is a username and password, base64-encoded, sent every request, as covered above. An API key is a single opaque string with no username involved, usually sent as a header or query parameter, identifying which application or account is calling, not a specific human user. A subscription key, specifically in Azure API Management, is a particular flavor of API key scoped to a Product, covered in an earlier post on this blog about APIM - it answers which subscription plan a caller is on, not who the caller is.

None of these three actually prove identity in any strong sense - they prove possession of a credential, whether a password, a key, or a subscription key. This is exactly why real production systems frequently combine one of these with OAuth2/OIDC - the API key or subscription key controls access tier and rate limits, while the OAuth token establishes actual, verifiable identity. This same layered pattern was covered concretely in an earlier post on this blog about Azure APIM, where a subscription key and an OAuth token are validated together, answering two different questions in the same request.

Session-Based Authentication: The Server Remembers You

In session-based authentication, a user logs in once with credentials, the server creates a session and stores its state server-side, then gives the browser a session ID, usually via a cookie, to present on every subsequent request instead of re-sending credentials each time.

A login request verifies credentials and creates a session, stored in memory, a database, or a cache like Redis, and returns a Set-Cookie header containing something like sessionId=abc123. Every future request automatically includes that cookie. The server looks up "abc123" in its session store, finds the associated user, and knows who's making the request without re-checking a password every time.

Think of a coat check at a restaurant. Handing over your coat once, logging in, gets you a numbered ticket. Presenting that ticket, the session ID, for the rest of the evening retrieves your coat without needing to re-prove ownership each time - the coat check itself, the server, is what's actually holding onto the state.

The real limitation is that because the server holds the actual session state, scaling horizontally across multiple servers requires that every server can access the same shared session store. A server that doesn't have "abc123" in its own memory can't recognize that session unless the store is centralized, like Redis, or the session is somehow shared across instances. This is a genuine architectural constraint sessions introduce that token-based approaches largely avoid.

OAuth vs OAuth 2.0: Not the Same Protocol

The distinction people miss most often: "OAuth" without a version number technically refers to OAuth 1.0, an older protocol that required cryptographically signing every single request - genuinely painful to implement correctly. OAuth 2.0 is a substantially different, simpler protocol built around bearer tokens sent over HTTPS instead of signed requests. When anyone says "OAuth" today without qualification, they almost always mean OAuth 2.0 - OAuth 1.0 is effectively extinct in modern development.

OAuth 1.0 required every request to be cryptographically signed using a shared secret, complex to implement correctly, with no built-in token expiration concept. OAuth 2.0, what "OAuth" means today, uses bearer tokens - "whoever holds this token is authorized" - sent over HTTPS, with a built-in concept of token expiration and refresh, and multiple grant types for different scenarios, including client credentials and authorization code flows.

OAuth 2.0 is fundamentally a framework for delegated authorization - letting one application access resources on behalf of a user, or another system, without ever handling that user's actual password. An earlier post on this blog covered the mechanics of this in detail: Client Credentials Flow for service-to-service scenarios, Authorization Code Flow for real user logins, access tokens, and refresh tokens.

OpenID Connect (OIDC): The Piece That Makes OAuth2 Usable for Login

OAuth 2.0, by itself, is an authorization framework - it's designed to grant an application access to a resource, not to prove who a user is. A raw OAuth2 access token technically doesn't guarantee anything about identity; it only proves the holder was granted some scope of access. This is a genuinely common point of confusion - "Sign in with Google" and "Sign in with Microsoft" buttons are commonly described as using OAuth, but strictly speaking, they're using OpenID Connect, a layer built directly on top of OAuth 2.0 specifically to add authentication.

OAuth 2.0 alone answers whether an application is allowed to access a resource on the user's behalf. It does not reliably answer who the user is, specifically. OpenID Connect adds a standardized identity layer on top of OAuth 2.0's existing authorization flow, introducing the ID token - a JWT specifically containing identity claims like name, email, and a unique user ID - distinct from the access token.

Where OAuth2 alone issues an access token for calling APIs, OIDC additionally issues an ID token, a JWT whose entire purpose is describing who the user is, not what they can access. Both tokens are often returned together in the same OIDC flow, but they answer different questions and are used differently: the access token gets sent to APIs to prove authorization, while the ID token gets read by the application itself to know who just logged in.

{
  "access_token": "eyJhbGciOiJ...",
  "id_token": "eyJhbGciOiJ...",
  "token_type": "Bearer",
  "expires_in": 3600
}

The decoded ID token payload carries identity claims rather than authorization scopes:

{
  "sub": "a1b2c3d4",
  "name": "Manohari Jayachandran",
  "email": "user@example.com",
  "iss": "https://login.microsoftonline.com/...",
  "aud": "your-app-client-id",
  "exp": 1719399600
}

The one-sentence summary worth remembering: OAuth 2.0 answers whether an app is allowed to do something - it's authorization. OpenID Connect adds who the user doing it actually is - it's authentication, layered on top of OAuth2's existing machinery rather than replacing it. This is exactly why "Sign in with Google" or "Sign in with Microsoft" buttons work the way they do - they're OIDC flows, using OAuth2 underneath to handle the actual token exchange.

JWT: A Token Format, Not an Authentication Method

The distinction that trips people up in interviews most often: JWT, JSON Web Token, is not itself a way of authenticating anyone. It's a specific, structured format that a token can take. OAuth 2.0 is commonly used to issue a JWT as the resulting access token, but OAuth2 and JWT are answering different questions - OAuth2 is the protocol for how a token gets issued and exchanged; JWT is simply the shape that token happens to be in.

A JWT has three parts, separated by dots - header, payload, and signature. This is the same structure covered in more depth in an earlier post on this blog about OAuth token flows: the header names the signing algorithm, the payload carries claims about who issued it, who it's for, when it expires, and what scopes or roles it grants, and the signature cryptographically proves the token hasn't been tampered with.

Critically, a JWT is signed, not encrypted. Anyone holding the token can read every claim inside it, even without the ability to forge a new one. This is why sensitive data should never be placed directly in a JWT's payload.

Stated plainly: Basic Auth and Sessions are both complete authentication mechanisms on their own. OAuth2 is a framework for authorization and delegated access. JWT is neither of those - it's a data format that OAuth2, and other systems, commonly use to package the result of a successful authentication or authorization decision into something portable and independently verifiable.

SSO: Single Sign-On, Built on Top of What's Already Covered

Single Sign-On lets a user authenticate once, with one identity provider, and gain access to multiple separate applications without logging in again for each one. SSO is not a new authentication mechanism of its own - it's an architecture built on top of session-based auth and OpenID Connect, covered just above, applied across multiple applications instead of just one.

Think of a single hotel key card that opens the room, the gym, the pool area, and the parking garage - one check-in at the front desk, the identity provider, and every other door on the property recognizes that same card without asking for ID again. Without SSO, it would be like getting a separate, differently-shaped key for every single door, each requiring its own check-in process.

Without SSO, a user manages separate logins and separate passwords for every application, logging in repeatedly across each one. With SSO, the user logs into the Identity Provider once, and every application trusting that same Identity Provider recognizes the user's session or token without asking them to log in again.

Mechanically, the first application a user visits redirects them to a central Identity Provider if they aren't already authenticated. The user logs in once at the Identity Provider, which issues a token, commonly a JWT via OAuth2 or OpenID Connect, or sets a session with itself. When the user then visits a second application, that application also redirects to the same Identity Provider - but since the user already has a valid session or token from the first login, they're recognized immediately and redirected back, fully authenticated, without ever seeing a login form the second time.

Two protocols are commonly used to implement SSO. SAML, Security Assertion Markup Language, is older and XML-based, still common in large enterprise environments. OpenID Connect, built directly on top of OAuth 2.0, adds a standardized identity layer onto OAuth's authorization framework - this is the modern, most common way SSO is implemented today, and it's why OpenID Connect is often described as "OAuth2 plus authentication."

Azure AD, now Microsoft Entra ID, plays exactly this role across Microsoft 365, the Azure Portal, and any custom application registered against the same tenant - logging into one Microsoft-connected application means every other application trusting that same Azure AD tenant recognizes the session without a repeated login. This is the same Azure AD covered in an earlier post on this blog about OAuth token flows, now applied across multiple applications instead of just one.

How This Connects to Azure Specifically

The full picture ties together two earlier posts on this blog. Azure AD, now called Microsoft Entra ID, issues a token after verifying identity - this is authentication, using OAuth 2.0 as the protocol, covered in depth in an earlier post on Azure AD and OAuth token flows. That token is a JWT - the format, not the method. Azure API Management's validate-jwt policy checks the token's signature, expiry, issuer, and audience at the gateway, before the backend ever runs, covered in depth in an earlier post on Azure APIM. Claims inside that JWT, like app roles or scopes, determine what the caller is actually allowed to do once authenticated - checking those specific claims is authorization, layered on top of the authentication that already happened.

Where authentication ends and authorization begins in this Azure flow is worth being precise about. Azure AD verifying the caller's identity and issuing a valid, signed JWT is authentication - it answers who this is. APIM's validate-jwt policy checking that the token is genuinely valid, not expired, correctly signed, right audience, is still part of confirming the authentication is real. The moment a policy checks a specific claim, such as whether this token has the Orders.Read role, that's authorization - a separate question answered using data carried inside the already-authenticated token.

RBAC vs ABAC: How Authorization Decisions Actually Get Made

Everything above establishes who a caller is. This section covers how a system actually decides what that caller can do - the real mechanism behind checking whether a token has a specific role, mentioned just above.

Role-Based Access Control, RBAC, attaches permissions to roles, and users are assigned to one or more of those roles. An Admin role can read, write, and delete. An Editor role can read and write. A Viewer role can only read. A user's permissions are whatever their assigned role or roles grant - simple, predictable, and easy to reason about.

Think of a hospital ID badge. A badge marked Nurse opens certain doors and certain systems. A badge marked Doctor opens more. The badge doesn't know anything about the specific person wearing it beyond their assigned role - two different nurses with the same role badge get identical access, no matter how their individual situations might differ.

Attribute-Based Access Control, ABAC, decides permissions dynamically, based on a combination of attributes evaluated at the moment of the request, rather than a fixed role assignment. A rule might allow access to a patient record only if the requesting user's department matches the patient's assigned department, the request happens during business hours, and the record isn't flagged as restricted. The same user might be allowed access to one record and denied access to another, based on attributes of the specific resource and context, not a single fixed role.

Think of airport security screening. Whether a specific bag gets flagged for additional screening depends on a combination of factors evaluated in that specific moment - what's in the bag, which flight, current threat level, random selection - not a single fixed role the passenger was permanently assigned at check-in. The decision is made fresh, per situation, based on multiple attributes together.

RBAC fits when a permission structure is genuinely role-shaped - a manageable number of roles, each with a clear, fairly static set of permissions. ABAC fits when access decisions genuinely depend on context that changes per request - resource ownership, time, location, sensitivity level, or the relationship between the user and the specific resource. Many real systems use both together, a coarse RBAC layer for broad access tiers like Admin versus Standard User, with finer ABAC-style rules layered on top for specific sensitive resources.

This connects directly back to the Azure JWT example above: a role claim inside a JWT, like Orders.Read, being checked by APIM is RBAC in action - the caller was assigned that role, and the token carries proof of it. A more advanced setup might layer ABAC on top - even with a valid Orders.Read role, a specific policy might further restrict access based on which region the order belongs to, matching an attribute on the caller's own token against an attribute on the specific resource being requested.

Choosing the Right Approach

Basic Auth fits internal tooling, simple server-to-server calls behind a firewall, and low-risk scenarios only. Session-based auth fits traditional server-rendered web apps, where the server already controls the full request lifecycle and horizontal scaling isn't a primary concern. OAuth 2.0 combined with JWT fits APIs, single-page applications, mobile apps, service-to-service integration, and anything needing delegated access without sharing real passwords, or anything that needs to scale horizontally without shared server-side session state.

Key Lessons

Authentication proves identity; authorization proves permission - they're checked separately, and passing one doesn't guarantee passing the other.

API keys, subscription keys, and Basic Auth all prove possession of a credential, not identity - none of the three is a strong identity check on its own.

Basic Auth is simple but only safe over HTTPS, since base64 encoding is trivially reversible, not real encryption.

Session-based auth keeps state on the server, which is simple for single-server apps but requires a shared session store to scale horizontally.

OAuth and OAuth 2.0 are genuinely different protocols - OAuth 2.0 is what "OAuth" means today, using bearer tokens instead of OAuth 1.0's cryptographic request signing.

OAuth 2.0 alone only handles authorization - OpenID Connect is the layer built on top of it that adds real authentication, via a separate ID token distinct from the access token.

JWT is a token format, not an authentication method - OAuth2 is a common way to issue one, but the two answer different questions.

SSO is not a separate mechanism - it's session and OAuth concepts applied across multiple applications trusting one shared identity provider, commonly implemented today via OpenID Connect on top of OAuth 2.0.

In a real Azure setup, Azure AD handles authentication and issues a JWT, while claims inside that JWT, checked by APIM or the backend, handle authorization - two distinct steps using the same token.

RBAC assigns fixed permissions to roles, simple and predictable; ABAC decides access dynamically based on multiple attributes at request time - real systems often layer both together.

Summary

Authentication and authorization are two separate questions - who are you, and what are you allowed to do - answered by different mechanisms that often work together but are never the same check. Basic Auth and session-based authentication are complete, older methods of proving identity. OAuth 2.0 is a modern framework for delegated authorization, built around bearer tokens rather than OAuth 1.0's cryptographic signing. JWT is not a method at all - it's the structured format a token commonly takes, readable by anyone holding it but not forgeable without the signing key. Seeing how Azure AD, JWTs, and APIM's validation policy fit together, authentication first, authorization layered on top using claims inside the same token, is what turns these five terms from a list of buzzwords into a coherent system.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=authentication-vs-authorization-explained

Related reading on TechStack Blog:
Azure AD and OAuth Token Flows: https://www.techstackblog.com/post.html?slug=azure-ad-oauth-token-flows-explained
Azure API Management Part 1: https://www.techstackblog.com/post.html?slug=azure-apim-explained-part1

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

Azure API Management Part 2: A Complete CRUD API, Built and Deployed Behind APIM End to End

Manohari Jayachandran — Wed, 05 Aug 2026 16:31:04 +0000

Part 1 covered the concepts - what APIM is, the Product and API and Operation hierarchy, policies, subscription keys, OAuth validation, CORS, and rate limiting. This part builds something real: a complete CRUD API in ASP.NET Core, imported into APIM, wrapped in a Product, and secured with every policy from Part 1 actually applied and working - the full path from code to a production-shaped, secured API.

Step 1: Building a Minimal CRUD API

A small Notes API - Create, Read, Update, Delete - is enough to demonstrate every APIM concept without unnecessary complexity. Swagger and OpenAPI support are enabled from the start, since that's what makes importing into APIM trivial in the next step.

// Program.cs - minimal API style, ASP.NET Core

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();
app.UseSwagger();
app.UseSwaggerUI();

var notes = new List<Note>();

app.MapGet("/notes", () => notes);

app.MapGet("/notes/{id}", (int id) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    return note is not null ? Results.Ok(note) : Results.NotFound();
});

app.MapPost("/notes", (Note note) =>
{
    note.Id = notes.Count + 1;
    notes.Add(note);
    return Results.Created($"/notes/{note.Id}", note);
});

app.MapPut("/notes/{id}", (int id, Note updated) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    if (note is null) return Results.NotFound();
    note.Title = updated.Title;
    note.Content = updated.Content;
    return Results.Ok(note);
});

app.MapDelete("/notes/{id}", (int id) =>
{
    var note = notes.FirstOrDefault(n => n.Id == id);
    if (note is null) return Results.NotFound();
    notes.Remove(note);
    return Results.NoContent();
});

app.Run();

record Note
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
    public string Content { get; set; } = "";
}

Deployed to an App Service, the same pattern covered when this blog's own API was set up, the Swagger UI at /swagger now serves a machine-readable OpenAPI spec at /swagger/v1/swagger.json - this file is what APIM will import directly in the next step.

Step 2: Importing the API Into APIM

In the Azure Portal, inside an existing APIM instance, the import flow starts at APIs, then Add API, then OpenAPI. Pasting the URL to the swagger.json file, or uploading it directly, along with a Display Name like "Notes API" and an API URL suffix like "notes," is enough for APIM to read the spec and automatically create every Operation - GET /notes, GET /notes/{id}, POST /notes, PUT /notes/{id}, and DELETE /notes/{id} - with their parameters already defined.

No manual operation-by-operation setup is required. This is the entire benefit of enabling Swagger and OpenAPI on the API itself before ever touching APIM - the import step becomes almost entirely automatic.

Step 3: Creating a Product and Adding the API to It

A new Product named "Partner Notes Access" is created, with a description explaining it grants access to the Notes API for approved partners, subscription required, and approval required so that a partner requesting access gets manually reviewed before being granted a key. The Notes API is then added to that Product directly. The Notes API is now reachable only through a valid subscription to this specific Product, not by anyone who simply discovers the URL.

Step 4: Layering the Policies From Part 1

The Product-level policy handles the subscription key check, which is largely automatic once "Requires subscription" is enabled on the Product itself. The underlying policy structure still exists as an inbound block with a base element, even though the actual key validation happens automatically based on that Product setting.

The API-level policy handles OAuth validation, applying to every operation in the Notes API, layered on top of the product-level subscription check:

<!-- Notes API-level policy.xml -->
<policies>
  <inbound>
    <base />
    <validate-jwt header-name="Authorization"
        failed-validation-httpcode="401"
        failed-validation-error-message="Unauthorized">
      <openid-config url="https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration" />
      <audiences>
        <audience>api://notes-api</audience>
      </audiences>
    </validate-jwt>
  </inbound>
</policies>

The Operation-level policy applies a stricter rate limit specifically to the write operations - POST, PUT, and DELETE - leaving GET at the product's default limit:

<!-- Applied to POST /notes, PUT /notes/{id},
     DELETE /notes/{id} individually -->
<policies>
  <inbound>
    <base />
    <rate-limit-by-key calls="5"
        renewal-period="60"
        counter-key="@(context.Subscription.Id)" />
  </inbound>
</policies>

Write operations get five calls per minute, meaningfully stricter than the read-only GET operations, since writes are more expensive and more consequential if something calls them in a runaway loop.

The actual effective policy for a POST request, once all three levels combine, runs in a specific order: the subscription key is checked first at the Product level, inherited automatically; then the OAuth token is validated at the API level, also inherited; then the stricter rate limit applies at the Operation level, specific to this operation alone - all three running in sequence before the request ever reaches the real backend.

Step 5: Adding CORS for a Real Frontend Origin

<!-- API-level policy, added alongside the JWT validation -->
<inbound>
  <base />
  <validate-jwt ... />

  <cors allow-credentials="true">
    <allowed-origins>
      <origin>https://partner-app.example.com</origin>
    </allowed-origins>
    <allowed-methods>
      <method>GET</method>
      <method>POST</method>
      <method>PUT</method>
      <method>DELETE</method>
    </allowed-methods>
    <allowed-headers>
      <header>Content-Type</header>
      <header>Authorization</header>
    </allowed-headers>
  </cors>
</inbound>

Setting allow-credentials to true means the Authorization header, carrying the OAuth token, is permitted - which is exactly why the origin must be named explicitly as https://partner-app.example.com rather than a wildcard, per the CORS rule covered in Part 1: browsers explicitly forbid combining a wildcard origin with credentialed requests.

Step 6: Versioning Before the Breaking Change Ships

Consider a scenario where the Notes API's response shape needs to change - "Content" is being renamed to "Body" to better match a new internal naming convention. This breaks every existing caller still expecting "Content."

The fix starts under APIs, then Notes API, then Add Version, choosing a Path-based versioning scheme for the discoverability reasoning covered in Part 1, with a version identifier of v2. The v2 API is now live at /v2/notes, completely separate from the original, which APIM automatically prefixes as v1 once a second version exists.

The v2 backend returns a response shaped as Id, Title, and Body, while the v1 backend still returns Id, Title, and Content - both versions can point to different backend deployments, or the same backend with a version-aware response transformation. Existing partners keep calling /v1/notes with zero changes required on their end. New partners, or partners ready to migrate, start using /v2/notes explicitly and get the new Body field name.

Step 7: Testing the Complete Flow End to End

What a caller actually experiences, request by request, demonstrates every layer working together.

A POST request with no subscription key returns 401 Unauthorized, blocked at the Product level before the backend is ever called.
The same request with a subscription key added but no Authorization header still returns 401 Unauthorized, this time blocked at the API level.
The same request with both a valid subscription key and a valid OAuth token, called six times within one minute, succeeds for the first five calls but the sixth returns 429 Too Many Requests, blocked at the Operation level's rate limit.
Only a request with a valid key, a valid token, and within the rate limit actually reaches the backend and returns 201 Created with the note genuinely persisted.

Every failure in that sequence was caught by APIM before the backend ever ran - exactly the architectural benefit covered conceptually in Part 1, now demonstrated with an actual request sequence.

Key Lessons

Enabling Swagger and OpenAPI on an API before importing into APIM turns manual operation-by-operation setup into an automatic import.

Real production APIM setups layer policies across all three levels deliberately - subscription key at the product level, identity at the API level, fine-grained limits at the operation level.

Write operations often warrant stricter rate limits than reads, applied specifically at the operation level rather than uniformly across the whole API.

CORS with credentials requires a named origin, never a wildcard - this is not optional, browsers enforce it directly.

Versioning before a breaking change ships, not after, is what lets existing callers continue working completely unaffected while new callers adopt the new version deliberately.

Testing the full request sequence - missing key, missing token, rate limit exceeded, successful call - demonstrates that every layer of protection actually runs before the backend, not just in theory.

The Two-Part Series, Complete

Part 1 covered the concepts - what APIM is, the Product and API and Operation hierarchy, policies, subscription keys, OAuth, CORS, and rate limiting. Part 2 built all of it into a real, working example - a CRUD API imported into APIM, secured with layered policies, versioned safely, and tested end to end.

Summary

The concepts from Part 1 only fully make sense once they're applied together against something real. A minimal CRUD API, imported via its OpenAPI spec, becomes a fully governed API once it sits inside a Product with a subscription requirement, an API-level OAuth check, an operation-level rate limit on the expensive write paths, and a properly scoped CORS policy for its actual frontend. Versioning before a breaking change ships, rather than scrambling after callers start failing, is what keeps that governance sustainable over time. This is the complete, real path from a few lines of C# to a production-shaped, secured API, not just the individual pieces in isolation.

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

Part 1 of this series (Concepts): https://www.techstackblog.com/post.html?slug=azure-apim-explained-part1

Azure API Management Part 1: Products, Policies, and Securing Your APIs

Manohari Jayachandran — Mon, 03 Aug 2026 17:51:46 +0000

Azure API Management was one of the core pieces of the integration platform used at Blue Yonder to connect Salesforce and ServiceNow, alongside Logic Apps, Function Apps, and Service Bus, covered in earlier posts on this blog. APIM is also genuinely confusing the first time it needs to be configured rather than just read about. This is Part 1 of a two-part refresher - concepts, policies, and security. Part 2 will be a complete, real example: building an actual CRUD API and putting it behind APIM end to end.

What Azure API Management Actually Is

The core idea behind APIM is that it sits in front of one or more backend APIs, and callers talk to APIM, never directly to the backend. APIM checks identity, applies rate limits, can transform the request or response, and only then forwards the call to the real API.

Think of a hotel front desk. Guests don't walk directly into any room they want - they check in at the desk first, which verifies who they are, hands out a key card scoped to specific rooms, and only then lets them proceed. The rooms themselves, the backend APIs, never have to handle check-in logic directly - that's the desk's job, done once, consistently, for every guest.

Without APIM, every API has to implement its own auth check, its own rate limiting, and its own logging, and do it consistently across every single service. With APIM, a caller reaches APIM first, which handles auth, rate limiting, logging, and transformation once, centrally, for every API behind it, without duplicating that logic in every backend service.

The Core Hierarchy: Product, API, Operation

A Product is a bundle of one or more APIs presented together to consumers, with subscription and usage rules attached at the product level. An API is a specific backend service exposed through APIM. An Operation is a single endpoint within that API - one specific HTTP verb and route, like GET /orders/{id}.

A caller subscribes to the Product, which grants access to every API inside it. A single subscription key can call multiple different APIs, as long as both live inside the same product - an Orders API and an Inventory API bundled into one "Partner Integration APIs" product, for instance, both become reachable with the same subscription key.

This hierarchy matters because policies can be written at the Product level, the API level, or the individual Operation level, and they run in an inherited order - product-level policies apply first, then API-level, then operation-level, unless explicitly overridden. A rate limit set at the product level applies to every API inside it by default; a stricter rate limit set on one specific operation overrides that default for just that operation.

Publishing and Versioning

Versioning solves the problem of shipping a breaking change to an API without breaking every existing caller still using the old version. APIM supports several versioning schemes: path-based, where the version is visible directly in the URL as /v1/orders versus /v2/orders; query string-based, where the same URL accepts a version parameter like ?api-version=2; and header-based, where the URL stays identical and the version travels in a custom header instead.

A practical publishing flow looks like this: a new API version is created alongside the existing one, and both are live simultaneously. Existing callers keep hitting the original version exactly as before, with nothing breaking for them. New callers, or callers ready to migrate, opt into the new version explicitly. Once every caller has migrated off the old version, confirmed through APIM's analytics, the old version can be safely retired.

Path-based versioning is the most common choice specifically because it's the most discoverable - a caller can see directly in the URL which version they're hitting, which matters enormously when debugging an integration issue with an external partner months after the original setup.

Policies: XML That Runs in the Request and Response Pipeline

A policy is a block of XML that executes at specific points in a request's lifecycle - before it reaches the backend, after the backend responds, or if something fails along the way. There are four policy sections, run in order.

The <inbound> section runs before the request reaches the backend - authentication checks, rate limiting, request transformation, and header manipulation all happen here. The <backend> section is the actual call to the real backend API, rarely customized beyond the default forward-the-request behavior, though it can be modified for advanced routing scenarios. The <outbound> section runs on the response, before it reaches the caller - response transformation, header stripping, and adding CORS headers all happen here. The <on-error> section runs if anything in the sections above throws an error, and is commonly used for consistent error response formatting across every API behind APIM.

<policies>
  <inbound>
    <base />
    <!-- Check for a required custom header -->
    <check-header name="X-Client-Id"
        failed-check-httpcode="400"
        failed-check-error-message="X-Client-Id header is required"
        ignore-case="true" />

    <!-- Rewrite the backend URL -->
    <set-backend-service base-url="https://internal-api.company.com" />
  </inbound>

  <backend>
    <base />
  </backend>

  <outbound>
    <base />
    <!-- Strip an internal header before it reaches the caller -->
    <set-header name="X-Internal-Server-Id" exists-action="delete" />
  </outbound>

  <on-error>
    <base />
    <set-header name="X-Error-Source" exists-action="override">
      <value>APIM</value>
    </set-header>
  </on-error>
</policies>

The <base /> element matters - it means "also run whatever policy is inherited from the level above, whether that's Product or API." Omitting it means this policy replaces the inherited one entirely rather than adding to it, which is a common source of confusion when a policy that worked at the Product level appears to stop applying once an Operation-level policy is added without including <base />.

Subscription Keys: The Simplest Layer of Access Control

A subscription key proves that the caller has a valid key - nothing more. It does not identify who is calling, only that the caller possesses a key associated with a specific Product subscription. A subscription key is sent as a header or query parameter on every request, and APIM validates that the key exists and is active for the Product this API belongs to before forwarding the request to the backend at all.

Think of a building's keycard system. Having a valid keycard proves you're allowed into the building - it does not prove you're a specific named employee versus a visitor who was issued a temporary card. Subscription keys work the same way: they gate access, but they aren't a real identity check.

Subscription keys alone are genuinely sufficient for internal tooling, low-risk read-only endpoints, or scenarios where the actual sensitive authorization happens downstream anyway. They're rarely sufficient on their own for anything handling real user data or financial operations.

OAuth Validation at the Gateway

Validating a JWT access token directly at the APIM gateway - the same OAuth mechanism covered in an earlier post on this blog about Azure AD token flows - rejects invalid or expired tokens before the request ever reaches the backend API.

<inbound>
  <base />
  <validate-jwt header-name="Authorization"
      failed-validation-httpcode="401"
      failed-validation-error-message="Unauthorized - invalid or missing token">
    <openid-config url="https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration" />
    <audiences>
      <audience>api://your-api-client-id</audience>
    </audiences>
    <required-claims>
      <claim name="roles" match="any">
        <value>Orders.Read</value>
      </claim>
    </required-claims>
  </validate-jwt>
</inbound>

This single policy block validates the token's signature, checks it hasn't expired, confirms it was issued for the right audience, and confirms the caller has a specific required role claim, all before the backend API's own code runs at all.

Validating at the gateway matters, not just in the backend, because an invalid or expired token gets rejected immediately at APIM - the backend never spends compute processing a request that was going to fail authorization anyway. It also means every API behind APIM gets consistent token validation logic without each one implementing it separately, the exact same architectural benefit as centralizing rate limiting or logging.

Real production APIs often require both a subscription key and a valid OAuth token together - the subscription key controls which Product or plan the caller is on, while the OAuth token establishes their actual identity and permissions. Neither replaces the other; they answer different questions.

CORS: Why Browsers Block Requests That Postman Allows Fine

The actual confusion, named directly: a request works perfectly in Postman, curl, or the backend's own server-to-server calls, but fails specifically when called from JavaScript running in a browser, with an error mentioning "CORS policy" and no obvious HTTP status code to debug. This happens because CORS is not a backend rule at all - it's a browser-enforced security restriction, and the browser is the thing blocking the request, not the API.

Browsers enforce a same-origin policy by default - JavaScript running on one origin, a combination of scheme, domain, and port like https://techstackblog.com, cannot make requests to a different origin like https://api.techstackblog.com unless that other origin explicitly says it's allowed to. CORS, Cross-Origin Resource Sharing, is the mechanism a server uses to explicitly grant that permission via response headers.

Think of a guest list at a private event. The browser is the venue's security guard - by default, it doesn't let anyone in unless the event's host, the API, has explicitly published a guest list saying which other venues, or origins, are allowed to send their guests over. Postman and curl aren't guests arriving through the browser's front door at all - they're not subject to the guest list, which is exactly why the same request that fails from a browser works completely fine from those tools.

This is why CORS only affects browser-based JavaScript specifically. Postman, curl, or a server-to-server call trigger no CORS check at all, since CORS is a browser enforcement mechanism, not a server-side one. Browser JavaScript calling a different origin gets checked by the browser for CORS headers before letting the response reach the calling JavaScript code - even if the API actually processed and returned a valid response, the browser hides it from the page's JavaScript if the CORS headers are missing.

A second common source of confusion is the preflight request. For certain requests, anything beyond simple GET or POST with standard headers, the browser sends an OPTIONS request first, before the real request, asking "am I allowed to do this." This preflight request happens automatically and invisibly, before the actual GET, POST, or PUT the developer wrote code for. The server's response to that preflight needs to include headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. Only if the preflight response includes the right headers does the browser then send the real request that the developer's code actually triggered.

APIM handles this through a dedicated CORS policy rather than requiring individual response headers to be hand-written:

<inbound>
  <base />
  <cors allow-credentials="true">
    <allowed-origins>
      <origin>https://techstackblog.com</origin>
    </allowed-origins>
    <allowed-methods>
      <method>GET</method>
      <method>POST</method>
      <method>PUT</method>
    </allowed-methods>
    <allowed-headers>
      <header>Content-Type</header>
      <header>Authorization</header>
    </allowed-headers>
  </cors>
</inbound>

APIM's built-in CORS policy automatically handles the OPTIONS preflight request and adds the correct headers to the real response - both halves of the CORS handshake in one policy block, rather than manually writing separate logic for the preflight and the actual response.

The specific mistake that causes the most confusion is setting Access-Control-Allow-Origin to a wildcard, allowing any origin, while also trying to send credentials like cookies or authorization headers from the browser. Browsers explicitly forbid combining a wildcard origin with credentialed requests, since that combination would defeat the entire purpose of the restriction. If credentials need to be sent, the allowed origin must be a specific, named origin, not a wildcard.

Rate Limiting: Protecting the Backend From Being Overwhelmed

<!-- Product-level rate limit - applies to every
     API inside this product by default -->
<inbound>
  <base />
  <rate-limit-by-key calls="100"
      renewal-period="60"
      counter-key="@(context.Subscription.Id)" />
</inbound>

This example allows 100 calls per 60 seconds, tracked per subscription. Exceeding this returns a 429 Too Many Requests response automatically, without the backend ever being called.

<!-- A stricter limit on one specific operation,
     overriding the product-level default -->
<inbound>
  <base />
  <rate-limit-by-key calls="10"
      renewal-period="60"
      counter-key="@(context.Subscription.Id)" />
</inbound>

This specific operation, perhaps an expensive report-generation endpoint, gets a much stricter limit than the product default, because it's genuinely more expensive to serve.

The real point of rate limiting is that it happens in the inbound policy, before the backend call - that's what makes it actually protective rather than just informational. A rate limit checked after the backend already processed the request has already spent the compute it was meant to prevent.

A product-level limit is the sensible default for ensuring no single subscriber can overwhelm anything behind that product. An operation-level override makes sense when one specific endpoint is disproportionately expensive to serve, such as a search or report-generation endpoint, and needs a tighter limit than the rest of the product.

Key Lessons

APIM sits in front of backend APIs - callers talk to APIM, never directly to the real service, which centralizes auth, rate limiting, and transformation instead of duplicating that logic in every backend.

The Product, API, Operation hierarchy determines where a policy lives, and policies inherit downward unless explicitly overridden - this is the most common source of "why isn't my policy applying" confusion.

Path-based versioning is the most discoverable scheme, letting existing callers on the old version keep working unaffected while new callers opt into the new version explicitly.

Policies run in four sections - inbound, backend, outbound, on-error - and <base /> matters, since omitting it replaces the inherited policy instead of adding to it.

A subscription key proves possession of a key, not identity - OAuth validation at the gateway is what establishes a real, checkable identity before the backend ever runs.

CORS is a browser-enforced restriction, not a server-side one - Postman and server-to-server calls never trigger it, which is exactly why "it works in Postman but not the browser" is the classic CORS symptom.

Rate limiting belongs in the inbound policy specifically because that's what actually protects the backend - checking after the fact only observes the problem rather than preventing it.

What's Next

Part 2 puts all of this into practice - a complete, real example building a CRUD API and putting it behind APIM end to end, with actual products, policies, versioning, and security configured from scratch.

Summary

Azure API Management is the front desk in front of one or more real backend APIs, centralizing authentication, rate limiting, and request and response transformation so that logic doesn't need to be duplicated in every individual service. The Product, API, and Operation hierarchy determines where policies live and how they inherit. Subscription keys and OAuth validation answer different questions - possession of a key versus actual identity - and real production APIs frequently need both. Rate limiting, applied in the inbound policy before the backend is ever called, is what makes it genuinely protective. Understanding these pieces individually is what makes APIM's XML policy language make sense as a coherent system rather than a collection of unrelated snippets to copy and paste.

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

Related reading on TechStack Blog:
Azure AD and OAuth Token Flows: https://www.techstackblog.com/post.html?slug=azure-ad-oauth-token-flows-explained
Azure API Management Deep Dive: https://www.techstackblog.com/post.html?slug=azure-api-management-deep-dive

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

Database Interview Topics Part 4: Normalization, 1NF Through 3NF, and When to Break the Rules

Manohari Jayachandran — Fri, 31 Jul 2026 17:12:49 +0000

Part 1 of this series covered joins. Part 2 covered indexing. Part 3 covered stored procedures, views, and transactions. This closing part covers normalization - and rather than abstract rule definitions, it takes one genuinely messy sample table and fixes it one normal form at a time, so each rule is visible in an actual before and after rather than just described.

The Messy Starting Table

OrderId	CustomerName	CustomerPhones	ProductNames	CityId	CityName
1	Alex Kim	555-1234, 555-5678	Mouse, Keyboard	10	Chicago
2	Priya Shah	555-9999	Monitor	20	Denver
3	Alex Kim	555-1234, 555-5678	Webcam	10	Chicago

Three real problems are already visible here: CustomerPhones holds multiple values crammed into one field, ProductNames holds multiple values crammed into one field, and CityName is fully determined by CityId, repeating identically on every row that shares the same CityId.

First Normal Form: Every Column Holds Exactly One Value

The rule for First Normal Form is that every column must hold exactly one atomic value per row - no repeating groups, no multi-valued fields.

Think of a form with a single Phone Number field, not one field where someone crammed three phone numbers separated by commas. If a person can have multiple phone numbers, that's a sign a separate table is needed, not a wider single field.

Orders (1NF)

OrderId	CustomerName	CityId	CityName
1	Alex Kim	10	Chicago
2	Priya Shah	20	Denver
3	Alex Kim	10	Chicago

OrderProducts (1NF)

OrderId	ProductName
1	Mouse
1	Keyboard
2	Monitor
3	Webcam

CustomerPhones (1NF)

CustomerName	Phone
Alex Kim	555-1234
Alex Kim	555-5678
Priya Shah	555-9999

Every column in every table now holds exactly one value per row - this is 1NF.

Second Normal Form: No Partial Dependency on Part of a Composite Key

Second Normal Form only becomes relevant when a table has a composite primary key - two or more columns together forming the key. The rule states every other column must depend on the entire key, not just part of it.

Think of the OrderProducts table having a composite key of OrderId plus ProductName, with someone adding a ProductCategory column to that same table. ProductCategory depends only on ProductName - it has nothing to do with OrderId at all.

OrderProducts — 2NF violation (key: OrderId + ProductName)

OrderId	ProductName	ProductCategory
1	Mouse	Peripherals
1	Keyboard	Peripherals
2	Monitor	Displays
3	Webcam	Peripherals

"Peripherals" is duplicated three times. If the category name ever changes, every single row with that product needs to be updated individually.

Fix — split into two tables:

OrderProducts (2NF)

OrderId	ProductName
1	Mouse
1	Keyboard
2	Monitor
3	Webcam

Products (2NF)

ProductName	ProductCategory
Mouse	Peripherals
Keyboard	Peripherals
Monitor	Displays
Webcam	Peripherals

Now ProductCategory is stored exactly once per product, not once per order line.

Third Normal Form: No Transitive Dependency Between Non-Key Columns

The rule for Third Normal Form is that every non-key column must depend only on the primary key, not on another non-key column in the same table.

CityId depends directly on OrderId, and CityName depends directly on CityId - so CityName depends on OrderId only indirectly, through CityId. This is a transitive dependency.

Orders — 3NF violation

OrderId	CustomerName	CityId	CityName
1	Alex Kim	10	Chicago
2	Priya Shah	20	Denver
3	Alex Kim	10	Chicago

"Chicago" is duplicated every time CityId equals 10 appears. If Chicago were ever renamed in the system, every duplicate needs updating.

Fix — split City into its own table:

Orders (3NF)

OrderId	CustomerName	CityId
1	Alex Kim	10
2	Priya Shah	20
3	Alex Kim	10

Cities (3NF)

CityId	CityName
10	Chicago
20	Denver

CityName now exists exactly once per city, referenced by Id rather than duplicated by name.

The Fully Normalized Result

Table	Columns
Orders	OrderId, CustomerName, CityId
OrderProducts	OrderId, ProductName
Products	ProductName, ProductCategory
CustomerPhones	CustomerName, Phone
Cities	CityId, CityName

Five focused tables instead of one wide, repetitive one. Every piece of information now exists in exactly one place - updating a city name, a product category, or a phone number means updating exactly one row, not hunting down every duplicate.

Denormalization

Denormalization means deliberately duplicating data across tables, or keeping wider tables than strict normalization would produce, specifically to avoid the cost of joining multiple tables together on a read path that needs to be fast.

-- A fully normalized "get order summary" query
-- needs several joins to reconstruct one readable row
SELECT o.OrderId, o.CustomerName, c.CityName,
       p.ProductName, pr.ProductCategory
FROM Orders o
JOIN Cities c ON o.CityId = c.CityId
JOIN OrderProducts p ON o.OrderId = p.OrderId
JOIN Products pr ON p.ProductName = pr.ProductName;

Normalized, this costs three joins per read but keeps exactly one row to update, always in sync. Denormalized, this costs one read with no joins, but the duplicate copy needs explicit sync, or it goes stale.

A deliberately denormalized version might store CityName directly on the Orders table again:

-- ORDERS (deliberately denormalized)
-- OrderId | CustomerName | CityId | CityName
-- 1       | Alex Kim     | 10     | Chicago

-- One less join, faster read. The tradeoff: if
-- Chicago is ever renamed, this duplicated copy
-- needs an explicit update too, or it silently
-- goes stale.

This is a legitimate choice, not a mistake. Normalization optimizes for data integrity and avoiding update anomalies. Denormalization optimizes for read speed, at the acknowledged cost of needing to keep duplicated data in sync deliberately - whether through application code, database triggers, or a scheduled process. The real mistake is denormalizing by accident, without realizing the sync responsibility now exists - not the deliberate choice to denormalize a specific, measured hot path.

Key Lessons

1NF requires every column to hold exactly one atomic value - no repeating groups or multi-valued fields crammed into one column.

2NF only applies to tables with a composite key, and requires every other column to depend on the whole key, not just part of it.

3NF requires every non-key column to depend only on the primary key, not transitively through another non-key column.

Each normal form removes one specific kind of data duplication, which in turn removes one specific kind of update anomaly.

Denormalization is a deliberate, legitimate tradeoff - duplicating data on purpose to avoid join cost on a measured, high-traffic read path, accepting the responsibility to keep that duplicate in sync.

The real mistake is accidental denormalization - duplicating data without realizing it now needs active synchronization, rather than choosing to denormalize deliberately for a specific, identified reason.

The Series, Complete

This closes out the four-part database interview series. Part 1 covered joins - Inner, Left, Right, Full Outer, Cross, Self. Part 2 covered indexing - clustered, non-clustered, composite, and covering indexes. Part 3 covered stored procedures, views, ACID, isolation levels, and deadlocks. Part 4 covered normalization - 1NF through 3NF, and the honest case for denormalizing on purpose.

Summary

Normalization is a step-by-step process for removing duplicated data and the update anomalies that duplication causes. First Normal Form removes multi-valued fields. Second Normal Form removes dependencies on only part of a composite key. Third Normal Form removes dependencies that flow indirectly through another non-key column. Each step trades some storage efficiency and update simplicity for the cost of needing more joins to reconstruct a full picture - which is exactly why denormalization exists as its deliberate, honest counterpart, trading that join cost back for read speed on the specific paths that genuinely need it. Knowing both directions - when to normalize and when to deliberately step back from it - is what separates textbook schema design from schema design that holds up in a real, high-traffic system.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=database-normalization-schema-design

Part 1 of this series (Joins): https://www.techstackblog.com/post.html?slug=database-joins-explained
Part 2 of this series (Indexing): https://www.techstackblog.com/post.html?slug=database-indexing-explained
Part 3 of this series (Transactions): https://www.techstackblog.com/post.html?slug=database-stored-procedures-transactions

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

Database Interview Topics Part 3: Stored Procedures, Views, and Transactions

Manohari Jayachandran — Wed, 29 Jul 2026 17:03:21 +0000

Part 1 of this series covered joins. Part 2 covered indexing. This part covers the territory that separates "I can write a query" from "I understand what happens when multiple transactions hit the same data at the same time" - stored procedures, views, ACID properties, and transaction isolation levels.

Stored Procedures: Precompiled SQL, Stored in the Database Itself

A stored procedure is a named, precompiled block of SQL stored inside the database, called by name instead of sending the full SQL text from application code every time.

-- Defining a stored procedure
CREATE PROCEDURE GetActiveCustomers
    @MinOrderCount INT
AS
BEGIN
    SELECT c.Id, c.Name, COUNT(o.Id) AS OrderCount
    FROM Customers c
    JOIN Orders o ON c.Id = o.CustomerId
    GROUP BY c.Id, c.Name
    HAVING COUNT(o.Id) >= @MinOrderCount;
END;

-- Calling it - the application sends this short
-- call instead of the full query text every time
EXEC GetActiveCustomers @MinOrderCount = 3;

The real benefit is that the database can cache and reuse a precompiled execution plan for the procedure, avoiding the overhead of re-parsing and re-planning the same query structure repeatedly. It also centralizes a piece of logic in one place if multiple applications need the exact same query.

The real cost, stated honestly: business logic now lives in two separate places, application code and the database itself, which makes it harder to track down where a piece of logic actually lives, harder to unit test compared to application-layer code, and adds real deployment friction, since a stored procedure change is a database migration, not just an application code change that ships through the normal build pipeline.

Views: A Saved Query That Looks Like a Table

A view is a named, saved SELECT query that can be queried as if it were a table, without actually storing any data of its own.

-- Defining a view
CREATE VIEW ActiveCustomersView AS
SELECT c.Id, c.Name, COUNT(o.Id) AS OrderCount
FROM Customers c
JOIN Orders o ON c.Id = o.CustomerId
GROUP BY c.Id, c.Name
HAVING COUNT(o.Id) >= 3;

-- Querying it looks exactly like querying a table
SELECT * FROM ActiveCustomersView
WHERE Name LIKE 'A%';

-- But underneath, the ENTIRE original query runs
-- again every single time this view is queried - a
-- view is not stored data, it's a stored QUERY

Think of a saved search on a shopping site. The saved search isn't a separate copy of matching products sitting somewhere - it's a remembered set of filters that re-runs against the live catalog every time it's opened. A view works the same way against a database.

Views are used for simplifying a complex, frequently-repeated query into something readable and reusable, and for hiding underlying table structure from application code that doesn't need to know about it. This is a genuine readability and maintenance win, not a performance optimization on its own.

Materialized Views: The Same Idea, But the Result Is Actually Stored

A materialized view is a view where the query's result is physically stored, not recalculated on every read, and refreshed on some schedule or trigger rather than live every time.

-- Materialized view syntax varies by database engine -
-- this shows the PostgreSQL form
CREATE MATERIALIZED VIEW ActiveCustomersSummary AS
SELECT c.Id, c.Name, COUNT(o.Id) AS OrderCount
FROM Customers c
JOIN Orders o ON c.Id = o.CustomerId
GROUP BY c.Id, c.Name
HAVING COUNT(o.Id) >= 3;

-- Reading it is now fast - genuinely stored data,
-- not a recalculated query
SELECT * FROM ActiveCustomersSummary;

-- But it does NOT automatically stay current -
-- someone has to refresh it
REFRESH MATERIALIZED VIEW ActiveCustomersSummary;

The tradeoff is genuinely fast reads at the cost of staleness between refreshes - the exact same fundamental tradeoff as caching, covered in an earlier System Design post on this blog. A materialized view is, conceptually, a cache implemented at the database layer specifically for one query's result.

ACID: The Four Guarantees a Real Transaction Makes

Atomicity means all operations in a transaction succeed together, or none of them apply at all - there's no half-finished state left behind. Consistency means a transaction can only move the database from one valid state to another valid state, never leaving constraints, foreign keys, or rules violated.
Isolation means concurrent transactions don't see each other's incomplete, in-progress work.
Durability means once a transaction is committed, it survives a crash immediately afterward - it's genuinely saved, not just held in memory.

-- A concrete example of Atomicity: a bank transfer
BEGIN TRANSACTION;

UPDATE Accounts SET Balance = Balance - 100
WHERE AccountId = 1;

UPDATE Accounts SET Balance = Balance + 100
WHERE AccountId = 2;

COMMIT;

-- If the SECOND update failed for any reason
-- (constraint violation, crash, disconnect),
-- Atomicity guarantees the FIRST update is rolled
-- back too - the money never just vanishes from
-- account 1 without appearing in account 2

Transaction Isolation Levels: How Much Concurrent Transactions Can See of Each Other

Isolation levels are a dial between strict correctness and concurrency performance. Looser levels allow more simultaneous activity but permit specific, named anomalies. Stricter levels prevent those anomalies but require more locking, reducing how much can genuinely happen at the same time.

Read Uncommitted, the loosest level, can read another transaction's uncommitted changes. This allows a dirty read: one transaction updates a balance without committing, a second transaction reads that uncommitted value, and then the first transaction rolls back - meaning the second transaction read a value that never actually happened.

Read Committed only reads data that has actually been committed, eliminating dirty reads. It still allows a non-repeatable read: a transaction reads a row, a second transaction updates and commits a change to that same row, and when the first transaction reads the same row again within the same transaction, it gets a different value the second time.

Repeatable Read guarantees the same row read twice within one transaction returns the same value both times. It still allows a phantom read: a transaction counts rows matching a condition, a second transaction inserts a new row matching that same condition and commits, and when the first transaction runs the same count again, a "phantom" row appears that wasn't there moments ago.

Serializable, the strictest level, makes transactions behave as if they ran one at a time, completely sequentially - no dirty reads, no non-repeatable reads, no phantom reads. The cost is the most locking and the least real concurrency: genuinely correct, genuinely slower under contention.

Deadlocks: Two Transactions Waiting on Each Other Forever

A deadlock occurs when Transaction A holds a lock that Transaction B needs, while Transaction B simultaneously holds a lock that Transaction A needs. Neither can proceed, and neither will ever release its lock voluntarily, because each is waiting on the other.

The database engine detects this circular wait and picks one transaction to forcibly roll back, commonly called the deadlock victim, freeing its locks so the other transaction can proceed. The rolled-back transaction's application code typically needs to catch this specific error and decide whether to retry.

Deadlocks are a real, recurring production issue, not just an academic concept - they show up specifically when multiple transactions update the same set of rows in a different order from each other. A common, practical mitigation is ensuring application code always acquires locks on multiple rows in a consistent order across every code path, which prevents the circular wait from forming in the first place.

Key Lessons

Stored procedures gain a cached execution plan and centralized logic, at the cost of splitting business logic across two places and adding deployment friction.

A view is a saved query, not saved data - it re-runs the underlying query every time, and its main value is readability and abstraction, not performance.

A materialized view actually stores its result, trading staleness for speed, the same fundamental tradeoff as caching, implemented at the database layer.

ACID's four guarantees - Atomicity, Consistency, Isolation, Durability - are what make a transaction mean something more than just several statements run near each other.

Each stricter isolation level closes one specific, named gap the level below it leaves open - dirty reads, non-repeatable reads, and phantom reads each have a precise definition and a specific isolation level that prevents them.

Deadlocks are resolved automatically by the database killing one transaction, but the real fix is consistent lock ordering in application code to prevent the circular wait in the first place.

Where This Series Stands So Far

Part 1 covered joins - Inner, Left, Right, Full Outer, Cross, Self. Part 2 covered indexing - clustered, non-clustered, composite, and covering indexes, plus the honest write-cost tradeoff. Part 3 (this post) covered stored procedures, views, ACID, isolation levels, and deadlocks. Part 4 will cover normalization and schema design - 1NF through 3NF, and when denormalizing is actually the right call.

Summary

Stored procedures and views both package SQL for reuse, but in different ways - a stored procedure is precompiled and callable, a view is a saved query that looks like a table, and a materialized view actually stores its result at the cost of potential staleness. ACID defines what a real transaction guarantees. Isolation levels are the dial between strict correctness and concurrency, each stricter level closing one more specific gap. Deadlocks are the real, recurring cost of concurrent transactions competing for the same locked resources, resolved automatically but best prevented through consistent lock ordering. Together with joins and indexing, this rounds out three-quarters of the database knowledge that shows up constantly in both interviews and real production incidents - normalization completes the set in Part 4.

Originally published at TechStack Blog: https://www.techstackblog.com/post.html?slug=database-stored-procedures-transactions

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

Database Interview Topics Part 2: Indexing Explained - Clustered, Non-Clustered, and When an Index Makes Things Worse

Manohari Jayachandran — Mon, 27 Jul 2026 14:50:00 +0000

Part 1 of this series covered joins. This part covers indexing - specifically the honest version, not just "add an index and queries get faster." That advice is right about half the time. The other half, it's either the wrong fix for the actual problem, or it makes something else worse. This post covers what an index actually is, the different kinds, and the real tradeoffs each one carries.

A database table without an index answers a query by scanning every single row, in order, checking each one against the filter - a full table scan. An index is a separate data structure that lets the database jump directly to relevant rows instead, the same way a book's index at the back lets a reader jump to page 340 instead of reading every page until they find the right topic.

Clustered Index: The Physical Order of the Table Itself

A clustered index determines the actual physical order rows are stored in on disk. It's not a separate structure sitting alongside the table - the table itself is the clustered index, sorted by whatever column that index is built on.

Think of a physical dictionary. The words themselves are the data, and they're physically printed in alphabetical order - there's no separate "index of words" at the back, because the entire book already is that index. A clustered index works the same way: the table's actual storage order is the index.

-- A table with a clustered index on Id means rows
-- are physically stored in Id order
CREATE TABLE Posts (
    Id INT PRIMARY KEY CLUSTERED,  -- defines the
                                    -- physical order
    Title NVARCHAR(200),
    PublishedDate DATETIME
);

-- Because rows are physically ordered by Id, this
-- query is fast - it can jump straight to where
-- Id = 500 would physically be
SELECT * FROM Posts WHERE Id = 500;

-- A range query benefits enormously too - rows 100
-- through 200 are physically adjacent on disk
SELECT * FROM Posts WHERE Id BETWEEN 100 AND 200;

A table can have exactly one clustered index, because rows can only be physically stored in one order at a time. This is usually built on the primary key by default, but it doesn't have to be - it can be built on any column, and choosing the right one matters for tables with heavy range queries on a different column.

Non-Clustered Index: A Separate Structure Pointing Back to the Table

A non-clustered index is a genuinely separate structure from the table itself, holding a copy of the indexed column or columns plus a pointer back to the actual full row.

Think of the actual index section at the back of a non-fiction book. It doesn't contain the book's content - it contains a sorted list of terms, each with a page number pointing back to where the real content lives. Looking up "photosynthesis" in that index is fast specifically because the index itself is small and sorted, even though the real explanation lives many pages away.

-- A non-clustered index on Title, separate from
-- the table's physical (clustered) order by Id
CREATE INDEX IX_Posts_Title ON Posts(Title);

-- This query can now use the index to find matching
-- Titles quickly, then follow the pointer back to
-- the full row for the columns not in the index
SELECT * FROM Posts WHERE Title = 'Azure Key Vault';

-- Conceptually what happens:
-- 1. Search the small, sorted Title index - fast
-- 2. Find the pointer (usually the clustered key)
-- 3. Jump to that row in the actual table for
--    everything else (PublishedDate, etc.)

Unlike clustered indexes, a table can have many non-clustered indexes - one per column or column combination that gets filtered or sorted on frequently. Each one is a genuine tradeoff though, covered further down in this post.

Composite Index: Multiple Columns, and Why Order Matters

A composite index is built across more than one column together, rather than a separate single-column index for each.

-- A composite index on (LastName, FirstName) -
-- column ORDER in the index definition matters
CREATE INDEX IX_Employees_Name
    ON Employees(LastName, FirstName);

-- This query benefits fully - it filters on the
-- FIRST column in the index (LastName), which is
-- how the index is actually sorted
SELECT * FROM Employees WHERE LastName = 'Smith';

-- This query ALSO benefits - it filters on both
-- columns, matching the index's sort order exactly
SELECT * FROM Employees
WHERE LastName = 'Smith' AND FirstName = 'Alex';

-- This query gets LITTLE TO NO benefit from the
-- same index - it filters on FirstName alone, which
-- is the SECOND column, not how the index is sorted
SELECT * FROM Employees WHERE FirstName = 'Alex';

Column order in a composite index isn't cosmetic. Think of a phone book sorted by last name, then first name. Finding everyone with last name "Smith" is fast - they're all grouped together. Finding everyone with first name "Alex," regardless of last name, gets no help at all from that same sort order, since Alexes are scattered throughout the entire book. A composite index behaves identically: it only helps a query that filters starting from its leftmost column.

Covering Index: When the Index Alone Can Answer the Query

A covering index includes every single column a specific query needs, so the database can answer the query entirely from the index itself, without ever touching the actual table.

-- Without a covering index - Title is indexed, but
-- PublishedDate is not, so after finding a matching
-- Title, the database still has to jump to the
-- actual table row to get PublishedDate
CREATE INDEX IX_Posts_Title ON Posts(Title);

SELECT Title, PublishedDate
FROM Posts
WHERE Title = 'Azure Key Vault';

-- With a covering index - PublishedDate is added as
-- an INCLUDED column, so it lives inside the index
-- structure itself
CREATE INDEX IX_Posts_Title_Covering
    ON Posts(Title)
    INCLUDE (PublishedDate);

-- Now the SAME query above is answered entirely from
-- the index - the table itself is never touched at
-- all, which is the fastest possible outcome for a read

A covering index is genuinely the fastest read path available, but it duplicates more data into the index, increasing storage, and it's the first kind of index to quietly stop covering a query once that query changes to select one more column than the index includes - at which point it silently falls back to the slower table lookup, with no error or warning that this happened.

The Honest Part: When an Index Makes Things Worse

Every index speeds up specific reads. Every index also slows down every write to that table, because every INSERT, UPDATE, and DELETE has to update every index on the table, not just the actual row. A table with six indexes pays that update cost six times, on every single write, not once.

Several situations provide little to no real indexing benefit.

Low-cardinality columns are the first - a boolean IsActive column only has two possible values, and an index here rarely helps because the database still ends up scanning roughly half the table either way, with no meaningful narrowing happening.

Small tables are the second - a table with a few hundred rows can often be scanned faster than an index can be looked up and followed, since the overhead of using the index exceeds the cost of just reading the whole small table.

Columns rarely used in WHERE, JOIN, or ORDER BY clauses are the third - an index that nothing actually filters, joins, or sorts on provides zero read benefit while still paying the full write cost on every insert or update.

Write-heavy tables with comparatively few reads are the fourth - a table that's written to constantly but read from rarely pays the full write-side tax of every index without collecting much benefit on the read side.

The actual rule of thumb: an index is a bet that a specific column will be filtered, joined, or sorted on often enough that the read speedup is worth the write cost and storage cost. It is not a default good practice to apply everywhere - it's a targeted tool for a specific, identifiable access pattern.

Key Lessons

A clustered index is the table's physical storage order - exactly one per table, no exceptions.

A non-clustered index is a separate structure pointing back to the real row - many allowed per table, each one a genuine tradeoff.

Composite index column order determines what the index actually helps - it only benefits queries filtering from its leftmost column onward.

A covering index answers a query entirely from the index itself, but silently stops covering the moment a query needs one more column than it includes.

Every index speeds up specific reads while slowing down every write to that table - this tradeoff is real, not theoretical, and gets worse as more indexes accumulate.

Low-cardinality columns, small tables, rarely-filtered columns, and write-heavy tables are all real cases where an index provides little benefit while still costing something on every write.

What's Next

Part 3 of this series covers stored procedures, views, and transactions, including ACID properties and transaction isolation levels.

Summary

An index trades write cost and storage for read speed on a specific, identifiable access pattern - it is not a default good practice, it's a targeted tool. A clustered index is the table's own physical order, one per table. A non-clustered index is a separate lookup structure, many allowed, each with its own cost. A composite index only helps queries filtering from its leftmost column. A covering index is the fastest possible read, until a query outgrows what it includes. Knowing when an index genuinely helps, and being honest about the cases where it doesn't, is what separates real indexing knowledge from just knowing the CREATE INDEX syntax.

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

Part 1 of this series (Joins): 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

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