Logging Framework

Every application you've ever used produces invisible messages. When a user logs in, there's a log entry. When a payment fails, there's a log entry. When the server runs out of memory at 2 AM and crashes, the ONLY thing that tells you what happened is the log. Logging is the black box recorder of software — like the flight recorder on an airplane. You don't think about it until something goes wrong, and then it's the most important thing in the world.

But most developers treat logging as an afterthought: Console.WriteLine("something happened") sprinkled randomly through the code. No structure, no levelsLog levels are severity categories. DEBUG is for developers during coding. INFO is for normal operations. WARN means something unusual happened but we recovered. ERROR means something broke. FATAL means the app is going down. Levels let you filter noise from signal., no way to send logs to a file or a remote server, no context about what was happening when the message was written. That's not a logging system — that's shouting into the void and hoping someone hears.

Here's the thing: the difference between a junior developer's logging and a senior developer's logging isn't the framework they use — it's the thinking behind it. What to log, what NOT to log, how to structure it for searchability, how to avoid performance traps, how to make it testable. Those decisions come from understanding the architecture, not from importing a NuGet package.

We're going to build a real logging framework from scratch — the kind that powers SerilogThe most popular structured logging library for .NET. Serilog treats log data as structured events rather than text strings. Its "sinks" (destinations), "enrichers" (context adders), and "formatters" (output styles) are exactly the architecture we'll discover level by level., NLogA flexible .NET logging framework. NLog uses "targets" (our sinks), "layouts" (our formatters), and "rules" (our level filters). Different vocabulary, identical concepts., and log4net. 8 levels, each adding one constraint that breaks your previous code. By the end, you'll understand exactly why professional logging frameworks are designed the way they are — because you'll have reinvented their architecture from first principles.

Unlike a game (Tic-Tac-Toe) or a physical system (Parking Lot), logging is a cross-cutting concernA cross-cutting concern is something that touches every part of your application — not just one module. Logging, authentication, error handling, and caching are all cross-cutting. They don't belong to any single feature but weave through everything. — it touches every service, every controller, every background job. That's what makes it so interesting to design.

What makes logging a particularly rich design exercise? It touches nearly every pattern in the book. You need the Observer patternOne logger, many destinations. When a log message is produced, every registered "sink" gets notified. The logger doesn't know how many sinks exist or what they do — it just broadcasts. Adding a new sink requires zero changes to the logger. for routing to multiple destinations. You need StrategyDifferent formatting algorithms (plain text, JSON, XML) all do the same job — turn a LogEntry into a string — but in different ways. Swap the strategy without touching the logger. for swappable formatters. You need DecoratorEnrichers "wrap" the logging pipeline to add context (timestamps, thread IDs, user info) without modifying the core logger. Stack decorators to compose behavior: ThreadEnricher wrapping SourceEnricher wrapping the base logger. for layered enrichment. You need SingletonThe entire app shares one logger — but a DI-managed singleton (registered once in the service container), not a static field. This keeps it testable and mockable, unlike the old static Logger.Instance approach. for a shared instance. It's a design pattern playground disguised as a utility class.

Before we write a single line of code, let's think about what logging actually looks like in real life. Not in a framework — in the physical world. Imagine you're a factory manager watching your production line. Things go wrong. Machines break, workers call in sick, deliveries arrive late. How do you keep track of what happened? You write it down in a log book. Each entry has a date, a description of what happened, and how serious it was. That same idea — that exact same structure — drives every logging framework ever built.

The genius of the "real-world walkthrough" technique is that it gives you the architecture for free. You don't need to know design patterns. You don't need 10 years of experience. You just need to observe the real-world process carefully and translate it to code. The nouns become classes. The verbs become methods. The relationships become interfaces. Let's do it.

This is also the answer to one of the most common interview questions: "How do you decide which design pattern to use?" The answer is: you don't pick patterns from a menu. You observe the problem, ask "what varies independently?", and the right pattern emerges naturally. The real world is the world's best design pattern instructor.

Think our walkthrough was just theoretical? Let's check how our discoveries map to the real frameworks that millions of .NET developers use every day:

Different names, identical concepts. The real-world walkthrough gave us the same architecture that professional framework authors arrived at independently. Serilog calls it a "Sink," NLog calls it a "Target," log4net calls it an "Appender" — but they're all the same thing: a destination that receives log entries. The names are cosmetic; the structure is universal. When you understand the structure, you can learn any framework in minutes instead of hours.

Every great framework starts as a humble one-liner. For logging, that means: someone hands you a message, you write it to the console with a timestamp. That's it. No severity levels, no file output, no structured data — just the bare minimum that technically qualifies as "logging." The goal of Level 0 is to get something working, then let the next constraint break it.

Why start this simple? Because the constraints reveal the design. If we start with ILogSink and ILogFormatter on day one, we're guessing at what we'll need. That's premature abstractionAdding interfaces, patterns, and layers of indirection before you know you need them. It feels productive ("look how clean this is!") but it actually makes the code harder to understand and change, because you're guessing at future requirements. Let the constraints tell you when to abstract. — one of the most common traps in software design.

But when Level 1 says "distinguish INFO from ERROR" and our simple logger can't do it — that pain tells us exactly what abstraction to add. When Level 2 says "write to a file too" and we can't because Console.WriteLine is hardcoded — that's when the ILogSink interface earns its existence. Each pain point is a signpost pointing toward the right design decision. No guessing needed.

Your Internal Monologue

"OK, simplest thing possible... A class with a Log() method that writes to the console. I could just make it a static method — Logger.Log("hello"). That's even simpler. One line, no new keyword needed."

"But wait... if I make it static, where does configuration go? When I add sinks and levels later, I'd need static fields for state. That makes it a global mutable state nightmare. And impossible to mock in tests. Hmm."

"Actually, let me make it an instance class instead. It's two extra lines for the caller (var logger = new SimpleLogger();), but it sets us up for everything that comes later. Configuration becomes fields. Different configs become different instances. And I can extract an ILogger interface later for testability."

"For the timestamp... DateTime.Now? No, DateTime.UtcNow. If this ever runs on servers in different time zones, UTC is the only sane choice. And I'll include milliseconds — when two things happen within the same second, ordering matters. Small details, but the kind of details that save you at 2 AM."

"Format: [timestamp] message. Simple, readable, grepable. I know this is incomplete — no levels, no flexibility — but that's OK. Level 0 is about getting started, not getting it perfect. I can already see 4 things that are wrong with this. Good. That's fuel for the next levels."

public static class Logger
{
    public static void Log(string message)
    {
        Console.WriteLine($"[{DateTime.UtcNow:yyyy-MM-dd HH:mm:ss}] {message}");
    }
}

// Usage:
Logger.Log("Application started");

public sealed class SimpleLogger
{
    public void Log(string message)
    {
        Console.WriteLine($"[{DateTime.UtcNow:yyyy-MM-dd HH:mm:ss}] {message}");
    }
}

// Usage:
var logger = new SimpleLogger();
logger.Log("Application started");

Here's the complete Level 0 code. Read every line — there are only about 10 of them.

public sealed class SimpleLogger
{
    public void Log(string message)
    {
        var timestamp = DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss.fff");
        Console.WriteLine($"[{timestamp}] {message}");
    }
}

Let's walk through each piece and understand why it's there:

• sealed class — sealedIn C#, marking a class "sealed" means no one can inherit from it. This is a good default for classes you don't explicitly design for inheritance. It communicates intent: "this class is complete as-is." The .NET performance team recommends sealing classes by default because the JIT compiler can optimize sealed method calls. because we don't need inheritance at this level. It communicates "this class is complete as-is" to anyone reading the code.
• Log(string message) — the single entry point. The caller provides a human-readable message; the logger handles everything else (timestamp, formatting, output). This is the Single Responsibility PrincipleThe S in SOLID: a class should have only one reason to change. The caller's job is to decide WHAT to log. The logger's job is to decide HOW to log it. Neither touches the other's responsibility. in action: the caller decides what to log, the logger decides how.
• DateTime.UtcNow — UTC timestamp with milliseconds (.fff). Why UTC and not local time? Imagine your app runs on servers in New York, London, and Tokyo. If each server logs in local time, correlating events across regions becomes a nightmare. UTC gives you one consistent timeline everywhere. And milliseconds matter when you're debugging race conditionsA race condition happens when two things happen at almost the same time and the outcome depends on which one finishes first. Millisecond-precision timestamps help you see the exact ordering of events when debugging these tricky bugs. or ordering events that happened within the same second.
• Console.WriteLine — the only output destination. This is hardcoded, which is fine for Level 0 but will become a problem when we need files, remote servers, or cloud dashboards. The hardcoded dependency on Console is exactly the kind of "tight coupling" that patterns like Dependency InversionThe D in SOLID. Instead of depending on concrete classes (Console), depend on abstractions (ILogSink). This lets you swap Console for File or HTTP without changing the logger. We'll implement this in Level 2. exist to solve — we'll get there in Level 2.

