The False Comfort of the Happy Path: Decoupling Your Services

The school lunch line that froze

Imagine a school canteen at lunchtime. There is one long line of hungry students.

At the front, one student is paying. But the canteen lady cannot find the right change. So she stops. She does not serve the next student. She just waits for the change. And because she waits, the whole line waits too. Fifty students stand still because of one coin.

Now imagine a smarter canteen. The student who needs change steps aside to a small side counter. Everyone else keeps moving. The line never freezes. The one slow case is handled on its own, and the rest of the school still eats on time.

Software services are just like that lunch line. When one service calls another and waits, a single slow or broken service can freeze the whole chain. This article is about not freezing the line. It is about building services that keep calm when one of their neighbours is having a bad day.

What the happy path really is

The happy path is the story you tell yourself while writing code.

In that story, every service answers instantly. The network never drops. No database is ever busy. Every input is clean and correct. You write your code for that perfect world, you run it once on your laptop, it works, and you feel safe.

That feeling is the false comfort. It is comfortable because nothing has gone wrong yet. But the happy path is only one of many paths. Real systems wander off it all the time.

Now look at the real world. The same request, but one step has a bad moment.

The code for both pictures can look identical. The difference is not in the lines you wrote. The difference is in what you forgot to handle.

Why direct calls couple your services together

Let us look at the most common shape of code that lives only on the happy path. One service calls another over HTTP and waits for the reply.

// Orders service calling the Payments service directly.
// This is the "phone call" style: ask, then wait.
public class OrderService
{
    private readonly HttpClient _http;
 
    public OrderService(HttpClient http) => _http = http;
 
    public async Task PlaceOrderAsync(Order order)
    {
        // Save the order first.
        await SaveOrderAsync(order);
 
        // Now wait for Payments to answer. If it is slow, we are stuck.
        var response = await _http.PostAsJsonAsync("/charge", order);
        response.EnsureSuccessStatusCode();
 
        // Only after payment do we send the email.
        await _http.PostAsJsonAsync("http://email/send", order);
    }
}

This code reads nicely. But it has a hidden chain. Orders waits for Payments. The user waits for Orders. If Payments is slow, everyone above it is slow too. This is called temporal coupling: the two services must be healthy at the same time for anything to work.

The more arrows you have like this, the more fragile your system becomes. With four services each up 99% of the time, the chance that all four are healthy together is lower than any single one. Coupling multiplies risk.

Look at the last row. Ten small services that each almost never fail still give you a chain that breaks one time in ten. That is the math of tight coupling. The fix is to stop making every step wait for every other step.

Decoupling step one: send a message, do not wait

The first big idea is simple. When a service does not truly need the answer right now, do not wait for it. Send a message and move on.

Think back to the post office. A phone call makes you wait on the line. A posted letter lets you drop it in the box and walk away. The post office holds it and delivers it later.

In software, the "post office" is a message broker, such as RabbitMQ or Azure Service Bus. Your service publishes a message. The broker holds it safely. The other service reads it when it is ready.

Now the email service can be down for ten minutes and nothing breaks. The message simply waits in the queue. When email comes back, it reads the waiting messages and catches up. Orders never knew there was a problem. The line never froze.

Here is the same idea in .NET. Instead of calling email directly, Orders just announces what happened.

// Decoupled: Orders announces an event and moves on.
public class OrderService
{
    private readonly IMessagePublisher _bus;
 
    public OrderService(IMessagePublisher bus) => _bus = bus;
 
    public async Task PlaceOrderAsync(Order order)
    {
        await SaveOrderAsync(order);
 
        // Tell the world it happened. Do not wait for anyone to react.
        await _bus.PublishAsync(new OrderPlaced(order.Id, order.Email));
 
        // We are done. Email and shipping will react on their own.
    }
}

The email service listens for that event in its own time:

// The Email service reacts when it is ready, not when Orders demands.
public class OrderPlacedHandler
{
    private readonly IEmailSender _email;
 
    public OrderPlacedHandler(IEmailSender email) => _email = email;
 
    public async Task HandleAsync(OrderPlaced message)
    {
        // If this service was down, the message waited in the queue for it.
        await _email.SendConfirmationAsync(message.CustomerEmail, message.OrderId);
    }
}

A quick note on tools. Two popular .NET messaging libraries, MassTransit and MediatR, moved to a commercial license for their newer versions. You can still use them, but check the license and pricing for your team. Plain options like the official client for RabbitMQ or Azure Service Bus remain free, and the in-process channel type System.Threading.Channels is built into .NET.

When you genuinely must wait, wait safely

Sometimes you really do need the answer before you continue. Checking a price. Reserving stock. Confirming a payment before you show "Order complete". For these, a direct call is fine. But a naive direct call is where the happy path bites hardest.

So when you must wait, wait safely. That means three small safety nets: a timeout, a retry, and a circuit breaker.

Timeout: do not wait forever

A timeout says "I will wait this long and no longer". Without it, a slow service can hold your thread until it gives up on its own, which might be 100 seconds. With a timeout you fail fast and stay in control.

Retry: try again, gently

Many failures are tiny hiccups. A dropped packet. A service restarting. A retry simply tries again after a short pause. The key is to wait a little longer each time, called exponential backoff, and add a little randomness, called jitter, so that a thousand clients do not all retry at the exact same second and cause a stampede.

Circuit breaker: stop knocking on a broken door

