DEV Community: Amine ABDALKHALKI

What an automation is, and how it actually works

Amine ABDALKHALKI — Sat, 26 Sep 2026 20:20:45 +0000

People rarely write to us with the word "automation". They write: every Monday I copy the orders into a spreadsheet. Or: I answer the same five questions on WhatsApp all day. Or: I chase invoices by hand and I hate it.

That's the right way in. An automation isn't a technology you buy. It's a task you stop doing, because something else now does it for you, the same way every time, including at three in the morning.

This article opens the bonnet: what happens inside, a few examples, and the tools that do the work, from Zapier to a few lines of .NET.

The drawing on the cover

The cover image shows a man drawing boxes on a sheet of glass. WhatsApp, an AI agent, a CRM, a calendar, a payment, joined by arrows. On the original article it's a video, and you can watch it being drawn.

That drawing is an automation. Every one we build starts as a sketch like it, usually on a call, sometimes on the back of whatever is lying on the desk.

Read it as a sentence: when this happens, do that. When a message arrives on WhatsApp, have it read, file the contact, book the visit, send the payment link. Nothing more mysterious than that.

Three parts, always the same

Every automation has a trigger, some steps and some actions.

The trigger is the event that starts everything: a new message, a form filled in, a payment, a file dropped in a folder, or simply a time of day. Most of the time it arrives as a webhook, the instant notice one app sends another the moment something happens.

The steps are what the automation does with what it received. It checks the data first, so nothing incomplete goes any further. It reshapes it, because your CRM and your accounting software never describe a customer the same way. And sometimes it lets an AI read it and decide: what the message is about, which figures matter on an invoice, who should deal with it.

The actions are where the result lands. A record in the CRM, an email or a WhatsApp reply to the customer, a line in the accounts, a payment link.

Most automations we build go through the same seven steps. The animation below shows them one at a time, each with its dictionary entry. On our site it's interactive: click a step to jump to it.

The seven entries, if you'd rather read than watch:

Step	On the tile	What it means
Webhook /ˈweb.hʊk/ noun	Trigger	An instant message one app sends another the moment something happens.
Validate /ˈvæl.ə.deɪt/ verb	Rules	To check every field is complete and correct before it moves on.
Transform /trænsˈfɔːrm/ verb	JavaScript	To reshape data with code so every tool speaks the same language.
Reason /ˈriː.zən/ verb	Claude	To let AI read, classify and decide what should happen next.
Store /stɔːr/ verb	Airtable	To save a clean record where your whole team can find it.
Notify /ˈnoʊ.tə.faɪ/ verb	Twilio	To reach your customer by SMS or WhatsApp, automatically.
Charge /tʃɑːrdʒ/ verb	Stripe	To take payment securely, without chasing a single invoice.

One message, followed from start to finish

Take the drawing and send a real message through it.

A buyer writes at ten in the evening: is the flat on Calle Mayor still available? WhatsApp passes the message on. The automation checks there's a number, a message and a listing it knows. The AI agent reads the question, sees it's about availability and a visit, and answers with the real price and the free slots. The contact is saved in the CRM with the conversation. The buyer picks Thursday at five, and the visit lands in the agent's calendar. If the agency takes a deposit, a payment link goes out.

The agent wakes up to a booked visit and a lead already filed. He did nothing. That's the whole point.

This one is an illustration, the same example our home page uses. The next three are real.

Three real ones

An accounting firm in Sydney. Each quarter, the accountant emails a client's spreadsheet to an address. Behind it, an n8n workflow reads every line, checks each figure against the accounting records, and sends the review back with every issue flagged. A full working day of review became a couple of minutes, and the firm measured over 70% less review time. The full story.

An online course with a paid community. Someone buys the course at two in the morning. Thirty seconds later they're in the Discord community with the right role, and nobody had to be awake for it. Two n8n workflows connect Stripe to Discord. The full story.

Three holiday apartments. A booking comes in. The door code is created on the lock for the right dates and emailed to the guest, and the monthly linen order writes itself from the real arrivals. The full story.

Different trades, same shape: something happens, a chain of small steps runs, and a person gets their evening back.

The tools that do it

There are two families. Platforms where you connect blocks on a screen, and code written for the job. Neither is better in general. Each is better for something.

Zapier is the easiest way in. It connects thousands of apps, and a simple chain is set up in an afternoon. You pay per task, though, so an automation that runs all day gets expensive quickly.

Make draws your automation as a scenario on a canvas, with branches and loops, and costs less than Zapier once the volume climbs. Large scenarios become hard to read if nobody keeps them tidy.

n8n is the one for serious workflows. It's open source, it can run on your own server, and when a block isn't enough you can drop a few lines of JavaScript or Python into any step. It runs the accounting and Discord projects above. The price of hosting it yourself is that someone has to keep it updated.

Gumloop is newer and built around AI from the start: reading documents, summarising, sorting, pulling data out of web pages. Worth a look when the AI step is the heart of the job. Check first that it connects to the tools you already use.

Node.js, .NET and Java come in when a platform stops being the right shape: high volume, sensitive data, rules too tangled for boxes and arrows, or an automation that has to live inside your own software. You own everything, including the maintenance. .NET is part of our core stack, for the systems that have to hold up under real load.

