Microservices III — Patterns in Practice

Chapter 9 and Chapter 10 built the architecture: services that own their data, talk over the network, and stay consistent through events. This chapter is the pattern catalogue for actually surviving in that world — the five architectural patterns every microservices system reaches for (API Gateway, Circuit Breaker, Saga, CQRS, Sidecar), the two ways to coordinate a saga, the idempotency and dead-letter machinery that makes any of it safe under retries, and finally the ordinary GoF design patterns that live inside a single service.

The trade you made

Every pattern in this chapter exists to pay off one debt. When you moved from a monolith to a distributed system, you exchanged function calls for network calls — and a network call is not a slower function call. It is a different kind of thing, with three failure modes a method call simply does not have.

The five MSA architectural patterns

These five are the canonical set. The first two are about how requests flow, the middle two about how data behaves, and the last about where cross-cutting concerns live.

1. API Gateway

The gateway is the single entry point for every client. It routes each request to the right downstream service, handles authentication once instead of five times, and often aggregates several service responses into the one payload a mobile screen actually needs.

The full treatment — the client-to-microservice problem it solves, the benefits and drawbacks, and how it relates to service discovery — is in Chapter 9. What the new slides add is the shape of the code, so here it is in C#. This is the minimal "dumb proxy" half:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpClient();
var app = builder.Build();

// The routing table: public prefix -> internal service base address.
var services = new Dictionary<string, string>
{
    ["order"]     = "http://order-service:8080",
    ["inventory"] = "http://inventory-service:8080"
};

app.MapGet("/proxy/{serviceName}/{*path}", async (
    string serviceName, string path,
    HttpRequest request, IHttpClientFactory factory) =>
{
    if (!services.TryGetValue(serviceName, out var baseUrl))
        return Results.NotFound($"Unknown service '{serviceName}'.");

    var target = $"{baseUrl}/{path}{request.QueryString}";

    var client = factory.CreateClient();
    client.Timeout = TimeSpan.FromSeconds(3);   // never inherit the 100s default here

    var response = await client.GetAsync(target);
    var body = await response.Content.ReadAsStringAsync();

    return Results.Content(body, "application/json", statusCode: (int)response.StatusCode);
});

app.Run();

The interesting half is aggregation — the part that actually earns the gateway its keep, because it turns a mobile client's three round trips over a slow radio link into one:

app.MapGet("/api/order-screen/{orderId}", async (string orderId, IHttpClientFactory factory) =>
{
    var client = factory.CreateClient();

    // Bound the WHOLE aggregation with one budget for the screen. Without this,
    // the gateway will sit waiting on a dead dependency until HttpClient's
    // 100-second default gives up — long after the user has left.
    using var budget = new CancellationTokenSource(TimeSpan.FromSeconds(2));
    var ct = budget.Token;

    // Fan out in parallel — sequential awaits would add up the latencies.
    var orderTask    = client.GetFromJsonAsync<OrderDto>($"http://order-service:8080/orders/{orderId}", ct);
    var shippingTask = client.GetFromJsonAsync<ShippingDto>($"http://shipping-service:8080/by-order/{orderId}", ct);
    var reviewsTask  = client.GetFromJsonAsync<ReviewDto[]>($"http://review-service:8080/by-order/{orderId}", ct);

    await Task.WhenAll(orderTask, shippingTask, reviewsTask);

    return Results.Ok(new OrderScreenDto(
        Order:    await orderTask,
        Shipping: await shippingTask,
        Reviews:  await reviewsTask));
});

2. Circuit Breaker

If Service A calls Service B and B is down, A should stop trying. Every doomed call ties up a connection, a thread-pool slot and a caller who is now waiting — and when A's resources run out, A fails too, and whoever calls A fails next. That is cascading failure, and the circuit breaker exists to stop it at the first hop.

Chapter 9 has the state diagram, a full C# implementation and an interactive simulator — work through those if the three states aren't yet automatic. What is worth adding here is a critique, because the version on the slides is a good example of how this pattern gets subtly wrong.