Notice the deliberate choices here. We used DateTime.UtcNow instead of DateTime.Now (timezone safety). We included milliseconds in the format (ordering precision). We made the class sealed (signals it's not designed for inheritance). We used string interpolationC# feature where $"[{timestamp}] {message}" embeds variables directly in the string. Cleaner than string.Format() or concatenation with +. The compiler optimizes it to a single string allocation. for clean formatting. Small decisions, but each one matters when you're building infrastructure that the entire application depends on.

Quick test to prove it works:

var logger = new SimpleLogger();
logger.Log("Application started");
logger.Log("Processing user request...");
logger.Log("Request completed successfully");

// Output:
// [2025-01-15 14:32:07.123] Application started
// [2025-01-15 14:32:07.125] Processing user request...
// [2025-01-15 14:32:07.128] Request completed successfully

10 lines. It works. But can you already see what's missing?

• No severity distinction — "Application started" (routine) and "Database connection failed" (critical) look exactly the same. In production, you'd have to read every line to find the important ones.
• One destination — console only. Close the terminal window and your logs are gone forever. No file backup, no cloud dashboard, nothing.
• No context — which class logged this? Which thread? Which user was being served? With 50 services running, a bare message like "timeout" tells you almost nothing.
• No filtering — in development you want to see everything. In production you want to see only warnings and errors. Right now there's no way to control verbosity without changing code.

We'll feel each of these pains in the coming levels. That's the point of incremental design — you don't add complexity until you need it.

// Scattered throughout the codebase...
Console.WriteLine("starting payment");
Console.WriteLine("payment ok");
Console.WriteLine("error happened");
Console.WriteLine("retrying...");
Console.WriteLine("done");

// Output:
// starting payment
// payment ok
// error happened
// retrying...
// done
//
// When did "error happened" occur? Which service?
// How severe? No idea.

var logger = new SimpleLogger();
logger.Log("Starting payment processing");
logger.Log("Payment completed successfully");
logger.Log("Error: card declined for order #4521");
logger.Log("Retrying payment with fallback provider");
logger.Log("Payment retry succeeded");

// Output:
// [2025-01-15 14:32:07.123] Starting payment processing
// [2025-01-15 14:32:07.456] Payment completed successfully
// [2025-01-15 14:32:07.789] Error: card declined for order #4521
// [2025-01-15 14:32:08.012] Retrying payment with fallback provider
// [2025-01-15 14:32:08.234] Payment retry succeeded
//
// Now we know WHEN each thing happened.
// Centralized format. Easy to grep.

[2025-01-15 14:32:07.123] User signed in
[2025-01-15 14:32:07.456] Payment failed

[14:32:07 INF] [AuthService] [Thread:12] [User:john@acme.com] User signed in
[14:32:07 ERR] [PaymentService] [Thread:15] [User:jane@acme.com] Payment failed
  CardType=Visa LastFour=4521 Amount=99.99
  System.Net.Http.HttpRequestException: Connection refused

Growing Diagram — After Level 0

Before / After Your Brain

Every item in the "Lacks" column becomes a constraint in one of the next 7 levels. That's how incremental design works — the gaps in your current solution are the roadmap for what comes next. This is also how you should present in an interview: "Here's my simplest version. Here are 4 things wrong with it. Let me evolve it." That progression shows design thinking, not design memorizing.

Real logging systems have a severity ladder. Think of it like a volume knob — you set a minimum level, and anything quieter gets ignored. In development you crank it all the way down to Debug so you see everything. In production you turn it up to Warning so only important stuff gets through. Same code, different verbosity, zero changes.

Your Internal Monologue

"Right now every message is just a string. I need to tag each message with a severity. I could use strings like "DEBUG", "ERROR"... but then filtering means string comparison, and someone could typo "DEBG" and it'd silently pass through."

"An enum is better — the compiler catches typos. And if I give them ascending numbers, I can filter with a single >= check. Debug is 0, Info is 1, Warning is 2, Error is 3, Fatal is 4. If minimum is Warning (2), then Debug (0) and Info (1) are below — filtered out. Error (3) and Fatal (4) are above — they pass. That's... really elegant."

"I also need to bundle the level WITH the message. A plain string won't cut it anymore. I need a recordA C# record is an immutable data type — once created, its values can't change. Perfect for log entries because a log message should never be modified after it's created. Records also get free equality comparison and a nice ToString() output. — LogEntry — that carries the level, the message, and a timestamp. Immutable, because you should never edit a log after the fact."

The Severity Ladder

Five levels, ordered from least critical to most. Each level includes everything above it — setting minimum to Warning means you also see Error and Fatal.

The Filter in Action

Set the minimum to Warning. Everything below that line gets silently dropped. Everything at or above passes through.

public void Log(string level, string message)
{
    // "DEBUG", "INFO", "WARNING"...
    // How do you compare? Alphabetical won't work.
    // "DEBUG" < "ERROR" alphabetically, but
    // "WARNING" > "INFO"? Good luck filtering.
    if (ShouldLog(level))
        Console.WriteLine($"[{level}] {message}");
}

// Caller can pass ANYTHING: "DEBG", "warn", "CRITICAL"
// No compile-time safety. Typos become silent bugs.

public const int DEBUG = 0;
public const int INFO = 1;
public const int WARNING = 2;
public const int ERROR = 3;
public const int FATAL = 4;

public void Log(int level, string message)
{
    if (level >= _minimumLevel)
        Console.WriteLine($"[{level}] {message}");
}

// Filtering works! But...
// Log(42, "oops") compiles fine. What's level 42?
// Log output shows "[2] Cache miss" — what's 2?

public enum LogLevel { Debug = 0, Info = 1, Warning = 2, Error = 3, Fatal = 4 }

public record LogEntry(LogLevel Level, string Message, DateTime Timestamp);

public void Log(LogLevel level, string message)
{
    if (level >= MinimumLevel)  // One comparison. Done.
    {
        var entry = new LogEntry(level, message, DateTime.UtcNow);
        Console.WriteLine($"[{entry.Level}] {entry.Message}");
    }
}

// Log(LogLevel.Debug, "click") — clear, safe, filterable
// Log(42, "oops") — COMPILE ERROR. Can't happen.

The Solution

Three small pieces: an enum to rank severity, a record to bundle each log entry, and a one-line filter that drops anything below your threshold.

public enum LogLevel
{
    Debug   = 0,   // Developer-only noise: variable values, method entry/exit
    Info    = 1,   // Normal operations: "request processed", "user logged in"
    Warning = 2,   // Something odd but recoverable: cache miss, retry needed
    Error   = 3,   // Something failed: timeout, invalid input, caught exception
    Fatal   = 4    // System is dying: out of memory, database unreachable
}

public record LogEntry(
    LogLevel  Level,      // How severe is this?
    string    Message,    // What happened?
    DateTime  Timestamp   // When did it happen?
);

// Usage:
// var entry = new LogEntry(LogLevel.Error, "Timeout", DateTime.UtcNow);
// entry.Message = "changed"; // COMPILE ERROR — records are immutable

public class Logger
{
    public LogLevel MinimumLevel { get; set; } = LogLevel.Debug; // Level 1: configurable threshold

    public void Log(LogLevel level, string message)
    {
        if (level < MinimumLevel) return;  // The entire filter — one line

        var entry = new LogEntry(level, message, DateTime.UtcNow);
        Console.WriteLine($"[{entry.Timestamp:HH:mm:ss}] [{entry.Level}] {entry.Message}");
    }

    // Convenience methods — so callers don't repeat LogLevel every time
    public void Debug(string msg)   => Log(LogLevel.Debug, msg);
    public void Info(string msg)    => Log(LogLevel.Info, msg);
    public void Warning(string msg) => Log(LogLevel.Warning, msg);
    public void Error(string msg)   => Log(LogLevel.Error, msg);
    public void Fatal(string msg)   => Log(LogLevel.Fatal, msg);
}

Growing Diagram — Level 1

Level 0 was just a Logger with Log(string). Now we've added LogLevel, LogEntry, and filtering. New pieces are highlighted.

Before / After Your Brain

Think about it this way: the act of writing a log entry is the same idea regardless of where it goes. Console, file, database, Slack — they all do the same thing (receive a log entry and put it somewhere) but in different ways. When you have multiple ways to do the same thing, and you want to swap or combine them freely, that's the textbook signal for the Strategy patternThe Strategy pattern defines a family of interchangeable algorithms behind a common interface. The caller picks which strategy to use at runtime without knowing the implementation details. Here, each "sink" (destination) is a strategy for writing logs..

Your Internal Monologue

"I could just add more Console.WriteLine() and File.AppendAllText() calls inside Log()... but that's the same mistake as hardcoding pricing strategies in the Parking Lot. Every new destination means modifying the Logger class. That's an OCP violationThe Open/Closed Principle says a class should be open for extension (add new behavior) but closed for modification (don't change existing code). Adding a new sink should extend the system, not modify the Logger.."

"What if I make each destination its own class? They all do the same thing — take a LogEntry and put it somewhere. That's a common interfaceAn interface in C# defines a contract: "any class that implements me promises to have these methods." ILogSink says: "I promise I have a Write(LogEntry) method." The Logger doesn't care HOW you write — just that you CAN.: ILogSink with a Write(LogEntry) method."

"And I don't just want ONE sink — I want multiple simultaneously. So the Logger holds a List<ILogSink>. When a log comes in, loop through the list and call Write() on each one. Fan-out! Adding Slack later? Create SlackSink : ILogSink, add it to the list. Done. Not a single existing file touched."

The Fan-Out: One Entry, Many Destinations

A single log entry enters the Logger, passes the level filter, then gets broadcast to every registered sink. Each sink writes it to its own destination independently.

public void Log(LogLevel level, string message)
{
    if (level < MinimumLevel) return;
    var entry = new LogEntry(level, message, DateTime.UtcNow);

    switch (_destinationType)
    {
        case "console":
            Console.WriteLine($"[{entry.Level}] {entry.Message}");
            break;
        case "file":
            File.AppendAllText(_path, $"[{entry.Level}] {entry.Message}\n");
            break;
        case "database":
            // ADO.NET insert...
            break;
        // Adding Slack? Add another case here. And here. And here.
    }
}

public void Log(LogLevel level, string message)
{
    if (level < MinimumLevel) return;
    var entry = new LogEntry(level, message, DateTime.UtcNow);

    if (_useConsole)
        Console.WriteLine($"[{entry.Level}] {entry.Message}");
    if (_useFile)
        File.AppendAllText(_path, $"[{entry.Level}] {entry.Message}\n");
    if (_useDatabase)
        ExecuteDbInsert(entry);
    if (_useSlack)
        PostToSlack(entry);
    // Every new destination = new boolean + new if-block
}

public interface ILogSink
{
    void Write(LogEntry entry);
}

public class Logger
{
    private readonly List<ILogSink> _sinks;
    public LogLevel MinimumLevel { get; set; } = LogLevel.Debug;

    public Logger(params ILogSink[] sinks)
        => _sinks = new List<ILogSink>(sinks);

    public void Log(LogLevel level, string message)
    {
        if (level < MinimumLevel) return;
        var entry = new LogEntry(level, message, DateTime.UtcNow);
        foreach (var sink in _sinks)
            sink.Write(entry);  // Fan-out: every sink gets the entry
    }
}

// Adding Slack = one new class, zero changes to Logger:
// public class SlackSink : ILogSink { ... }

Plug & Play: Configure Any Combination

Different environments, different sinks. The Logger's code is identical in all three — only the List<ILogSink> changes.

The Solution

One interface, three implementations, and a Logger that loops through them. The Logger never mentions Console, File, or Database by name — it only knows ILogSink.

public interface ILogSink
{
    void Write(LogEntry entry);
}

// That's it. One method. Every sink — Console, File, Database,
// Slack, Email, whatever comes next — just implements Write().
// The Logger never knows or cares what's on the other side.

public class ConsoleSink : ILogSink
{
    public void Write(LogEntry entry)
    {
        var color = entry.Level switch
        {
            LogLevel.Fatal   => ConsoleColor.Red,
            LogLevel.Error   => ConsoleColor.Red,
            LogLevel.Warning => ConsoleColor.Yellow,
            LogLevel.Info    => ConsoleColor.Cyan,
            _                => ConsoleColor.Gray
        };

        Console.ForegroundColor = color;
        Console.WriteLine($"[{entry.Timestamp:HH:mm:ss}] [{entry.Level}] {entry.Message}");
        Console.ResetColor();
    }
}

public class FileSink : ILogSink
{
    private readonly string _path;

    public FileSink(string path) => _path = path;

    public void Write(LogEntry entry)
    {
        var line = $"[{entry.Timestamp:yyyy-MM-dd HH:mm:ss}] [{entry.Level}] {entry.Message}";
        File.AppendAllText(_path, line + Environment.NewLine);
    }
}

public class Logger
{
    private readonly List<ILogSink> _sinks;                       // Level 2: multiple sinks
    public LogLevel MinimumLevel { get; set; } = LogLevel.Debug;   // Level 1: filtering

    public Logger(params ILogSink[] sinks)
        => _sinks = new List<ILogSink>(sinks);

    public void Log(LogLevel level, string message)
    {
        if (level < MinimumLevel) return;                          // Level 1: filter
        var entry = new LogEntry(level, message, DateTime.UtcNow);
        foreach (var sink in _sinks)                                // Level 2: fan-out
            sink.Write(entry);
    }

    // Convenience methods (unchanged from Level 1)
    public void Debug(string msg)   => Log(LogLevel.Debug, msg);
    public void Info(string msg)    => Log(LogLevel.Info, msg);
    public void Warning(string msg) => Log(LogLevel.Warning, msg);
    public void Error(string msg)   => Log(LogLevel.Error, msg);
    public void Fatal(string msg)   => Log(LogLevel.Fatal, msg);
}

Before vs. After: Adding Slack

The real test: what happens when requirements change? Left: Slack means cracking open Logger. Right: Slack means creating one file.

Growing Diagram — Level 2

The class diagram expands: ILogSink interface appears, concrete sinks implement it, and the Logger holds a list of them.

Before / After Your Brain

Imagine a Russian nesting dollMatryoshka dolls — each doll wraps around a smaller one. Open the outer doll, there's another inside. In code, a Decorator wraps around an existing object, adding behavior before/after delegating to the inner object. You can stack as many layers as you want.. The innermost doll is your FileSink — it knows how to write to a file. You wrap it in a "timestamp doll" that prepends a timestamp before passing the entry inward. Wrap that in a "thread ID doll" that adds the thread number. Each layer adds one piece of context, then hands off to the layer beneath. The sink at the center has no idea it's being wrapped. That's the Decorator patternThe Decorator pattern attaches new behavior to an object by wrapping it. The wrapper implements the same interface as the wrapped object, so the caller can't tell the difference. You can stack multiple decorators like layers of an onion — each one adds something and delegates the rest..

Your Internal Monologue

"I could add $"[{DateTime.UtcNow}] " + entry.Message inside ConsoleSink. And inside FileSink. And inside DatabaseSink. That's three places with the same timestamp logic. What happens when the team wants thread ID too? Three more copy-paste edits. This is heading toward a maintenance disaster."

"Wait — what if I wrap the sink instead of modifying it? Something that takes in an ILogSink, enriches the message, then calls the inner sink's Write(). That wrapper would ALSO implement ILogSink, so from the outside it looks identical. The caller doesn't know whether it's talking to a raw sink or a wrapped one."

"And if the wrapper is also an ILogSink, I can wrap a wrapper! ThreadIdDecorator wrapping TimestampDecorator wrapping FileSink. Each layer adds one thing. Like Russian dolls. ...That's the Decorator patternA structural design pattern where you wrap an object with another object that has the same interface. The wrapper adds behavior before/after delegating to the wrapped object. Since both share the same interface, decorators are stackable — you can nest as many as you want.!"

The Russian Doll: Decorators Wrapping a Sink

Each decorator wraps the next. The outermost one receives the log entry first, adds its context, and passes it inward. The innermost (FileSink) just writes.

The Delegation Chain: Step by Step

Follow a single log entry as it passes through the decorator stack. Each layer enriches the message, then delegates to the inner sink.

public class ConsoleSink : ILogSink
{
    public void Write(LogEntry entry)
    {
        // Enrichment copy-pasted into EVERY sink:
        var enriched = $"[{DateTime.UtcNow:HH:mm:ss}] " +
                       $"[Thread-{Thread.CurrentThread.ManagedThreadId}] " +
                       $"[{entry.Level}] {entry.Message}";
        Console.WriteLine(enriched);
    }
}

// Same 3 lines duplicated in FileSink, DatabaseSink, SlackSink...
// Change the timestamp format? Modify ALL of them.

public abstract class EnrichedSink : ILogSink
{
    public void Write(LogEntry entry)
    {
        var enriched = $"[{DateTime.UtcNow:HH:mm:ss}] " +
                       $"[Thread-{Thread.CurrentThread.ManagedThreadId}] " +
                       $"[{entry.Level}] {entry.Message}";
        var newEntry = entry with { Message = enriched };
        WriteCore(newEntry);
    }

    protected abstract void WriteCore(LogEntry entry);
}

// ConsoleSink : EnrichedSink, FileSink : EnrichedSink...
// But what if you want timestamp WITHOUT thread ID?
// Or thread ID WITHOUT timestamp?
// Can't mix and match. All or nothing.

// Base: wraps any ILogSink
public abstract class SinkDecorator : ILogSink
{
    protected readonly ILogSink _inner;
    protected SinkDecorator(ILogSink inner) => _inner = inner;
    public abstract void Write(LogEntry entry);
}

// Each decorator adds ONE thing, then delegates
public class TimestampDecorator : SinkDecorator
{
    public TimestampDecorator(ILogSink inner) : base(inner) { }

    public override void Write(LogEntry entry)
    {
        var enriched = entry with
        {
            Message = $"[{DateTime.UtcNow:HH:mm:ss}] {entry.Message}"
        };
        _inner.Write(enriched);  // pass inward
    }
}

// Stack them: ThreadId(Timestamp(FileSink))
// Mix freely: Timestamp(ConsoleSink) — no thread ID
// Add CallerInfo? One new class. Zero existing changes.

Mix & Match: Any Combination Works

Because every decorator is an ILogSink, you can compose them like LEGO bricks. Different sinks can have different enrichments.

The Solution

A base SinkDecorator class, plus one decorator per enrichment. Each wraps an inner ILogSink, enhances the entry, and delegates. Stack freely.

public abstract class SinkDecorator : ILogSink
{
    protected readonly ILogSink _inner;

    protected SinkDecorator(ILogSink inner)
        => _inner = inner ?? throw new ArgumentNullException(nameof(inner));

    public abstract void Write(LogEntry entry);
}

// Key insight: SinkDecorator IS an ILogSink (implements the interface)
// AND it HAS an ILogSink (holds a reference to the inner sink).
// This dual identity is what makes stacking possible.

public class TimestampDecorator : SinkDecorator
{
    public TimestampDecorator(ILogSink inner) : base(inner) { }

    public override void Write(LogEntry entry)
    {
        // Enrich: prepend timestamp to the message
        var enriched = entry with
        {
            Message = $"[{DateTime.UtcNow:HH:mm:ss}] {entry.Message}"
        };

        // Delegate: pass enriched entry to whatever's inside
        _inner.Write(enriched);
    }
}

public class ThreadIdDecorator : SinkDecorator
{
    public ThreadIdDecorator(ILogSink inner) : base(inner) { }

    public override void Write(LogEntry entry)
    {
        var threadId = Environment.CurrentManagedThreadId;
        var enriched = entry with
        {
            Message = $"[Thread-{threadId}] {entry.Message}"
        };
        _inner.Write(enriched);
    }
}

// Want CallerInfoDecorator? Same pattern:
// public class CallerInfoDecorator : SinkDecorator { ... }
// ONE new file. Zero existing changes. Ever.

// Dev: console with timestamp only
ILogSink devSink = new TimestampDecorator(
    new ConsoleSink()
);

// Production: file with full enrichment
ILogSink prodFileSink = new ThreadIdDecorator(
    new TimestampDecorator(
        new FileSink("app.log")
    )
);

// DB: no decorators needed (columns handle metadata)
ILogSink dbSink = new DatabaseSink(connectionString);

// Wire them all into the Logger
var logger = new Logger(devSink, prodFileSink, dbSink);

// This one call fans out to 3 sinks, 2 of them decorated:
logger.Error("Payment failed");
// Console: [14:32:05] [Error] Payment failed
// File:    [Thread-7] [14:32:05] [Error] Payment failed
// DB:      INSERT INTO logs (Level, Message, ...)

Inheritance vs. Decorator: The Flexibility Gap

With a base class, every sink gets the same enrichments. With decorators, each sink gets exactly what it needs — no more, no less.

Growing Diagram — Level 3

SinkDecorator joins the diagram. It implements ILogSink AND holds a reference to one — the IS-A / HAS-A duality. Concrete decorators extend it.

Before / After Your Brain

Your inner voice:

"I need exactly one instance. The simplest thing is a static class — you literally can't instantiate it. But then I can't swap it out in tests, and I can't put it behind an interface."

"A global static field like Logger.Instance is the classic Singleton patternA design pattern that ensures a class has only one instance and provides a global point of access to it. Think of it like a company having exactly one CEO — everyone in the company can reach the CEO, and there's never a second one.. It works, but every class that uses Logger.Instance is silently coupled to the concrete type. Hard to test, hard to replace."

"The modern approach: register the logger as a singleton lifetime in the DI container. The container creates one instance, hands the same one to everyone who asks, and I still program against an interface. Best of all worlds."

Three Ways to Get "One Logger"

What Would You Do?

Three developers, three ways to guarantee "one logger." Only one survives the "now write a unit test" challenge.

public static class Logger
{
    private static readonly List<ILogSink> _sinks = [];
    private static readonly object _lock = new();

    public static void AddSink(ILogSink sink) { lock (_lock) _sinks.Add(sink); }

    public static void Log(LogLevel level, string message)
    {
        lock (_lock)
        {
            foreach (var sink in _sinks)
                sink.Write(level, message);
        }
    }
}

// Usage — no instance, just static calls
Logger.Log(LogLevel.Info, "App started");

public sealed class Logger : ILogger
{
    private static readonly Lazy<Logger> _instance = new(() => new Logger());
    public static Logger Instance => _instance.Value;

    private readonly List<ILogSink> _sinks = [];
    private readonly object _lock = new();

    private Logger() { }   // private ctor — no one else can create

    public void AddSink(ILogSink sink) { lock (_lock) _sinks.Add(sink); }

    public void Log(LogLevel level, string message)
    {
        lock (_lock)
        {
            foreach (var sink in _sinks)
                sink.Write(level, message);
        }
    }
}

// Usage — global access
Logger.Instance.Log(LogLevel.Info, "App started");

// Program.cs — register once, container manages lifetime
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton<ILogger>(sp =>
{
    var logger = new Logger(LogLevel.Debug);
    logger.AddSink(new ConsoleSink());
    logger.AddSink(new FileSink("app.log"));
    return new TimestampDecorator(
           new ThreadIdDecorator(logger));
});

// Any class just asks for ILogger in its constructor
public class OrderService(ILogger logger)
{
    public void PlaceOrder(Order order)
    {
        logger.Log(LogLevel.Info, $"Order {order.Id} placed");
    }
}

The Solution — Thread-Safe Logger + DI Registration

The logger needs to be thread-safeThread-safe means multiple threads can call the same method at the same time without corrupting data. In a web app, dozens of requests hit your logger simultaneously. Without thread safety, log entries get garbled, interleaved, or lost. because in a web application, dozens of requests hit the logger simultaneously. We use lock to ensure only one thread writes at a time.

public sealed class Logger : ILogger
{
    private readonly List<ILogSink> _sinks = [];
    private readonly LogLevel _minLevel;
    private readonly object _lock = new();  // guards shared state

    public Logger(LogLevel minLevel) => _minLevel = minLevel;

    public void AddSink(ILogSink sink)
    {
        lock (_lock) _sinks.Add(sink);
    }

    public void Log(LogLevel level, string message)
    {
        if (level < _minLevel) return;      // filter first (cheap)

        lock (_lock)                         // then write (one at a time)
        {
            foreach (var sink in _sinks)
                sink.Write(level, message);
        }
    }
}

var builder = WebApplication.CreateBuilder(args);

// One logger instance, shared app-wide
builder.Services.AddSingleton<ILogger>(sp =>
{
    var core = new Logger(LogLevel.Debug);
    core.AddSink(new ConsoleSink());
    core.AddSink(new FileSink("logs/app.log"));

    // Wrap with decorators (from Level 3)
    ILogger decorated = core;
    decorated = new CallerInfoDecorator(decorated);
    decorated = new ThreadIdDecorator(decorated);
    decorated = new TimestampDecorator(decorated);

    return decorated;  // everyone gets THIS decorated instance
});

builder.Services.AddScoped<OrderService>();
builder.Services.AddScoped<PaymentService>();

var app = builder.Build();
app.Run();

// The service has NO idea whether the logger is a singleton,
// a transient, or a scoped instance. It just uses ILogger.
public class OrderService(ILogger logger)
{
    public void PlaceOrder(Order order)
    {
        logger.Log(LogLevel.Info, $"Placing order {order.Id}");

        try
        {
            // ... process order ...
            logger.Log(LogLevel.Info, $"Order {order.Id} completed");
        }
        catch (Exception ex)
        {
            logger.Log(LogLevel.Error, $"Order {order.Id} failed: {ex.Message}");
            throw;
        }
    }
}

How lock() Protects the Logger

Growing Diagram — Level 4

Four Production Problems

Your inner voice:

"The beautiful thing is — we already built the extension points. File rotation? That's a smarter FileSink (Strategy). Async? That's a new Decorator that queues entries. Rate limiting? Another Decorator. Structured data? A richer LogEntry type instead of a bare string. Each feature slots into the existing architecture without rewriting anything."

What If? Framework

Each tab is a production scenario. Read the problem, then expand the solution.

public sealed class RotatingFileSink : ILogSink, IDisposable
{
    private readonly string _basePath;
    private readonly long _maxBytes;
    private StreamWriter _writer;
    private long _currentSize;

    public RotatingFileSink(string basePath, long maxBytes = 10 * 1024 * 1024)
    {
        _basePath = basePath;
        _maxBytes = maxBytes;
        _writer = new StreamWriter(basePath, append: true);
        _currentSize = new FileInfo(basePath).Length;
    }

    public void Write(LogLevel level, string message)
    {
        if (_currentSize >= _maxBytes)
            Rotate();

        _writer.WriteLine(message);
        _writer.Flush();
        _currentSize += Encoding.UTF8.GetByteCount(message) + 2;
    }

    private void Rotate()
    {
        _writer.Dispose();
        var archive = _basePath.Replace(".log",
            $"-{DateTime.UtcNow:yyyy-MM-dd-HHmmss}.log");
        File.Move(_basePath, archive);
        _writer = new StreamWriter(_basePath, append: false);
        _currentSize = 0;
    }

    public void Dispose() => _writer.Dispose();
}

public sealed class AsyncLoggerDecorator : ILogger, IAsyncDisposable
{
    private readonly ILogger _inner;
    private readonly Channel<(LogLevel, string)> _channel;
    private readonly Task _worker;

    public AsyncLoggerDecorator(ILogger inner, int capacity = 1024)
    {
        _inner = inner;
        _channel = Channel.CreateBounded<(LogLevel, string)>(capacity);
        _worker = Task.Run(ProcessQueue);   // background consumer
    }

    public void Log(LogLevel level, string message)
    {
        // Non-blocking: if the channel is full, drop the message
        _channel.Writer.TryWrite((level, message));
    }

    private async Task ProcessQueue()
    {
        await foreach (var (level, msg) in _channel.Reader.ReadAllAsync())
        {
            _inner.Log(level, msg);   // actual write happens here
        }
    }

    public async ValueTask DisposeAsync()
    {
        _channel.Writer.Complete();
        await _worker;                // drain remaining messages
    }
}

// Instead of just a string, carry key-value pairs
public sealed record LogEntry
{
    public required LogLevel Level { get; init; }
    public required string Message { get; init; }
    public DateTime Timestamp { get; init; } = DateTime.UtcNow;
    public Dictionary<string, object> Properties { get; init; } = [];
}

// Usage: attach context to every log message
logger.Log(new LogEntry
{
    Level = LogLevel.Error,
    Message = "Payment failed",
    Properties =
    {
        ["OrderId"] = 42,
        ["UserId"] = "user-789",
        ["Amount"] = 99.95m,
        ["Gateway"] = "Stripe"
    }
});

// Now you can search: WHERE Properties["OrderId"] = 42
// Or export as JSON for Elasticsearch / ELK

public sealed class RateLimitDecorator : ILogger
{
    private readonly ILogger _inner;
    private readonly TimeSpan _window;
    private readonly Dictionary<string, (DateTime LastSeen, int Count)> _recent = [];

    public RateLimitDecorator(ILogger inner, TimeSpan? window = null)
    {
        _inner = inner;
        _window = window ?? TimeSpan.FromSeconds(30);
    }

    public void Log(LogLevel level, string message)
    {
        var now = DateTime.UtcNow;

        if (_recent.TryGetValue(message, out var entry)
            && now - entry.LastSeen < _window)
        {
            _recent[message] = (entry.LastSeen, entry.Count + 1);
            return;  // suppressed — same message within window
        }

        // Emit suppression notice if we held back duplicates
        if (entry.Count > 0)
            _inner.Log(level, $"(suppressed {entry.Count} duplicates)");

        _recent[message] = (now, 0);
        _inner.Log(level, message);
    }
}

Growing Diagram — Level 5

Your inner voice:

"The key insight is: we already did most of the work. ILogger and ILogSink are interfaces from Level 0-2. Creating a TestSink is trivial — it implements ILogSink and stores messages in a List<string>. For timestamps, I need to extract DateTime.UtcNow behind an ITimeProvider — .NET 8 even ships one built-in (TimeProvider). For testing services that use the logger, I just pass a TestSink-backed logger through the constructor. DI made this trivially easy."

Production vs. Test Wiring

The Solution — Test Doubles

We need three small pieces: a TestSink to capture output, a FakeClock to freeze time, and an ITimeProvider interface to make time injectable.

// Captures everything that was logged — like a tape recorder
public sealed class TestSink : ILogSink
{
    public List<(LogLevel Level, string Message)> Entries { get; } = [];

    public void Write(LogLevel level, string message)
        => Entries.Add((level, message));
}

// Abstraction: anything that provides "now"
public interface ITimeProvider
{
    DateTime UtcNow { get; }
}

// Production: delegates to the real clock
public sealed class SystemTimeProvider : ITimeProvider
{
    public DateTime UtcNow => DateTime.UtcNow;
}

// Test: returns whatever time you set
public sealed class FakeClock : ITimeProvider
{
    public DateTime UtcNow { get; set; } = new(2025, 1, 15, 10, 30, 0);
}

// BEFORE (untestable — hardcoded DateTime.UtcNow):
// public void Log(LogLevel level, string msg)
//     => _inner.Log(level, $"[{DateTime.UtcNow:HH:mm:ss}] {msg}");

// AFTER (testable — injectable time):
public sealed class TimestampDecorator(
    ILogger inner,
    ITimeProvider clock) : ILogger
{
    public void Log(LogLevel level, string message)
    {
        var stamp = clock.UtcNow.ToString("yyyy-MM-dd HH:mm:ss");
        inner.Log(level, $"[{stamp}] {message}");
    }
}

[Fact]
public void Timestamp_decorator_prepends_formatted_time()
{
    // Arrange
    var sink = new TestSink();
    var clock = new FakeClock { UtcNow = new(2025, 3, 15, 14, 30, 0) };
    var logger = new Logger(LogLevel.Debug);
    logger.AddSink(sink);
    ILogger decorated = new TimestampDecorator(logger, clock);

    // Act
    decorated.Log(LogLevel.Info, "Hello");

    // Assert — exact, deterministic, no flakiness
    Assert.Single(sink.Entries);
    Assert.Equal("[2025-03-15 14:30:00] Hello", sink.Entries[0].Message);
}

[Fact]
public void Order_service_logs_error_on_payment_failure()
{
    // Arrange
    var sink = new TestSink();
    var logger = new Logger(LogLevel.Debug);
    logger.AddSink(sink);
    var service = new OrderService(logger);

    // Act
    var result = service.PlaceOrder(new Order { Id = 42 });

    // Assert — verify the service logged what we expected
    Assert.Contains(sink.Entries,
        e => e.Level == LogLevel.Error
          && e.Message.Contains("Order 42"));
}

[Fact]
public void Level_filter_suppresses_debug_messages()
{
    var sink = new TestSink();
    var logger = new Logger(LogLevel.Warning);  // only Warning+
    logger.AddSink(sink);

    logger.Log(LogLevel.Debug, "should be dropped");
    logger.Log(LogLevel.Warning, "should appear");

    Assert.Single(sink.Entries);
    Assert.Equal("should appear", sink.Entries[0].Message);
}

How a Test Flows

Growing Diagram — Level 6

Your inner voice:

"A Correlation ID is just a GUID that travels with the request. The API gateway generates it, attaches it to an HTTP header (like X-Correlation-Id), and every downstream service reads and propagates it. Every log entry includes this ID. When something goes wrong, I search for that one GUID and see the entire journey — across 5 services, 20 servers."

"For centralization, the ELK stack is the industry standard: Elasticsearch stores and indexes logs, Logstash ingests them, Kibana visualizes them. Our logger doesn't need to know about ELK — it just writes structured JSON. A lightweight agent (Filebeat) watches the log files and ships them to Elasticsearch."

Correlation ID — One ID, Many Services

The Solution

Two new pieces: a CorrelationIdDecorator that stamps every log entry with the request's unique ID, and a JsonSink that outputs machine-readable JSON for Elasticsearch.

// Stores the current request's correlation ID (per-thread / per-async-flow)
public static class CorrelationContext
{
    private static readonly AsyncLocal<string?> _id = new();
    public static string? CurrentId
    {
        get => _id.Value;
        set => _id.Value = value;
    }
}

// Decorator: prepends the correlation ID to every message
public sealed class CorrelationIdDecorator(ILogger inner) : ILogger
{
    public void Log(LogLevel level, string message)
    {
        var id = CorrelationContext.CurrentId ?? "no-corr-id";
        inner.Log(level, $"[{id}] {message}");
    }
}

// Middleware: reads or generates the ID for each request
public class CorrelationMiddleware(RequestDelegate next)
{
    public async Task InvokeAsync(HttpContext ctx)
    {
        var id = ctx.Request.Headers["X-Correlation-Id"]
                     .FirstOrDefault()
                 ?? Guid.NewGuid().ToString("N")[..12];

        CorrelationContext.CurrentId = id;
        ctx.Response.Headers["X-Correlation-Id"] = id;
        await next(ctx);
    }
}

public sealed class JsonSink : ILogSink
{
    private readonly StreamWriter _writer;

    public JsonSink(string path)
        => _writer = new StreamWriter(path, append: true);

    public void Write(LogLevel level, string message)
    {
        // Build a JSON object that Elasticsearch can index
        var json = JsonSerializer.Serialize(new
        {
            timestamp = DateTime.UtcNow.ToString("o"),
            level = level.ToString(),
            message,
            correlationId = CorrelationContext.CurrentId,
            machineName = Environment.MachineName,
            threadId = Environment.CurrentManagedThreadId
        });

        _writer.WriteLine(json);
        _writer.Flush();
    }
}

// Output example (one JSON object per line):
// {"timestamp":"2025-03-15T14:30:00Z","level":"Error",
//  "message":"Payment failed","correlationId":"abc123def456",
//  "machineName":"web-server-03","threadId":14}

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddSingleton<ITimeProvider, SystemTimeProvider>();
builder.Services.AddSingleton<ILogger>(sp =>
{
    var core = new Logger(LogLevel.Debug);
    core.AddSink(new ConsoleSink());
    core.AddSink(new RotatingFileSink("logs/app.log"));
    core.AddSink(new JsonSink("logs/app.json"));

    var clock = sp.GetRequiredService<ITimeProvider>();

    // Decorator chain: outermost runs first
    ILogger logger = core;
    logger = new CallerInfoDecorator(logger);
    logger = new ThreadIdDecorator(logger);
    logger = new TimestampDecorator(logger, clock);
    logger = new CorrelationIdDecorator(logger);
    logger = new RateLimitDecorator(logger);
    logger = new AsyncLoggerDecorator(logger);

    return logger;
});

var app = builder.Build();
app.UseMiddleware<CorrelationMiddleware>();
app.Run();

The ELK Stack — Centralized Log Search

The key insight: our logger doesn't need to know about Elasticsearch. It writes structured JSON to local files. Filebeat (a lightweight agent) watches those files and ships new lines to Logstash, which forwards them to Elasticsearch. Kibana provides the search UI. Our code stays simple; the infrastructure handles distribution.

Growing Diagram — Level 7 (Complete Architecture)

You built this logging framework one constraint at a time across eight levels. Now let's see every piece in one place. Each file is annotated with // Level N comments so you can trace which constraint forced each line into existence. Green types appeared early (Levels 0–2), yellow ones in the middle (Levels 3–5), and red ones in the advanced stages (6–7).

Now let's see the actual code. Each file is organized by responsibility — click through the tabs to read each one.

namespace Logging.Models;

// ─── LogLevel ────────────────────────────────────────  // Level 0
// Severity categories. The logger filters entries whose
// level is below the configured minimum.
public enum LogLevel { Trace, Debug, Info, Warning, Error, Fatal }

// ─── LogEntry ────────────────────────────────────────  // Level 1
// An immutable snapshot of one log event. Records give us
// value equality and a nice ToString() for free.
public record LogEntry(
    LogLevel Level,                                       // Level 0
    string Message,                                       // Level 0
    DateTimeOffset Timestamp,                             // Level 4
    string? Category = null,                              // Level 1
    string? ThreadId = null,                              // Level 4
    string? CallerInfo = null,                            // Level 4
    string? CorrelationId = null                          // Level 7
);

// ─── StructuredLogEntry ─────────────────────────────  // Level 7
// Extends LogEntry with key-value properties for machine-
// readable structured logging (JSON sinks love this).
public record StructuredLogEntry(
    LogLevel Level,
    string Message,
    DateTimeOffset Timestamp,
    Dictionary<string, object> Properties,                // Level 7
    string? Category = null,
    string? ThreadId = null,
    string? CallerInfo = null,
    string? CorrelationId = null
) : LogEntry(Level, Message, Timestamp, Category, ThreadId, CallerInfo, CorrelationId);

namespace Logging.Sinks;

// ─── ILogSink ────────────────────────────────────────  // Level 1
// The Strategy interface. Every destination implements
// this single method. The logger doesn't know or care
// whether it's writing to the console, a file, or a DB.
public interface ILogSink : IDisposable                   // Level 6
{
    void Write(LogEntry entry);                           // Level 1
}

// ─── ConsoleSink ─────────────────────────────────────  // Level 1
public sealed class ConsoleSink : ILogSink
{
    public void Write(LogEntry entry)
    {
        var color = entry.Level switch                    // Level 2
        {
            LogLevel.Error or LogLevel.Fatal => ConsoleColor.Red,
            LogLevel.Warning => ConsoleColor.Yellow,
            LogLevel.Info => ConsoleColor.Green,
            _ => ConsoleColor.Gray
        };
        var prev = Console.ForegroundColor;
        Console.ForegroundColor = color;
        Console.WriteLine($"[{entry.Level}] {entry.Message}");
        Console.ForegroundColor = prev;
    }
    public void Dispose() { /* nothing to release */ }
}

// ─── FileSink ────────────────────────────────────────  // Level 3
public sealed class FileSink : ILogSink
{
    private readonly StreamWriter _writer;
    private readonly object _lock = new();                // Level 5

    public FileSink(string path)
    {
        _writer = new StreamWriter(path, append: true)
            { AutoFlush = true };
    }
    public void Write(LogEntry entry)
    {
        lock (_lock)                                      // Level 5
        {
            _writer.WriteLine(
                $"{entry.Timestamp:O} [{entry.Level}] {entry.Message}");
        }
    }
    public void Dispose() => _writer.Dispose();          // Level 6
}

// ─── DbSink ─────────────────────────────────────────  // Level 3
public sealed class DbSink : ILogSink
{
    private readonly string _connectionString;

    public DbSink(string connectionString)
        => _connectionString = connectionString;

    public void Write(LogEntry entry)
    {
        // In production: INSERT INTO Logs (Level, Message, Timestamp...)
        // Simplified here for clarity.
        Console.WriteLine($"[DB] Persisted: {entry.Level} - {entry.Message}");
    }
    public void Dispose() { /* close DB connection */ }
}

// ─── FileRotationSink ────────────────────────────────  // Level 6
// Wraps file writing with automatic rotation when the
// file exceeds a size threshold.
public sealed class FileRotationSink : ILogSink
{
    private readonly string _basePath;
    private readonly long _maxBytes;
    private StreamWriter _writer;
    private long _bytesWritten;
    private int _fileIndex;
    private readonly object _lock = new();

    public FileRotationSink(string basePath, long maxBytes = 10_000_000)
    {
        _basePath = basePath;
        _maxBytes = maxBytes;
        _writer = OpenNewFile();
    }
    public void Write(LogEntry entry)
    {
        var line = $"{entry.Timestamp:O} [{entry.Level}] {entry.Message}";
        lock (_lock)
        {
            if (_bytesWritten + line.Length > _maxBytes)
                Rotate();
            _writer.WriteLine(line);
            _bytesWritten += line.Length + Environment.NewLine.Length;
        }
    }
    private void Rotate()
    {
        _writer.Dispose();
        _fileIndex++;
        _writer = OpenNewFile();
        _bytesWritten = 0;
    }
    private StreamWriter OpenNewFile()
        => new(Path.ChangeExtension(_basePath,
               $".{_fileIndex}.log"), append: false)
            { AutoFlush = true };

    public void Dispose() => _writer.Dispose();
}

// ─── TestSink ────────────────────────────────────────  // Level 6
// Captures entries in memory so unit tests can assert on them.
public sealed class TestSink : ILogSink
{
    public List<LogEntry> Entries { get; } = new();
    public void Write(LogEntry entry) => Entries.Add(entry);
    public void Dispose() => Entries.Clear();
}

namespace Logging.Decorators;

// ─── TimestampDecorator ─────────────────────────────  // Level 4
// Wraps any ILogSink and stamps the current UTC time
// onto the entry before passing it along.
public sealed class TimestampDecorator : ILogSink
{
    private readonly ILogSink _inner;
    public TimestampDecorator(ILogSink inner) => _inner = inner;

    public void Write(LogEntry entry)
    {
        var stamped = entry with
            { Timestamp = DateTimeOffset.UtcNow };        // Level 4
        _inner.Write(stamped);
    }
    public void Dispose() => _inner.Dispose();
}

// ─── ThreadIdDecorator ──────────────────────────────  // Level 4
public sealed class ThreadIdDecorator : ILogSink
{
    private readonly ILogSink _inner;
    public ThreadIdDecorator(ILogSink inner) => _inner = inner;

    public void Write(LogEntry entry)
    {
        var tagged = entry with
            { ThreadId = Environment.CurrentManagedThreadId.ToString() };
        _inner.Write(tagged);
    }
    public void Dispose() => _inner.Dispose();
}

// ─── CallerInfoDecorator ────────────────────────────  // Level 4
public sealed class CallerInfoDecorator : ILogSink
{
    private readonly ILogSink _inner;
    public CallerInfoDecorator(ILogSink inner) => _inner = inner;

    public void Write(LogEntry entry)
    {
        var enriched = entry with
            { CallerInfo = GetCaller() };
        _inner.Write(enriched);
    }
    private static string GetCaller()
    {
        var frame = new System.Diagnostics.StackTrace(skipFrames: 3)
            .GetFrame(0);
        return frame?.GetMethod()?.DeclaringType?.Name ?? "Unknown";
    }
    public void Dispose() => _inner.Dispose();
}

// ─── CorrelationDecorator ───────────────────────────  // Level 7
// Tags every entry with a correlation ID so you can trace
// a single request across multiple log lines.
public sealed class CorrelationDecorator : ILogSink
{
    private readonly ILogSink _inner;
    private static readonly AsyncLocal<string?> _correlationId = new();

    public static string? CurrentCorrelationId
    {
        get => _correlationId.Value;
        set => _correlationId.Value = value;
    }
    public CorrelationDecorator(ILogSink inner) => _inner = inner;

    public void Write(LogEntry entry)
    {
        var tagged = entry with
            { CorrelationId = _correlationId.Value ?? Guid.NewGuid().ToString("N")[..8] };
        _inner.Write(tagged);
    }
    public void Dispose() => _inner.Dispose();
}

// ─── AsyncDecorator ─────────────────────────────────  // Level 6
// Offloads writing to a background thread so the caller
// never blocks on slow sinks (file I/O, DB, network).
public sealed class AsyncDecorator : ILogSink
{
    private readonly ILogSink _inner;
    private readonly Channel<LogEntry> _channel;
    private readonly Task _consumer;

    public AsyncDecorator(ILogSink inner, int capacity = 1024)
    {
        _inner = inner;
        _channel = Channel.CreateBounded<LogEntry>(capacity);
        _consumer = Task.Run(ConsumeAsync);
    }
    public void Write(LogEntry entry)
    {
        if (!_channel.Writer.TryWrite(entry))
            _inner.Write(entry); // back-pressure: write synchronously
    }
    private async Task ConsumeAsync()
    {
        await foreach (var entry in _channel.Reader.ReadAllAsync())
            _inner.Write(entry);
    }
    public void Dispose()
    {
        _channel.Writer.Complete();
        _consumer.GetAwaiter().GetResult();
        _inner.Dispose();
    }
}

namespace Logging;

// ─── Logger ─────────────────────────────────────────  // Level 0
// The single entry point for all logging. Registered as
// a DI singleton (Level 5) so every service shares the
// same configured pipeline.
public sealed class Logger : IDisposable                  // Level 6
{
    private readonly IReadOnlyList<ILogSink> _sinks;     // Level 1
    private readonly LogLevel _minimumLevel;              // Level 2
    private readonly object _lock = new();                // Level 5

    public Logger(
        IEnumerable<ILogSink> sinks,                     // Level 1
        LogLevel minimumLevel = LogLevel.Info)            // Level 2
    {
        _sinks = sinks.ToList().AsReadOnly();
        _minimumLevel = minimumLevel;
    }

    // ─── Convenience methods ─────────────────────────
    public void Trace(string msg)   => Log(LogLevel.Trace, msg);
    public void Debug(string msg)   => Log(LogLevel.Debug, msg);
    public void Info(string msg)    => Log(LogLevel.Info, msg);
    public void Warning(string msg) => Log(LogLevel.Warning, msg);
    public void Error(string msg)   => Log(LogLevel.Error, msg);
    public void Fatal(string msg)   => Log(LogLevel.Fatal, msg);

    public void Log(LogLevel level, string message)       // Level 0
    {
        if (level < _minimumLevel) return;                // Level 2

        var entry = new LogEntry(level, message,
            DateTimeOffset.UtcNow);                       // Level 4

        lock (_lock)                                      // Level 5
        {
            foreach (var sink in _sinks)                  // Level 1
            {
                try
                {
                    sink.Write(entry);                    // Level 1
                }
                catch (Exception ex)                      // Level 5
                {
                    Console.Error.WriteLine(
                        $"Sink {sink.GetType().Name} failed: {ex.Message}");
                }
            }
        }
    }

    public void Dispose()                                 // Level 6
    {
        foreach (var sink in _sinks)
            sink.Dispose();
    }
}

using Logging;
using Logging.Sinks;
using Logging.Decorators;

// ─── DI Registration ────────────────────────────────  // Level 5
var builder = WebApplication.CreateBuilder(args);

// Build decorated sink pipelines:
// Console: timestamp + threadId + console output
ILogSink consolePipeline = new ConsoleSink();             // Level 1
consolePipeline = new TimestampDecorator(consolePipeline); // Level 4
consolePipeline = new ThreadIdDecorator(consolePipeline); // Level 4

// File: timestamp + caller + async + rotating file
ILogSink filePipeline = new FileRotationSink("logs/app.log"); // Level 6
filePipeline = new CallerInfoDecorator(filePipeline);     // Level 4
filePipeline = new TimestampDecorator(filePipeline);      // Level 4
filePipeline = new AsyncDecorator(filePipeline);          // Level 6

// Register Logger as singleton with both pipelines
builder.Services.AddSingleton(                            // Level 5
    new Logger(
        new[] { consolePipeline, filePipeline },
        LogLevel.Debug));

var app = builder.Build();

// ─── Usage ──────────────────────────────────────────
var logger = app.Services.GetRequiredService<Logger>();

logger.Info("Application started");                       // Level 0
logger.Debug("Loading configuration...");                 // Level 2
logger.Warning("Cache miss on user profile");             // Level 2
logger.Error("Payment gateway timeout after 30s");        // Level 5

// Correlation ID for request tracing                     // Level 7
CorrelationDecorator.CurrentCorrelationId = Guid.NewGuid().ToString("N")[..8];
logger.Info("Processing order #12345");
logger.Info("Charging payment method");
logger.Info("Order confirmed");

logger.Dispose();                                         // Level 6

You've been using design patterns for the last eight levels. Some were obvious — we named them as we built them. Others are hiding in the code, doing their job without anyone labeling them. This section is about developing pattern recognitionThe ability to look at code and see the underlying design patterns at work. Senior engineers do this unconsciously — they glance at a Logger class and immediately see "that's a Strategy for sinks, Decorator for enrichment, Singleton for sharing." This skill comes from building patterns yourself. — the skill of seeing structural bones underneath working code.

The Three Explicit Patterns

These are the patterns we named during the build. For each one: where it lives, what it enables, and what breaks without it.

Pattern X-Ray — See Through the Code

Here's the class diagram with colored overlays showing which pattern each type belongs to. Yellow is Strategy, purple is Decorator, cyan is Singleton. Notice how Decorator wraps Strategy — every decorator is also an ILogSink, which is what makes the stacking work.

How the Patterns Interact

Patterns don't live in isolation. Here's what happens when your code calls logger.Error("Payment failed"). The Singleton ensures there's one Logger. The Logger iterates its sinks (Chain). Each sink might be wrapped in Decorators that enrich the entry. Finally, the concrete Strategy sink writes to its destination.

You built this logging framework across eight levels. At Level 0 it was a single class that printed to the console. By Level 7, it's a composable pipeline with decorators, async offloading, file rotation, and correlation tracking. But it didn't happen all at once — it grew one constraint at a time.

Each stage below shows what was added at that level. Glowing boxes are new arrivals; the growth curveThe growth curve shows how many types exist at each level. A healthy design grows gradually — 1–3 new types per level. An unhealthy design dumps 10 types in Level 0 because someone tried to anticipate every future need. stays gentle because we never added more than one concept at a time.

Here's the complete picture — every entity, its type, and the level that introduced it.

You've seen the good solution — built incrementally over 8 levels. Now let's study five bad approaches that people commonly reach for when building logging frameworks. Each one is tempting for a different reason, and each one breaks in a predictable way.

public class GodLogger
{
    private StreamWriter? _fileWriter;
    private string? _dbConnection;
    private LogLevel _minLevel = LogLevel.Info;

    public void Log(LogLevel level, string msg)
    {
        if (level < _minLevel) return;
        var ts = DateTime.Now.ToString("O");        // bug: local time
        var tid = Thread.CurrentThread.ManagedThreadId;
        var line = $"{ts} [{tid}] [{level}] {msg}";

        // Console — inline formatting
        Console.ForegroundColor = level >= LogLevel.Error
            ? ConsoleColor.Red : ConsoleColor.Gray;
        Console.WriteLine(line);
        Console.ResetColor();

        // File — inline with rotation
        if (_fileWriter != null)
        {
            _fileWriter.WriteLine(line);
            if (_fileWriter.BaseStream.Length > 10_000_000)
            {
                _fileWriter.Close();
                // ... 30 lines of rotation logic ...
            }
        }

        // DB — inline insert
        if (_dbConnection != null)
        {
            // ... 20 lines of SQL insert ...
        }
    }
}

// Logger: ONLY orchestration
public sealed class Logger(IEnumerable<ILogSink> sinks, LogLevel min)
{
    public void Log(LogLevel level, string msg)
    {
        if (level < min) return;
        var entry = new LogEntry(level, msg, DateTimeOffset.UtcNow);
        foreach (var sink in sinks) sink.Write(entry);
    }
}
// Each sink: ONE destination, ONE responsibility
public interface ILogSink { void Write(LogEntry entry); }

public interface ILogProvider { ILogSinkFactory GetFactory(); }
public interface ILogSinkFactory { ILogSink Create(string name); }
public abstract class AbstractSinkProvider : ILogProvider { ... }
public interface ILogMediator { void Route(LogEntry entry); }
public class LoggingPipeline : ILogMediator
{
    private readonly ILogProvider _provider;
    private readonly ILogSinkFactory _factory;
    // 4 layers of indirection just to call Write()
}

// One interface. Implement it. Done.
public interface ILogSink { void Write(LogEntry entry); }

// Need enrichment? Decorator. Need async? Decorator.
// Need multiple destinations? List<ILogSink>.
// No factories, no mediators, no abstract providers.

public sealed class Logger
{
    private readonly List<ILogSink> _sinks;

    public void Log(LogLevel level, string msg)
    {
        var entry = new LogEntry(level, msg, DateTimeOffset.UtcNow);
        foreach (var sink in _sinks)
            sink.Write(entry);  // no try/catch — one failure kills all
    }
    // no Dispose — StreamWriters leak forever
}

public sealed class FileSink : ILogSink
{
    private readonly StreamWriter _writer;
    public void Write(LogEntry entry)
    {
        // no lock — concurrent threads corrupt the file
        _writer.WriteLine($"[{entry.Level}] {entry.Message}");
    }
}

public sealed class Logger : IDisposable   // IDisposable!
{
    private readonly object _lock = new();

    public void Log(LogLevel level, string msg)
    {
        var entry = new LogEntry(level, msg, DateTimeOffset.UtcNow);
        lock (_lock)
        {
            foreach (var sink in _sinks)
            {
                try { sink.Write(entry); }
                catch (Exception ex)      // isolate failures
                {
                    Console.Error.WriteLine(
                        $"Sink failed: {ex.Message}");
                }
            }
        }
    }
    public void Dispose()
    {
        foreach (var s in _sinks) s.Dispose(); // clean up!
    }
}

public static class Logger
{
    private static readonly List<ILogSink> _sinks = new();
    public static void Configure(params ILogSink[] sinks)
        => _sinks.AddRange(sinks);
    public static void Log(LogLevel level, string msg)
    {
        foreach (var sink in _sinks) sink.Write(...);
    }
}
// In unit tests:
Logger.Configure(new TestSink()); // PROBLEM:
// this TestSink persists across ALL tests!
// Test A's logs leak into Test B's assertions.

// Register as DI singleton — same instance, but swappable
builder.Services.AddSingleton(
    new Logger(new[] { consoleSink, fileSink }, LogLevel.Debug));

// In unit tests: create a fresh Logger per test
var testSink = new TestSink();
var logger = new Logger(new[] { testSink }, LogLevel.Trace);
// No leakage. No global state. Full control.

public class Logger
{
    public void Log(LogLevel level, string msg)
    {
        // Format ONCE, pass string to all sinks
        var line = $"{DateTime.Now:O} [{level}] {msg}";
        foreach (var sink in _sinks)
            sink.Write(line);   // sink gets a flat string
    }
}
// DbSink now has to PARSE the string to extract level:
public class DbSink
{
    public void Write(string line)
    {
        // Regex to extract level from "[Info]"?!
        var match = Regex.Match(line, @"\[(.*?)\]");
        // Fragile, slow, and breaks if format changes
    }
}

// Pass a typed record — each sink formats as needed
public record LogEntry(LogLevel Level, string Message,
    DateTimeOffset Timestamp);

public class DbSink : ILogSink
{
    public void Write(LogEntry entry)
    {
        // Direct access to typed fields — no parsing!
        cmd.Parameters.Add("@level", entry.Level.ToString());
        cmd.Parameters.Add("@msg", entry.Message);
        cmd.Parameters.Add("@ts", entry.Timestamp);
    }
}

A candidate submitted this logging framework as a pull request. It compiles. It runs. It handles basic console and file logging. But there are exactly 5 bugs hiding in it — issues that would cause real problems in production. Some are obvious if you know what to look for. Others are the kind of subtle mistakes that slip past junior reviewers and only surface at 3 AM when the on-call engineer is debugging a production outage.

This is how real code reviews work: the code looks fine at first glance. The bugs aren't syntax errors — they're design mistakes that only matter under load, across timezones, or during shutdown. Can you find them all before scrolling down?

Read the code below carefully. Try to find all 5 issues before revealing the answers.

public class Logger                                              // Line 1
{
    private readonly List<ILogSink> _sinks;
    private readonly LogLevel _minLevel;

    public Logger(List<ILogSink> sinks, LogLevel minLevel)       // Line 6
    {
        _sinks = sinks;
        _minLevel = minLevel;
    }

    public void Log(LogLevel level, string message)              // Line 12
    {
        if (level < _minLevel) return;
        var entry = new LogEntry(level, message,
            DateTime.Now);                                       // Line 16

        foreach (var sink in _sinks)                             // Line 18
            sink.Write(entry);
    }
}

public class FileSink : ILogSink                                 // Line 23
{
    private readonly StreamWriter _writer;

    public FileSink(string path)
    {
        _writer = new StreamWriter(path, append: true);
    }

    public void Write(LogEntry entry)                            // Line 31
    {
        _writer.WriteLine(
            "[" + entry.Level + "] " + entry.Timestamp + " " +  // Line 34
            entry.Message);
    }
}

public static class LogManager                                   // Line 39
{
    public static Logger Instance { get; private set; } = null!;

    public static void Initialize(List<ILogSink> sinks)
    {
        Instance = new Logger(sinks, LogLevel.Info);
    }
}

Bug Severity Overview

Not all bugs are created equal. The chart below ranks the 5 issues by severity and category. Thread safety and resource leaks are the hardest to catch because they don't show up in simple testing — they only surface under load or during shutdown. That's why they're the highest-severity bugs in the list.

Found them? Reveal one at a time:

Score Yourself

A logging framework sounds boring until the interviewer asks "how do you add a new sink without touching existing code?" or "how does correlation work across async calls?" Suddenly it's a design patterns showcaseLogging naturally uses Strategy (sinks), Decorator (enrichment), and Singleton (shared logger instance) — three patterns in one system. That's why interviewers love this question.. Below you'll see two complete runs of the same 30-minute interview: the polished one where everything flows smoothly, and the realistic one with stumbles, pauses, and recovery. Both get hired. The difference is recovery speed, not perfection.

Pay attention to the "Interviewer Thinks" column — it reveals the hidden scoring that candidates never see. Every green comment is a mental checkbox. Every yellow comment is a "let's see if they recover" moment. Understanding what interviewers are silently tracking is the single biggest advantage you can have.

What Interviewers Actually Score

Most candidates think interviewers score on "did you use the right pattern?" Wrong. They score on five dimensions, and only one of them is about patterns. The others are about extensibility, thread safety, modern practices, and real-world awareness. Miss any two and you're below "Hire" even if your code compiles perfectly.

The CREATES Timeline — 30 Minutes, 7 Phases

Every logging framework interview follows the same arc, whether you're doing the clean run or the realistic one. The CREATES frameworkCREATES stands for Clarify, Requirements, Entities, API/Architecture, Trade-offs, Edge cases, Scale. It's a systematic way to structure your answer so you never forget a phase. gives you a roadmap so you never blank on "what should I talk about next?" Spend roughly 60% of your time on entities and code (the middle phases), and 40% on everything else.

Scoring Rubric — How Interviewers Grade Each Phase

This is the rubric interviewers use (often on a shared doc). Each phase has a clear "Strong Hire" signal and a "No Hire" signal. The gap between them is usually one thing: reasoning. The candidate who explains why they chose an interface over a switch will always outscore the one who just writes an interface without explanation.

Scoring Summary — Both Runs

Both candidates scored "Strong Hire" despite very different paths. The Clean Run hit every phase on time. The Realistic Run stumbled twice, got nudged once, but recovered every time. The key insight: interviewers don't grade on polish — they grade on thinking. A stumble you recover from is often more impressive than a flawless run, because it proves you can handle ambiguity on a real team.

Common Follow-Up Questions

After the main 30-minute walkthrough, interviewers often have 5-10 minutes left for follow-ups. These questions test depth — they're not asking you to redesign, they're asking you to extend your existing design under new constraints. If your architecture is truly extensible, every answer should start with "add a new class" rather than "change existing code."

Design skill and communication skill are separate muscles. You can have a brilliant logging framework in your head and still tank the interview because you can't narrate it under pressure. The 8 cards below cover the exact moments where phrasing decides whether the interviewer hears "this person gets it" or "this person memorized a pattern catalog." Each card gives you four things: the Situation (when you'd use this phrase), the Say (what to actually say), the Don't Say (the common mistake), and the Why (the psychology behind why one works and the other doesn't).