Our rule of thumb: start with the lightest tool that will still be right in a year, and move a step to code only when that step has earned it. Often the answer is a mix.

How we choose

The question is never which tool is best. It's which tool is right for this business, a year from now.

How often will it run? Ten times a day and ten thousand times a day don't produce the same bill. How sensitive is the data? Customer records and money sometimes have to stay on your own server. Who will look after it? If someone on your team will adjust it, a platform they can read beats code they can't. And what do you already use? The best automation fits around your tools instead of replacing them.

The part nobody draws

The drawing on the glass shows the day when everything goes right. The work is in all the other days.

An automation that crashes is fine. You see it, you fix it. The one that hurts keeps running and gets it slightly wrong, for months, without a word.

So ours follow a few dull rules. When the data is wrong, it stops and says so: it would rather do nothing than do it wrong. An odd case gets flagged instead of dropped, because an odd line gets noticed and a missing one doesn't. Anything that needs a human, an urgent message, a refund, an unhappy customer, goes to a person straight away. And every run leaves a trace, so when something unusual happens you can see exactly where and why.

Nobody draws those rules on the glass. They're the difference between an automation you forget about and one you check every morning.

If this sounds familiar

If there's something you do every week with your fingers crossed, copying, pasting, chasing, answering the same questions, tell us about it. We'll tell you honestly whether it's worth automating, and with what.

Originally published on wolfdevlabs.com, where the seven steps are interactive.

.NET, Polly, and 5 Other Microservices Liked This Post

Amine ABDALKHALKI — Mon, 07 Apr 2025 15:43:40 +0000

I remember the first time I deployed a suite of microservices into production (for a cashback company). Everything seemed to run smoothly until services started talking to each other in ways I never fully anticipated. One microservice would fail, causing a ripple effect of timeouts and errors across the entire system. The lesson? In a distributed world, every service is only as strong as its resilience strategy.

Enter Polly. Polly is the go-to .NET library for dealing with transient faults and unpredictable network issues challenges that are magnified in microservice architectures. Whether you’re calling a payment microservice, retrieving weather data for shipping cost estimates, or connecting to any external API, Polly ensures your calls can handle real-world chaos.

Visual Overview

Below is a simple conceptual diagram of how multiple microservices might interact with each other or external APIs, all protected by Polly’s resilience policies.

 ┌────────────────────┐       ┌───────────────────────┐
 │  .NET Microservice │       │ External REST Service │
 │ (e.g., Service A)  │  ---> │  (e.g., Weather API)  │
 │                    │       │                       │
 │     Polly Policies │       │  Potential Failures   │
 └────────────────────┘       └───────────────────────┘
         │
         │        ┌────────────────────┐
         │        │  .NET Microservice │
         └──────> │ (e.g., Service B)  │
                  │                    │
                  │     Polly Policies │
                  └────────────────────┘

Each microservice can independently configure Polly to handle retries, timeouts, circuit breakers, and more. That way, a failure in one service or an external API doesn’t bring down your entire ecosystem.

1. Start with the Right Building Blocks

Polly has evolved significantly and now comes in a modular v8+ form that integrates seamlessly with .NET 9 and beyond perfect for microservices, where you often need flexibility in how you plug into different services.

🛠️ Install the Essentials

dotnet add package Polly.Core
dotnet add package Microsoft.Extensions.Http.Resilience

Polly.Core: Core resilience components (retry, circuit breaker, timeout, etc.).
Microsoft.Extensions.Http.Resilience: Out-of-the-box integration with HttpClientFactory, making it straightforward to configure named clients.

Installing these packages allows each microservice to plug into smart policies helping the entire ecosystem handle transient errors gracefully.

2. Add Resilience to HTTP Clients Like a Pro

In a microservice architecture, it’s normal for services to make numerous HTTP calls to each other or to external APIs. Failures are inevitable: network splits, timeouts, 5xx errors, and more. Polly lets you define how each service should handle those failures.

In `Program.cs`, Hook Polly into an HTTP Client

builder.Services.AddHttpClient("WeatherApi")
    .AddStandardResilienceHandler(options =>
    {
        // Retry Strategy
        options.Retry.MaxRetryAttempts = 5;
        options.Retry.BackoffType = DelayBackoffType.Exponential;
        options.Retry.Delay = TimeSpan.FromSeconds(2);

        // Circuit Breaker
        options.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(30);
        options.CircuitBreaker.FailureRatio = 0.5;
    });

What’s Happening?

Retries up to 5 times when requests fail (like 500-series errors).
Exponential Backoff spreads out retries (2s, 4s, 8s…), reducing load on downstream services.
A Circuit Breaker monitors failures for 30 seconds; if more than 50% fail, it opens to block further calls temporarily (preventing a cascading meltdown).

Microservice Use Case

Order Service → Payment Service: If your payment provider has a momentary glitch, a retry might resolve a temporary outage without user impact.
Analytics Service → External APIs: If data ingestion fails occasionally, retries can stabilize the flow and avoid partial data loss.