public static class CircuitBreaker
{
    public static int  Failures  = 0;     // shared by EVERY caller
    public static int  Threshold = 5;
    public static bool IsOpen    = false; // once true, true forever
}

async Task<string> CallExternalServiceAsync(HttpClient client)
{
    if (CircuitBreaker.IsOpen)
        throw new HttpRequestException("Service temporarily unavailable (503)");

    try
    {
        return await client.GetStringAsync("http://unstable-service/api");
    }
    catch (Exception)
    {
        CircuitBreaker.Failures++;
        if (CircuitBreaker.Failures >= CircuitBreaker.Threshold)
            CircuitBreaker.IsOpen = true;
        throw;
    }
}

// One policy pipeline PER dependency, registered on that dependency's client.
builder.Services
    .AddHttpClient<IPaymentClient, PaymentClient>(c =>
    {
        c.BaseAddress = new Uri("http://payment-service:8080");
        c.Timeout     = TimeSpan.FromSeconds(3);
    })
    .AddStandardResilienceHandler();   // retry + timeout + circuit breaker,
                                       // scoped to THIS client only

3. Saga — distributed transactions without a distributed transaction

Each microservice owns its own database, so there is no BEGIN TRANSACTION that spans Order, Payment and Inventory — and no global transaction manager to run one. The saga pattern's answer: model the business process as a sequence of local transactions, each committed in its own service, and when a later step fails, undo the earlier ones by running explicit compensating transactions.

Choreography — event-driven, no boss

Each service does its local transaction and publishes an event; the next service is listening and reacts. Nobody is in charge, and the "saga" is simply the chain that emerges.

Orchestration — a conductor tells everyone what to do

An orchestrator — a dedicated service, or a component inside one of them — holds the saga's state and issues explicit commands: "charge this card", "reserve this stock". Participants just do as they are told and reply. It is the same idea as the orchestrator in SOA.

public sealed class OrderSagaOrchestrator
{
    private readonly IPaymentService _payments;
    private readonly IInventoryService _inventory;
    private readonly IOrderService _orders;
    private readonly IDeadLetterQueue _deadLetters;

    public OrderSagaOrchestrator(IPaymentService payments,
                                 IInventoryService inventory,
                                 IOrderService orders,
                                 IDeadLetterQueue deadLetters)
    {
        _payments = payments; _inventory = inventory;
        _orders = orders; _deadLetters = deadLetters;
    }

    public async Task<SagaResult> PlaceOrderAsync(OrderRequest request, CancellationToken ct = default)
    {
        var sagaId = Guid.NewGuid().ToString("N");

        // Each completed step pushes the action that undoes it, with a name so a
        // failed undo can say which one it was.
        var compensations = new Stack<(string Name, Func<Task> Undo)>();

        try
        {
            var orderId = await _orders.CreatePendingAsync(request, ct);
            compensations.Push(("cancel-order", () => _orders.MarkCancelledAsync(orderId)));

            var paymentId = await _payments.ChargeAsync(request.CustomerId, request.Total, ct);
            compensations.Push(("refund-payment", () => _payments.RefundAsync(paymentId)));

            await _inventory.ReserveAsync(orderId, request.Items, ct);
            compensations.Push(("release-stock", () => _inventory.ReleaseAsync(orderId)));

            await _orders.MarkConfirmedAsync(orderId, ct);
            return SagaResult.Completed(orderId);
        }
        catch (Exception ex)
        {
            var outstanding = await CompensateAsync(compensations, sagaId);

            // A saga whose compensations all succeeded is back to a consistent
            // state. One whose compensations DIDN'T is not, and must not claim to
            // be — "compensated" would hide a real charge that was never refunded.
            return outstanding.Count == 0
                ? SagaResult.Compensated(ex.Message)
                : SagaResult.CompensationFailed(ex.Message, outstanding);
        }
    }