The golden rule is simple: problem first, pattern name second. Interviewers can tell in one sentence whether you understand a pattern or merely memorized its name. When you say "sinks vary independently — that's Strategy," the interviewer hears reasoning. When you say "I'll use Strategy because it's standard," they hear a textbook.

Say vs Don't Say — Side by Side

Here's the cheat sheet. The left column sounds like someone who has built logging systems. The right column sounds like someone who has read about logging systems. The difference is always the same: the good version names a concrete problem before naming a pattern.

8 Moments That Decide the Interview

Each card below targets a specific interview moment. The "Say" phrasing has been tested across dozens of mock interviews — it consistently triggers positive reactions from interviewers because it leads with the problem, names the pattern only after motivation, and acknowledges trade-offs.

The 5 Most Common Phrasing Mistakes

These aren't hypothetical — they're the exact phrases that cost real candidates points in real interviews. Each one sounds fine in your head but triggers a negative reaction from the interviewer. The fix is always the same: say the problem before the pattern.

Quick Reference — The 3 Sentences to Memorize

If you're short on prep time, memorize these three sentences. They cover the three most-asked design points in a logging framework interview. Each one follows the articulation order: problem → pattern → trade-off.

Confidence Curve — Why Practice Matters

Most candidates know these concepts in their heads but stumble when they have to say them out loud under time pressure. The chart below shows the typical confidence curve: reading builds recognition, but only speaking builds production fluency. The gap between "I know this" and "I can say this clearly in 10 seconds" is bigger than you think.

