Seven Backend Patterns for Scalable Systems — and When Not to Use Them

Every backend pattern fixes one problem and creates another. Knowing which problem you actually have matters more than knowing the pattern’s name.

A pattern is a recorded trade-off

A pattern is useful because someone has already worked out what it fixes and what it costs. It becomes harmful when it is adopted for its name. For each of the seven below, this guide covers what it solves, what it adds to build and operate, and when to leave it out.

The sketches are in C#, but the ideas are not tied to .NET. Where a .NET library is named, it is one implementation of the pattern and not the pattern itself.

Three kinds of pattern

Strictly, none of these seven is a design pattern in the Gang of Four sense, which describes structure inside a program. Using the right word helps you ask the right question.

• Design pattern. A solution to a recurring problem inside a program, such as Strategy or Decorator.
• Architectural pattern. Shapes how a system is divided into parts and how they communicate.
• Integration or resilience pattern. Governs how components exchange data, or how they survive each other’s failures.
• Implementation technique. A specific mechanism that realises a pattern, such as an expiry on a cache entry, an idempotency key or a polling relay.

The boundaries are fuzzy, and catalogues classify some of these differently.

1. Cache-aside

Implementation technique Caching strategy

The problem. The same data is read far more often than it changes, and every read pays for a trip to the data store.

How it works. The application checks the cache first. On a hit it returns the cached value. On a miss it reads from the data store, saves the result in the cache with an expiry, and returns it. Writes go to the data store, and the cached entry is removed or left to expire.

public sealed class ProductReader(HybridCache cache, ProductDb db)
{
    public ValueTask<ProductDto?> GetAsync(int id, CancellationToken ct) =>
        cache.GetOrCreateAsync(
            $"product:{id}",
            async token => await db.Products
                .Where(p => p.Id == id)
                .Select(p => new ProductDto(p.Id, p.Name, p.Price))
                .FirstOrDefaultAsync(token),
            new HybridCacheEntryOptions { Expiration = TimeSpan.FromMinutes(5) },
            cancellationToken: ct);

    public async Task UpdateAsync(Product product, CancellationToken ct)
    {
        db.Update(product);
        await db.SaveChangesAsync(ct);
        await cache.RemoveAsync($"product:{product.Id}", ct); // invalidate on write
    }
}

HybridCache (package Microsoft.Extensions.Caching.Hybrid, generally available from ASP.NET Core 9) performs the check-and-fill steps and ensures only one concurrent caller runs the factory for a given key, which guards against stampedes. Other caches follow the same steps.

2. Queue-based load levelling

Integration pattern With competing consumers

The problem. Traffic arrives in bursts, but the work behind it can only run at a steady rate. Without a buffer, a burst lands directly on the slower component, which then times out or fails.

How it works. A queue sits between the producer and the worker. The producer adds a message and returns at once. Consumers take messages at the rate they can sustain. More consumers reading the same queue (competing consumers) raise throughput without changing the producer.

// Producer: accept quickly, enqueue, answer "accepted"
app.MapPost("/reports", (ReportRequest request, Channel<ReportRequest> queue) =>
    queue.Writer.TryWrite(request)
        ? Results.Accepted()
        : Results.StatusCode(503));        // bounded queue is full: shed load

// Consumer: drain at a rate the downstream can sustain
public sealed class ReportWorker(Channel<ReportRequest> queue, ReportService reports) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        await foreach (var request in queue.Reader.ReadAllAsync(ct))
            await reports.GenerateAsync(request, ct);
    }
}

An in-process channel loses its contents if the process stops. For work that must survive a restart, use a durable broker. The pattern is the same.

3. CQRS

Architectural pattern Command Query Responsibility Segregation

The problem. The model that suits changing data, with validation and consistency rules, is often awkward for reading it, which needs joins and a different shape per screen. One model for both gets compromised.

How it works. Separate the operations that change state (commands) from those that read it (queries), and give each its own model. In its simplest form, both still use the same database. Separate read stores, kept in step by projections, are an option for when the read side needs different storage or scale. CQRS does not require separate databases, and it does not require event sourcing.

public sealed class PlaceOrderHandler(OrdersDb db)
{
    public async Task HandleAsync(PlaceOrder command, CancellationToken ct)
    {
        var order = Order.Create(command.CustomerId, command.Lines);   // domain rules live here
        db.Orders.Add(order);
        await db.SaveChangesAsync(ct);
    }
}

public sealed class OrderSummaryHandler(OrdersDb db)
{
    public Task<OrderSummaryDto?> HandleAsync(GetOrderSummary query, CancellationToken ct) =>
        db.Orders.AsNoTracking()                                       // same database, read-shaped model
            .Where(o => o.Id == query.OrderId)
            .Select(o => new OrderSummaryDto(o.Id, o.Status, o.Lines.Count, o.Total))
            .FirstOrDefaultAsync(ct);
}

4. Transactional outbox and idempotent consumer

Integration pattern With an idempotent consumer as an implementation technique

The problem. A service saves a change and then publishes an event. If it saves and crashes before publishing, the event is lost. If it publishes first and the save fails, the event describes something that never happened. The database and the broker cannot share one transaction.

How it works. In the same transaction that saves the change, write the event to an outbox table. A separate relay reads unsent rows, publishes them and marks them as sent. The relay can publish a message and fail before marking it, so delivery is at least once and duplicates are possible.

That is why an idempotent consumer is the usual companion: it records the IDs of messages it has handled and ignores repeats. Neither needs the other. Naturally idempotent handlers can sit behind an outbox, and an idempotent consumer helps behind any at-least-once source.