3. Crafting Custom Pipelines (Precision for Critical Paths)

Not all microservices have the same reliability or latency requirements. Some need more granular control (e.g., immediate failover for user authentication, cautious retries for inventory checks).

Example: A Custom Policy with Retry, Timeout, and Circuit Breaker

builder.Services.AddResiliencePipeline("critical-pipeline", pipelineBuilder =>
{
    pipelineBuilder
        .AddRetry(new RetryStrategyOptions
        {
            MaxRetryAttempts = 3,
            Delay = TimeSpan.FromSeconds(1),
            BackoffType = DelayBackoffType.Exponential,
            ShouldHandle = new PredicateBuilder()
                .Handle<HttpRequestException>()
                .HandleResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)
        })
        .AddTimeout(TimeSpan.FromSeconds(10))
        .AddCircuitBreaker(new CircuitBreakerStrategyOptions
        {
            FailureRatio = 0.3,
            SamplingDuration = TimeSpan.FromSeconds(15),
            BreakDuration = TimeSpan.FromSeconds(30)
        });
});

Access this pipeline in your microservices via ResiliencePipelineProvider.

Key Concepts

ShouldHandle decides which scenarios to retry (e.g., a 500 server error or HttpRequestException).
Timeout: Prevents any request from hanging indefinitely, which is crucial in a microservice chain where a single stalled request can cascade into bigger issues.
Circuit Breaker: Protects your service from continuous failures that might overwhelm both the caller and the callee.

4. Advanced Resilience: Hedging & Fallbacks

If standard retries aren’t enough (for instance, if you have multi-regional endpoints or partial data that you can serve as a fallback), Polly also supports more advanced patterns.

Hedging: Race Two Requests, Pick the Fastest

builder.Services.AddHttpClient("HedgedWeatherClient")
    .AddStandardHedgingHandler();  // Parallel requests, returns first success

Microservice Example

If you host weather or user profile data in multiple regions, hedging can send requests to more than one region and return whichever responds first.

Fallback: Provide a Default Response if Everything Fails

var fallback = new ResiliencePipelineBuilder<HttpResponseMessage>()
    .AddFallback(new FallbackStrategyOptions<HttpResponseMessage>
    {
        ShouldHandle = new PredicateBuilder<HttpResponseMessage>()
            .HandleResult(r => r.StatusCode == HttpStatusCode.InternalServerError),
        FallbackAction = _ =>
            Outcome.FromResultAsValueTask(new HttpResponseMessage(HttpStatusCode.OK)
            {
                Content = new StringContent("Service unavailable, showing cached data.")
            })
    })
    .Build();

Fallback ensures your microservice returns a graceful response like cached data rather than just failing outright.

5. Best Practices: Building for Real-World Chaos

A few additional tips to make sure your microservices remain robust in production:

Idempotency ✅

Only retry operations that are safe. For instance, you don’t want to double-charge a user by retrying a payment without proper safeguards. Design your microservices so that critical operations either handle duplicates safely or use unique transaction IDs to prevent unwanted side effects.

Telemetry 📊

Hook Polly’s resilience data into your observability system whether that’s Serilog, Splunk, or Application Insights. Monitoring and alerting on retries and circuit-breaker activations helps you spot problems quickly in a distributed environment.

Add Jitter to Avoid Retry Storms 🎲

options.Retry.DelayGenerator = args =>
{
    var baseDelay = TimeSpan.FromSeconds(Math.Pow(2, args.AttemptNumber));
    var jitter = TimeSpan.FromMilliseconds(Random.Shared.Next(0, 500));
    return new ValueTask<TimeSpan?>(baseDelay + jitter);
};

Jitter helps microservices avoid synchronized retry storms, which can overwhelm a failing service and make outages even worse.

6. Test Like a Scientist

Polly is very test-friendly, allowing you to simulate different failure modes in each microservice before going live.

var pipeline = new ResiliencePipelineBuilder()
    .AddRetry()
    .Build();

var descriptor = pipeline.GetPipelineDescriptor();
Console.WriteLine($"Configured strategies: {string.Join(", ", descriptor.Strategies.Select(s => s.Name))}");

Check the configured strategies, verify retry logic, timeouts, and fallbacks ensuring each microservice is prepared for real-world stresses.

Additional Resources

Official Polly Docs: https://www.pollydocs.org
GitHub Samples: Polly-Samples

Summary: Why Polly Makes Your Microservices Bulletproof

Polly is more than just a retry helper it’s a toolkit for resilience in a microservice architecture. By mixing and matching Polly’s features, you ensure each microservice stands on its own when dealing with network hiccups or external service outages.

Feature	Benefit
Retry	Recover from transient faults automatically
Timeout	Prevent indefinite waiting
Circuit Breaker	Halt cascading failures and protect resources
Fallback	Deliver a graceful user experience under load
Hedging	Get the fastest response from multiple sources

Need help integrating Polly in your microservices or simulating edge cases? Feel free to reach out. Resilience is a journey especially in complex distributed systems and Polly ensures your services keep running even when the world doesn’t cooperate.

Ready to make your microservices truly bulletproof? Let’s do it together!