12 questions ranked by difficulty. Each has a "Think" prompt, a solid answer, and the great answer that earns "Strong Hire." These aren't hypothetical — they're the exact questions interviewers ask when they see a logging framework design.

Every one of these has ended real interviews. Logging sounds simple, so candidates lower their guard — and that's exactly when these mistakes strike. They're organized by severity: fatal mistakes that end the interview immediately, serious ones that drop you from "Hire" to "Lean No," and minor ones that won't fail you but won't let you shine either.

● Fatal Mistakes — Interview Enders

● Serious Mistakes — Significant Red Flags

● Minor Mistakes — Missed Opportunities

You just built a production-ready logging framework that uses three design patterns working together. Now let's lock those patterns into long-term memory so they come back instantly in your next interview or design session. The trick isn't rote repetition — it's anchoring each concept to something vivid.

Memory Palace — Walk Through a Server Room

Imagine walking into a server room with three stations. Each station represents one of the three core patterns. As you walk through, the pattern clicks into place.

Pattern Decision Tree — Which Pattern Do I Need?

When you're staring at a logging requirement, ask these questions in order. Each answer points you to the right pattern.

Smell → Pattern Quick Reference

Flashcards — Quiz Yourself

Click each card to reveal the answer. If you can answer without peeking, the pattern is sticking.