    /// Returns the names of the compensations that could not be completed.
    private async Task<IReadOnlyList<string>> CompensateAsync(
        Stack<(string Name, Func<Task> Undo)> compensations, string sagaId)
    {
        var outstanding = new List<string>();

        while (compensations.Count > 0)
        {
            var (name, undo) = compensations.Pop();
            try
            {
                await undo();
            }
            catch (Exception ex)
            {
                // The worst case: the forward step failed AND taking it back
                // failed. Automation is out of options, so escalate to a human —
                // and keep unwinding, because the remaining undos can still work.
                outstanding.Add(name);
                await _deadLetters.SendAsync(
                    $"compensation:{sagaId}:{name}",
                    $"Compensation '{name}' failed: {ex.Message}");
            }
        }

        return outstanding;
    }
}

public interface IDeadLetterQueue
{
    Task SendAsync(string messageId, string reason);
}

public enum SagaStatus { Completed, Compensated, CompensationFailed }

public sealed record SagaResult(
    SagaStatus Status, string? OrderId, string? Reason,
    IReadOnlyList<string> OutstandingCompensations)
{
    public static SagaResult Completed(string orderId) =>
        new(SagaStatus.Completed, orderId, null, Array.Empty<string>());

    public static SagaResult Compensated(string reason) =>
        new(SagaStatus.Compensated, null, reason, Array.Empty<string>());

    // The third state is the one people forget. Without it, "we tried to undo it"
    // and "we undid it" are indistinguishable to every caller downstream.
    public static SagaResult CompensationFailed(string reason, IReadOnlyList<string> outstanding) =>
        new(SagaStatus.CompensationFailed, null, reason, outstanding);
}

// The participants, as seen by the orchestrator. Note that none of them
// knows the others exist — only the orchestrator knows the workflow.
public sealed record OrderRequest(Guid CustomerId, decimal Total, IReadOnlyList<string> Items);

public interface IOrderService
{
    Task<string> CreatePendingAsync(OrderRequest request, CancellationToken ct);
    Task MarkConfirmedAsync(string orderId, CancellationToken ct);
    Task MarkCancelledAsync(string orderId);      // compensation
}

public interface IPaymentService
{
    Task<string> ChargeAsync(Guid customerId, decimal amount, CancellationToken ct);
    Task RefundAsync(string paymentId);           // compensation
}

public interface IInventoryService
{
    Task ReserveAsync(string orderId, IReadOnlyList<string> items, CancellationToken ct);
    Task ReleaseAsync(string orderId);            // compensation
}

Choreography vs orchestration

Neither is "correct" — this is a genuine trade-off, and being able to argue it both ways is the point.

4. CQRS — Command Query Responsibility Segregation

In a high-scale system, the way you write data is very different from the way you read it. Writes want normalisation, validation and strict consistency. Reads want denormalisation, pre-joined shapes and raw speed — and there are usually a hundred times more of them. CQRS stops those two jobs fighting over one model by splitting them:

One detail in the code below is easy to skip past and is the difference between a read model that eventually catches up and one that is permanently wrong. The command handler does not save the order and then publish an event as a second step — that is the dual-write problem from Chapter 10, and a crash in between would leave an order that the read model never hears about. Instead it writes the order row and an outbox row in one local transaction, and a separate relay publishes from the outbox.

// ---------- COMMAND SIDE: normalised, validated, returns an id — not a view ----------
public sealed record PlaceOrderCommand(Guid CustomerId, IReadOnlyList<OrderLine> Lines);
public sealed record OrderLine(string Sku, int Quantity, decimal UnitPrice);

public sealed class PlaceOrderHandler
{
    private readonly IOrderWriteStore _write;

    public PlaceOrderHandler(IOrderWriteStore write) => _write = write;

    public async Task<Guid> HandleAsync(PlaceOrderCommand command)
    {
        if (command.Lines.Count == 0)
            throw new ArgumentException("An order must have at least one line.");

        var orderId = Guid.NewGuid();
        var total = command.Lines.Sum(l => l.Quantity * l.UnitPrice);

        // ONE local ACID transaction writes the order AND the outbox row, so there
        // is no second, independently-failable "publish" step to get out of sync.
        await _write.SaveWithOutboxAsync(
            new OrderRow(orderId, command.CustomerId, command.Lines, total),
            new OrderPlaced(orderId, command.CustomerId, total, LineCount: command.Lines.Count));

        return orderId;   // an id, not a view — the caller must QUERY for the view
    }
}