// Publisher side: one transaction writes the change and the event
db.Orders.Add(order);
db.Outbox.Add(new OutboxMessage
{
    Id = Guid.NewGuid(),
    Type = nameof(OrderPlaced),
    Payload = JsonSerializer.Serialize(new OrderPlaced(order.Id, order.Total)),
    CreatedAt = DateTimeOffset.UtcNow
});
await db.SaveChangesAsync(ct);

// Consumer side: ignore messages that were already handled
if (await db.Processed.AnyAsync(p => p.MessageId == messageId, ct)) return;
await ApplyEffectAsync(message, ct);
db.Processed.Add(new ProcessedMessage(messageId));  // unique index on MessageId guards races
await db.SaveChangesAsync(ct);

Some messaging libraries include outbox support. The sketch shows the mechanism only and is not a recommendation of any library.

5. Saga

Integration pattern Orchestration or choreography

The problem. A business operation spans several services, each with its own data. One database transaction cannot cover them, so when step three fails, steps one and two have already committed.

How it works. Split the operation into local transactions, one per service. If a step fails, run compensating actions for the steps that completed, such as releasing the stock or refunding the payment. A compensation is a new action and not a rollback. Some actions, such as an email already sent, cannot be undone, and other readers can see the intermediate state.

In orchestration, a coordinator tells each service what to do next, which is easier to follow. In choreography, each service reacts to the others’ events, which has fewer parts until the flow grows.

Sagas and outboxes often appear together, because each step must update its state and send the next message reliably. A saga does not require an outbox.

public enum OrderSagaState { Started, StockReserved, PaymentTaken, Completed, Compensating, Failed }

// The orchestrator reacts to each event and decides what happens next
switch (@event)
{
    case StockReserved:
        saga.State = OrderSagaState.StockReserved;
        await bus.SendAsync(new TakePayment(saga.OrderId));
        break;
    case ShippingFailed when saga.State == OrderSagaState.PaymentTaken:
        saga.State = OrderSagaState.Compensating;
        await bus.SendAsync(new RefundPayment(saga.OrderId));   // compensating action
        break;
}

6. Circuit breaker, with timeouts and retries

Resilience pattern Timeouts and retries are implementation techniques

The problem. A slow or failing dependency holds its callers’ resources, and callers that keep retrying add load to something already struggling. One bad dependency can spread failure across the system.

Three tools, three jobs. They are often grouped, but none replaces another.

• Timeout. Limits how long you wait for one call, so a slow dependency cannot hold your resources.
• Retry. Repeats a call after a transient failure. It needs backoff, jitter and a limit, and it is only safe for operations that can be repeated.
• Circuit breaker. Stops calling a dependency that keeps failing, so it can recover and callers fail fast.

Used together they form layers. Retries without a breaker keep pushing on a struggling service, and timeouts alone do not stop a pile-up.

builder.Services
    .AddHttpClient<PaymentsClient>(c => c.BaseAddress = new Uri("https://payments.internal"))
    .AddStandardResilienceHandler(options =>
    {
        // The defaults retry every HTTP method. Don't retry calls that aren't safe to repeat.
        options.Retry.DisableForUnsafeHttpMethods();
    });

Microsoft.Extensions.Http.Resilience, which builds on Polly, provides a standard handler that layers a rate limiter, a total timeout, retries, a circuit breaker and a per-attempt timeout, each with documented defaults. Treat those defaults as a starting point and check them against your version. They retry every HTTP method unless you change that.

7. Strangler fig

Architectural (migration) pattern About modernising, not scaling

The problem. A legacy system is hard to change, but replacing it in one go is risky and means a long period with nothing shipped. This pattern does not make a running system faster or more scalable. It makes replacing one safer.

How it works. Put a façade, usually a proxy, in front of the legacy system. At first it routes everything to the legacy system. Then, one capability at a time, build the replacement and move the matching routes to it. The legacy system shrinks until it can be switched off, and then the façade can go too.

{
  "ReverseProxy": {
    "Routes": [
      { "RouteId": "invoices", "ClusterId": "new-system",
        "Match": { "Path": "/invoices/{**catch-all}" } },
      { "RouteId": "everything-else", "ClusterId": "legacy",
        "Match": { "Path": "{**catch-all}" } }
    ],
    "Clusters": {
      "new-system": { "Destinations": { "d1": { "Address": "https://new.internal/" } } },
      "legacy":     { "Destinations": { "d1": { "Address": "https://legacy.internal/" } } }
    }
  }
}

YARP is a reverse proxy library for .NET. Any proxy or gateway that can route by path serves the same purpose. The configuration shape above follows YARP’s documentation, so check it against the version you use.

Choosing between them

Patterns combine, but none requires another. A saga step may use an outbox. A queue consumer may call a dependency guarded by a circuit breaker. Add a combination only when each part has its own reason.

Adopting patterns gradually

I’d treat each pattern as a response to a symptom you can observe, not as a starting point. Measure first, adopt the smallest form that helps, such as CQRS over one database, and write down what you gave up. Each pattern also adds something to watch: hit rate, queue depth, outbox lag, saga states, breaker state.

Two related areas on this site go deeper. The System Design page covers designing for failure and the architecture toolkit, and the URL Shortener walkthrough shows caching and partitioning in a worked design.

References

• HybridCache in ASP.NET Core, Microsoft Learn
• Build resilient HTTP apps, Microsoft Learn
• Strangler Fig pattern, Azure Architecture Center
• YARP overview, Microsoft Learn

← Back to all Insights