You didn't just learn how to build a logger. You learned seven structural thinking moves that appear in virtually every system that processes data. The three core patterns — "ensure one shared resource" (Singleton), "layer optional behavior" (Decorator), and "swap algorithms at runtime" (Strategy) — are joined by four supporting techniques: thread safety, structured data modeling, pipeline architecture, and error isolation. Below is the proof: the exact same techniques, applied to four completely different domains.

The point of this section is to convince you that learning one system well is worth more than skimming ten systems. If you can explain why Singleton works for a logger, you can explain why it works for a metrics collector, an audit service, or a cache manager. The structural problem is the same — only the domain vocabulary changes.

Transfer Matrix — 7 Techniques Across 4 Systems

Each row is a technique you learned in the logging framework. Each column is a different system. Read across a row to see how the same structural move applies to monitoring, auditing, and error tracking. Read down a column to see how one system uses multiple techniques together.

Transfer Web — One Framework, Many Domains

Think of the Logging Framework as the center of a web. Every pattern you learned radiates outward into entirely different systems. The domain changes, but the structural move stays the same. The lines are dashed because the connection isn't copy-paste — it's structural analogy. You don't take Logger code and paste it into a monitoring system. You take the thinking (Singleton for shared resource, Decorator for layering, Strategy for swapping) and apply it fresh.