// ---------- QUERY SIDE: denormalised, shaped for one screen ----------
public sealed record OrderSummary(
    Guid OrderId, string CustomerName, string CustomerCity,
    int LineCount, decimal Total, string Status);

public sealed class OrderSummaryQueryHandler
{
    private readonly IOrderReadStore _read;
    public OrderSummaryQueryHandler(IOrderReadStore read) => _read = read;

    // One lookup against a pre-joined row. No joins, no aggregation at read time.
    public Task<OrderSummary?> HandleAsync(Guid orderId) => _read.GetSummaryAsync(orderId);
}

// ---------- THE PROJECTOR: the only thing connecting the two ----------
public sealed class OrderSummaryProjector
{
    private readonly IOrderReadStore _read;
    private readonly ICustomerReadStore _customers;

    public OrderSummaryProjector(IOrderReadStore read, ICustomerReadStore customers)
    {
        _read = read; _customers = customers;
    }

    // Upsert, not insert: at-least-once delivery means this can run twice for the
    // same event, and a projector that is not idempotent corrupts the read model.
    public async Task OnAsync(OrderPlaced e)
    {
        var customer = await _customers.GetAsync(e.CustomerId);
        await _read.UpsertSummaryAsync(new OrderSummary(
            e.OrderId, customer.Name, customer.City, e.LineCount, e.Total, "PENDING"));
    }
}

// The event carries everything the read model needs. If the projector had to call
// back into the write side for the line count, the two would be coupled again.
public sealed record OrderPlaced(Guid OrderId, Guid CustomerId, decimal Total, int LineCount);

// The two stores are deliberately different shapes — that is the whole point.
public sealed record OrderRow(
    Guid OrderId, Guid CustomerId, IReadOnlyList<OrderLine> Lines, decimal Total);

public interface IOrderWriteStore
{
    /// Persists the order row and the outbox row in ONE local transaction.
    /// A separate message relay polls the outbox, publishes, and marks rows sent.
    Task SaveWithOutboxAsync(OrderRow order, OrderPlaced @event);
}

public interface IOrderReadStore
{
    Task<OrderSummary?> GetSummaryAsync(Guid orderId);
    Task UpsertSummaryAsync(OrderSummary summary);
}

public interface ICustomerReadStore
{
    Task<CustomerView> GetAsync(Guid customerId);
}

public sealed record CustomerView(Guid Id, string Name, string City);

5. Sidecar

The sidecar attaches a helper component to your main service — deployed alongside it, sharing its lifecycle and its local network — and hands that helper all the peripheral work: logging, metrics, tracing, TLS, retries, and service-to-service routing. Your service goes back to doing only its actual job.

Because the sidecar handles the network, your service's only obligation is to be sidecar-aware — which in practice means exposing health endpoints so the platform can tell whether to route traffic to you and whether to restart you:

builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy())          // is the process alive?
    .AddNpgSql(connectionString, name: "orders-db", tags: ["ready"]); // can it actually serve?

// Liveness: "am I broken beyond recovery?" — failing this gets you RESTARTED.
app.MapHealthChecks("/health/live", new HealthCheckOptions
{
    Predicate = _ => false            // no dependency checks: a dead DB is not a reason to restart me
});

// Readiness: "should traffic come to me right now?" — failing this gets you
// REMOVED FROM THE LOAD BALANCER, then put back when you recover.
app.MapHealthChecks("/health/ready", new HealthCheckOptions
{
    Predicate = check => check.Tags.Contains("ready")
});

Idempotency — the safety net that makes sagas work

In a distributed system, "exactly once" delivery is nearly impossible; "at least once" is the reality. A message broker that isn't sure whether you processed a message will send it again. A client whose request timed out will retry — even though the server may have processed the first attempt perfectly and just lost the response on the way back.

So every endpoint that changes something must be idempotent: calling it more than once with the same input has no additional effect beyond the first call. Without that, one dropped response packet charges your customer twice.

The idempotency key workflow

For operations that aren't naturally idempotent, the caller (a client, or your saga orchestrator) sends a unique key with the request — conventionally an X-Idempotency-Key header — and the server remembers what it did with that key.