If a service has failed many times in a row, it is clearly having a bad time. Retrying again only adds more load and makes things worse. A circuit breaker watches the failures. After too many, it "opens" and stops the calls for a while, returning quickly instead. Later it lets a test call through to check if the service has recovered. If yes, it "closes" again and normal traffic resumes.

This is exactly like a fuse in your home. When something draws too much current, the fuse trips and cuts the power so the wires do not burn. The circuit breaker trips so your service does not burn itself out hammering a dead neighbour.

Putting the safety nets together in .NET

The standard .NET tool for all three nets is Polly. With Polly v8 you build a ResiliencePipeline. For HTTP calls, the Microsoft.Extensions.Http.Resilience package gives you a ready-made pipeline with a single line.

// Program.cs — add resilience to a typed HttpClient with one line.
using Microsoft.Extensions.Http.Resilience;
 
builder.Services
    .AddHttpClient<PaymentClient>(c =>
    {
        c.BaseAddress = new Uri("https://payments.internal");
    })
    // Adds retry, timeout, circuit breaker, and a rate limiter.
    .AddStandardResilienceHandler();

That one call, AddStandardResilienceHandler, combines five strategies for you: a rate limiter, a total timeout across all attempts, a retry, a circuit breaker, and a per-attempt timeout. It is a sensible default for most internal calls.

When you need more control, build the pipeline by hand. This makes each safety net visible and tunable.

// A hand-built pipeline so you can see every safety net.
using Polly;
using Polly.CircuitBreaker;
using Polly.Retry;
using Polly.Timeout;
 
var pipeline = new ResiliencePipelineBuilder()
    // 1) Retry transient failures with backoff and jitter.
    .AddRetry(new RetryStrategyOptions
    {
        MaxRetryAttempts = 3,
        BackoffType = DelayBackoffType.Exponential,
        UseJitter = true
    })
    // 2) Trip the breaker if half the calls fail in the sampling window.
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 8,
        BreakDuration = TimeSpan.FromSeconds(15)
    })
    // 3) Never let a single attempt run longer than 5 seconds.
    .AddTimeout(TimeSpan.FromSeconds(5))
    .Build();
 
// Use it anywhere you make a risky call.
await pipeline.ExecuteAsync(async token =>
{
    await _http.PostAsJsonAsync("/charge", order, token);
});

The order matters. The retry sits outside the breaker and the timeout. So each attempt gets its own timeout, the breaker counts each attempt, and the retry decides whether to try once more.

A fallback for when nothing works

Even with all the nets, sometimes the answer just is not coming. A fallback is your plan B. Instead of showing the user an ugly error, you give them something reasonable.

If a "recommended products" service is down, show a simple list of popular items instead. If a live currency rate is unavailable, use the last known rate and label it. The user keeps moving. The line does not freeze.

// A safe fallback so the page still loads when the service is down.
public async Task<IReadOnlyList<Product>> GetRecommendationsAsync(int userId)
{
    try
    {
        return await _pipeline.ExecuteAsync(
            async token => await _client.GetRecommendedAsync(userId, token));
    }
    catch (Exception ex)
    {
        _logger.LogWarning(ex, "Recommendations unavailable. Using popular items.");
        return await _catalog.GetPopularItemsAsync(); // plan B
    }
}

This is a kind teacher's trick: when one student cannot answer, you do not stop the whole lesson. You move on and come back. The class keeps learning.

A simple rule for choosing your style

You do not have to make everything asynchronous, and you do not have to wait on everything. Use a small rule.

Most "after something happened" work, like sending emails, updating dashboards, awarding points, and writing logs, can become a message. That alone removes most of your tight coupling. Keep direct calls only for the few moments where you truly cannot move on without the reply, and wrap those in Polly.

Common mistakes to avoid

A few traps catch almost everyone the first time.

Do not retry a non-idempotent action blindly. If "charge the card" is retried, you might charge twice. Make the action safe to repeat first, often by giving each request an id the receiver can check, so a repeat does nothing.

Do not set retries without a circuit breaker. Endless retries against a dead service turn a small outage into a flood. The breaker is what stops the flood.

Do not forget timeouts on the broker side too. A consumer that hangs on a message can quietly stall a queue. Give handlers their own time limits and a path for messages that keep failing, often a "dead letter" queue.

Do not hide failures. Log them, count them, and put them on a dashboard. Decoupling does not mean ignoring problems. It means the rest of the system stays healthy while you fix the one that broke.

Quick recap

• The happy path is the version of your code where nothing goes wrong. It feels safe but it is a false comfort, because real systems leave it often.
• Tight coupling means services must be healthy at the same time. The longer the chain of waiting calls, the more often the whole thing breaks.
• Decouple by sending messages through a broker for any work that can happen a moment later. The sender does not wait, so a slow neighbour cannot freeze the line.
• When you truly must wait, wait safely with three nets: a timeout, a retry with backoff and jitter, and a circuit breaker.
• In .NET, Polly v8 and Microsoft.Extensions.Http.Resilience give you these nets. AddStandardResilienceHandler wires sensible defaults in one line.
• Add a fallback as plan B so users still get something useful when a service is down.
• Watch out for retrying unsafe actions, retries without a breaker, missing timeouts, and hidden failures.
• Note that MassTransit and MediatR newer versions are now commercially licensed, so check the terms before adopting them.

References and further reading

• Build resilient HTTP apps: Key development patterns — Microsoft Learn
• Implement the Circuit Breaker pattern — Microsoft Learn
• Asynchronous message-based communication — Microsoft Learn
• Communication in a microservice architecture — Microsoft Learn
• Building resilient cloud services with .NET — .NET Blog