Technique Heat Map — Which Technique Appears Where?

The darker the cell, the more critical that technique is to that domain. Notice how Decorator shows up as CRITICAL in almost every row — that's because layering optional behavior is the single most reusable pattern in infrastructure code. Also notice that thread safety is HIGH or CRITICAL everywhere — because infrastructure systems are almost always multi-tenantServing multiple users, threads, or requests concurrently. Any shared resource (logger, cache, config) must handle concurrent access safely. This is why thread safety shows up as critical in virtually every infrastructure domain..

How to Apply This in Your Next Design

When you sit down with a new system design problem — whether it's a caching layer, a notification service, or a payment gateway — run through the transfer matrix mentally. Ask yourself: "Does this system have a shared resource?" (Singleton). "Does it layer optional behavior?" (Decorator). "Does it have swappable implementations?" (Strategy). "Is it multi-threaded?" (Thread Safety). "Does data flow through stages?" (Pipeline). You'll find that most infrastructure systems match 4-5 of these seven rows. The domain vocabulary changes, but the structural problems are the same ones you just solved in logging.

Six thinking tools you picked up in this case study. Each one is a portable mental move — not a logging trick, but something you can use in any LLD interview or real-world design. Think of them as questions you ask yourself whenever you sit down to design a system. If you remember nothing else from this page, remember these six questions — they work for payment systems, caching layers, notification services, and anything else that processes data through a pipeline.