using System.Data;
using System.Text.Json;

// Store the real status code AND the real body, so a replay is indistinguishable
// from the original response — including when the original was a failure.
public sealed record IdempotentResponse(int StatusCode, string Body);

// Three genuinely different answers, so make them three cases. A nullable
// response cannot express them: "null" would mean both "you claimed it" and
// "somebody else owns it but hasn't finished".
public abstract record ClaimResult
{
    public sealed record Claimed : ClaimResult;
    public sealed record Replay(IdempotentResponse Response) : ClaimResult;

    /// Same key, DIFFERENT request — the caller reused a key by mistake.
    /// Replaying an unrelated response would be worse than refusing.
    public sealed record FingerprintMismatch : ClaimResult;
}

// Deterministic outcomes only. Anything transient — a timeout, a deadlock, the
// gateway being unreachable — must THROW rather than return Declined.
public abstract record ChargeOutcome
{
    public sealed record Charged(string PaymentId) : ChargeOutcome;
    public sealed record Declined(string Reason) : ChargeOutcome;
}

public interface IChargeStore
{
    Task<IDbTransaction> BeginTransactionAsync();

    /// ① CHECK + ② CLAIM, atomically — SQL in "Production details" below.
    Task<ClaimResult> TryClaimAsync(
        IDbTransaction tx, string key, string fingerprint, TimeSpan ttl);

    Task<ChargeOutcome> TryChargeAsync(IDbTransaction tx, string customerId, decimal amount);

    Task SaveResponseAsync(IDbTransaction tx, string key, IdempotentResponse response);
}

public sealed class ChargeHandler
{
    private static readonly TimeSpan Ttl = TimeSpan.FromHours(24);
    private readonly IChargeStore _store;

    public ChargeHandler(IChargeStore store) => _store = store;

    public async Task<IResult> ChargeAsync(string? rawKey, string customerId, decimal amount)
    {
        if (string.IsNullOrWhiteSpace(rawKey))
            return Results.BadRequest("X-Idempotency-Key header is required.");

        // Refuse at the edge what the currency cannot represent, so that nothing
        // downstream is ever tempted to round it into place.
        if (!Money.IsSupportedPrecision(amount))
            return Results.BadRequest("Amount has more precision than the currency supports.");

        var key = $"{customerId}:{rawKey}";              // scope per caller
        var fingerprint = Fingerprint.Of(customerId, amount);

        using var tx = await _store.BeginTransactionAsync();

        switch (await _store.TryClaimAsync(tx, key, fingerprint, Ttl))
        {
            case ClaimResult.Replay(var stored):         // ④ REPLAY
                tx.Rollback();                            // we did nothing
                return Results.Content(stored.Body, "application/json",
                                       statusCode: stored.StatusCode);

            case ClaimResult.FingerprintMismatch:
                tx.Rollback();
                return Results.Conflict(
                    "This idempotency key was already used with different parameters.");

            case ClaimResult.Claimed:
                break;                                    // we own it — carry on
        }

        // The claim, the side effect and ③ the stored response commit TOGETHER.
        // If TryChargeAsync throws, the `using` rolls all three back, so the
        // client's retry gets a genuine second attempt rather than finding a
        // half-finished key. That is the whole reason they share a transaction.
        var response = await _store.TryChargeAsync(tx, customerId, amount) switch
        {
            ChargeOutcome.Charged(var paymentId) => new IdempotentResponse(
                201, JsonSerializer.Serialize(new { paymentId, amount })),

            // A decline is a real answer, so it is stored and committed like any
            // other. Retry this request and you must get the same 402 back.
            ChargeOutcome.Declined(var reason) => new IdempotentResponse(
                402, JsonSerializer.Serialize(new { error = reason })),

            _ => throw new InvalidOperationException("Unhandled charge outcome.")
        };

        await _store.SaveResponseAsync(tx, key, response);
        tx.Commit();

        return Results.Content(response.Body, "application/json",
                               statusCode: response.StatusCode);
    }
}

using System.Globalization;
using System.Security.Cryptography;
using System.Text;