The trick isn't knowing the pattern name. It's knowing when to reach for it. Each card below gives you the trigger question (the moment you'd think of this tool), a plain English explanation of how to use it in any context, and the specific logging example where you saw it in action on this page.

Your 6-Tool Mental Toolkit

Deep Dive — Each Tool Explained

Self-Check — Can You Use Each Tool?

Before you leave this page, run through this checklist. Each item maps to one tool above. If you can answer "yes" to all six, you've internalized the thinking moves — not just the pattern names.

Decision Flowchart — Which Tool Do I Reach For?

When you're in the middle of a design and a new requirement appears, use this flowchart to pick the right tool. Start at the top with the requirement, follow the questions, and land on the tool. Most requirements map to exactly one tool. Some (like "add a new enricher") combine two (Decorator + OCP).

When NOT to Use Each Tool

Knowing when to use a tool is important. Knowing when not to use it is just as important. Over-applying patterns is the second most common mistake in LLD interviews (after under-applying them). Each tool has a specific trigger — use it only when that trigger fires.

Three exercises that test whether you truly learned the thinking, not just memorized the code. Each one adds a new constraint that forces you to extend the logging framework — exactly like a real interview follow-up question.

public class JsonFormatterDecorator : ILogger
{
    private readonly ILogger _inner;
    private readonly string _source;

    public JsonFormatterDecorator(ILogger inner, string source)
    {
        _inner = inner;
        _source = source;
    }

    public void Log(LogLevel level, string message)
    {
        var entry = new
        {
            timestamp = DateTime.UtcNow.ToString("o"),
            level = level.ToString(),
            message,
            source = _source
        };

        string json = JsonSerializer.Serialize(entry);
        _inner.Log(level, json);
    }
}

// Usage:
ILogger logger = new ConsoleLogger();
logger = new JsonFormatterDecorator(logger, "OrderService");
logger.Log(LogLevel.Info, "Order placed");
// Output: {"timestamp":"2026-03-15T...","level":"Info",
//          "message":"Order placed","source":"OrderService"}

public class RotatingFileDecorator : ILogSink, IDisposable
{
    private readonly string _basePath;
    private readonly long _maxBytes;
    private readonly int _maxArchives;
    private readonly object _lock = new();
    private StreamWriter _writer;

    public RotatingFileDecorator(
        string basePath,
        long maxBytes = 10 * 1024 * 1024,
        int maxArchives = 5)
    {
        _basePath = basePath;
        _maxBytes = maxBytes;
        _maxArchives = maxArchives;
        _writer = new StreamWriter(basePath, append: true);
    }

    public void Write(string entry)
    {
        lock (_lock)
        {
            if (new FileInfo(_basePath).Length >= _maxBytes)
                Rotate();

            _writer.WriteLine(entry);
            _writer.Flush();
        }
    }

    private void Rotate()
    {
        _writer.Close();

        // Compress old file
        string archive = $"{_basePath}.{DateTime.Now:yyyyMMddHHmmss}.gz";
        using (var input = File.OpenRead(_basePath))
        using (var output = File.Create(archive))
        using (var gz = new GZipStream(output, CompressionLevel.Optimal))
            input.CopyTo(gz);

        File.Delete(_basePath);

        // Prune old archives
        var archives = Directory.GetFiles(
                Path.GetDirectoryName(_basePath)!, "*.gz")
            .OrderByDescending(f => f)
            .Skip(_maxArchives);
        foreach (var old in archives)
            File.Delete(old);

        _writer = new StreamWriter(_basePath, append: false);
    }

    public void Dispose() => _writer?.Dispose();
}

// 1. Correlation context (shared across async calls)
public static class CorrelationContext
{
    private static readonly AsyncLocal<string?> _id = new();
    public static string? CurrentId
    {
        get => _id.Value;
        set => _id.Value = value;
    }
}

// 2. Decorator that enriches every log entry
public class CorrelationDecorator : ILogger
{
    private readonly ILogger _inner;
    public CorrelationDecorator(ILogger inner) => _inner = inner;

    public void Log(LogLevel level, string message)
    {
        var id = CorrelationContext.CurrentId ?? "no-correlation";
        _inner.Log(level, $"[{id}] {message}");
    }
}

// 3. ASP.NET middleware to propagate the ID
public class CorrelationMiddleware(RequestDelegate next)
{
    public async Task InvokeAsync(HttpContext ctx)
    {
        CorrelationContext.CurrentId =
            ctx.Request.Headers["X-Correlation-Id"]
                .FirstOrDefault()
            ?? Guid.NewGuid().ToString("N");

        ctx.Response.Headers["X-Correlation-Id"] =
            CorrelationContext.CurrentId;

        await next(ctx);
    }
}

// 4. HttpClient handler to forward the ID downstream
public class CorrelationHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage req, CancellationToken ct)
    {
        if (CorrelationContext.CurrentId is { } id)
            req.Headers.Add("X-Correlation-Id", id);
        return base.SendAsync(req, ct);
    }
}

You've used three design patterns and two SOLID principles to build a production-ready logging framework. Here's where to go next — each page below deepens a specific skill you've already started building.