public static class Money
{
    // Two decimal places is what this currency supports; anything finer is a
    // bad request, not something to quietly round.
    public static bool IsSupportedPrecision(decimal amount) =>
        decimal.Round(amount, 2) == amount;

    // Exact for any amount that passed the check above: decimal arithmetic is
    // not binary floating point, so 120.00m * 100m is exactly 12000m.
    public static long ToMinorUnits(decimal amount) => (long)(amount * 100m);
}

public static class Fingerprint
{
    /// Canonicalise, keep it lossless, THEN hash.
    ///   · InvariantCulture, so a replica running under a comma-decimal locale
    ///     doesn't hash "120,00" while its neighbour hashes "120.00";
    ///   · integer minor units, so 120, 120.0 and 120.00 — the same money —
    ///     agree, without rounding anything away.
    ///
    /// The trap: formatting with "F2" also makes those three agree, and looks
    /// right. It is lossy. 120.001 and 120.004 both become "120.00", so two
    /// genuinely different amounts hash identically and the second request
    /// replays the first one's response. NEVER round only for the fingerprint —
    /// validate the precision first (above), then hash a lossless form.
    public static string Of(string customerId, decimal amount)
    {
        var canonical = string.Create(CultureInfo.InvariantCulture,
            $"{customerId}|{Money.ToMinorUnits(amount)}");

        return Convert.ToHexString(SHA256.HashData(Encoding.UTF8.GetBytes(canonical)));
    }
}

-- ① CHECK + ② CLAIM
INSERT INTO idempotency_keys (key, fingerprint, expires_at)
VALUES (@key, @fingerprint, @expires)
ON CONFLICT (key) DO NOTHING;

-- 1 row inserted  => Claimed.
-- 0 rows inserted => somebody else owns it, so go and read it:
SELECT fingerprint, status_code, body
FROM   idempotency_keys
WHERE  key = @key
FOR    UPDATE;

Dead letter queues

Some messages simply cannot be processed. The payload is malformed, it refers to a customer who no longer exists, or a bug throws on every single attempt. Retrying such a poison message forever is worse than useless: it blocks the queue behind it and burns resources on a call that will never succeed.

A dead letter queue is where those messages go after N failed attempts — a holding area, off the main path, where a human can inspect them, fix the cause, and replay them. It is the human-in-the-loop safety valve: the system stops trying to be clever and asks for help instead of silently dropping data.

private const int MaxAttempts = 3;

public async Task ConsumeAsync(QueueMessage message, CancellationToken ct)
{
    for (var attempt = 1; attempt <= MaxAttempts; attempt++)
    {
        try
        {
            await HandleAsync(message, ct);   // must be idempotent — this can run twice
            await _queue.AckAsync(message);
            return;
        }
        catch (Exception ex) when (IsTransient(ex) && attempt < MaxAttempts)
        {
            // Exponential backoff with jitter: 1s, 2s, 4s (± a random slice) so that
            // a thousand consumers don't all retry on the same tick.
            var delay = TimeSpan.FromSeconds(Math.Pow(2, attempt - 1))
                      + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 500));
            _logger.LogWarning(ex, "Attempt {Attempt} failed; retrying in {Delay}", attempt, delay);
            await Task.Delay(delay, ct);
        }
        catch (Exception ex)
        {
            // Either non-transient (a poison message — retrying cannot help),
            // or we've exhausted the ladder. Set it aside for a human.
            await _queue.DeadLetterAsync(message, reason: ex.Message);
            _logger.LogError(ex, "Message {Id} dead-lettered after {Attempt} attempts",
                             message.Id, attempt);
            return;
        }
    }
}

The three pillars of distributed safety

These three patterns are usually taught separately, and each is perfectly useful alone — an idempotency key protects an ordinary HTTP endpoint with no queue or saga anywhere in sight. But a workflow like this one needs all three, because each covers a failure the others leave open.

Design patterns inside a service

Everything above is architectural — patterns about how services talk to each other. But a microservice is still just a program, and inside it the ordinary GoF patterns from Chapters 3–5 do the work. The slides make the two levels explicit:

The running example is a Notification Service that a checkout flow calls. Three patterns, three different jobs.

Creational Factory Method — choosing a driver from configuration

A microservice constantly needs to create a different driver based on configuration or on the request: send this notification by email, or SMS, or push. The calling code should say "give me a notifier for this channel" and know nothing about which class it gets.

Structural Adapter — surviving third-party APIs

Microservices constantly talk to external providers (Stripe, Twilio, MessageBird, AWS) whose APIs are strange, verbose and prone to change. The Adapter wraps each provider so that switching from Twilio to MessageBird means writing one new adapter — your business logic never learns that anything changed.

Behavioral Strategy — changing behaviour at runtime

A pricing service applies a different discount calculation on Black Friday than on a regular Tuesday. The Strategy pattern makes each rule an interchangeable object chosen at runtime, instead of an if chain that grows a new branch every promotion.

All three, in one checkout endpoint

Here is the slides' final example, ported to C#. Watch which pattern does what: Strategy decides the price, Factory picks the delivery tool, and an Adapter hides the fact that the SMS tool is a hostile third-party SDK.

// ===== BEHAVIORAL: Strategy — the pricing rule is chosen at runtime =====
public interface IPricingStrategy
{
    string Name { get; }
    decimal Apply(decimal price);
}

public sealed class RegularPricing : IPricingStrategy
{
    public string Name => nameof(RegularPricing);
    public decimal Apply(decimal price) => price;
}

public sealed class BlackFridayPricing : IPricingStrategy
{
    public string Name => nameof(BlackFridayPricing);
    public decimal Apply(decimal price) => price * 0.5m;   // 50% off
}

// ===== STRUCTURAL: Adapter — a third-party SDK with an awkward shape =====
// Pretend this comes from a NuGet package you do not control.
public sealed class LegacySmsSdk
{
    public string TransmitTextIso8859(string num, string payload)
        => $"SDK sent: {payload} to {num}";
}

// Our own interface — the shape our application actually wants.
public interface INotificationChannel
{
    Task<string> NotifyAsync(string recipient, string message);
}

public sealed class SmsAdapter : INotificationChannel
{
    private readonly LegacySmsSdk _sdk = new();

    // Adapting our simple NotifyAsync call to the SDK's awkward method.
    public Task<string> NotifyAsync(string recipient, string message)
        => Task.FromResult(_sdk.TransmitTextIso8859(recipient, message));
}

public sealed class EmailChannel : INotificationChannel
{
    public Task<string> NotifyAsync(string recipient, string message)
        => Task.FromResult($"Email delivered to {recipient}: {message}");
}

// ===== CREATIONAL: a factory — pick the driver from configuration =====
public static class NotificationFactory
{
    public static INotificationChannel Create(string channel) => channel switch
    {
        "sms"   => new SmsAdapter(),
        "email" => new EmailChannel(),
        _       => throw new ArgumentException($"Invalid channel '{channel}'.")
    };
}

// ===== The endpoint, bringing all three together =====
public static class Checkout
{
    public static async Task<string> RunAsync(
        decimal basePrice, string customerContact, string channel, bool isSale)
    {
        // 1. BEHAVIORAL Strategy decides the price.
        IPricingStrategy pricing = isSale ? new BlackFridayPricing() : new RegularPricing();
        var finalPrice = pricing.Apply(basePrice);

        // 2. CREATIONAL factory gets the right tool.
        var notifier = NotificationFactory.Create(channel);

        // 3. Use the tool — which may well be a STRUCTURAL Adapter.
        var message = $"Order confirmed! You paid ${finalPrice:F2}";
        var deliveryReport = await notifier.NotifyAsync(customerContact, message);

        return $"price_applied={finalPrice:F2}, strategy_used={pricing.Name}, delivery={deliveryReport}";
    }
}

public static class Program
{
    public static async Task Main()
    {
        Console.WriteLine(await Checkout.RunAsync(100m, "alice@example.com", "email", isSale: false));
        Console.WriteLine(await Checkout.RunAsync(100m, "+94771234567",      "sms",   isSale: true));
    }
}

Chapter 11 quiz