DEV Community: Onur Cinar

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

Onur Cinar — Sun, 12 Apr 2026 22:19:26 +0000

Claude’s "Dispatch" feature nailed the mobile-to-desktop UX. Being able to pull out your phone, delegate a heavy refactoring task to your local machine, and monitor its progress asynchronously is a massive quality-of-life upgrade.

But if your daily drivers are CLI-native AI tools like Gemini or OpenCode, you might feel locked out of that seamless remote workflow. Because these tools run in your terminal rather than a proprietary desktop app, they lack a native mobile bridge.

You don't have to abandon your favorite CLI tools to get that experience. By combining Tailscale and the modern terminal multiplexer Zellij, you can build a universal "Dispatch" layer.

The best part? You aren't just sending a fire-and-forget command. You get the exact same interactive, conversational experience on your phone as you do sitting at your mechanical keyboard.

Here is how to set up your own sovereign, mobile-to-local AI command center.

The Missing Link: Zellij Web + Tailscale

The core magic of Claude Dispatch is simply a secure, persistent, remotely accessible session. We can replicate this entirely using open-source infrastructure.

To bridge the gap between your smartphone browser and your local desktop terminal, we need two components:

Tailscale: This creates a secure overlay network. We will use Tailscale to safely pipe a local port out to your devices.
Zellij: This is the crucial piece. Zellij is a Rust-based terminal multiplexer with a robust Web Client. Unlike SSH apps, which can be clunky on mobile, Zellij renders a fully responsive terminal UI directly in your mobile browser.

Setting Up Your "Dispatch" Server

On your primary development machine—where your code, compilers, and AI tools live—you need to prepare the web session. Zellij takes privacy seriously, so the web client requires an authentication token and binds strictly to localhost by default.

1. Create the Authentication Token

Before starting the web UI, generate your secure login token:

zellij web --create-token

Make sure to copy and save the outputted token. You will need it to authenticate when you connect from your smartphone.

2. Start the Zellij Web Server

Next, start the web server and specify the port you want to use:

zellij web --port 4000

3. Expose the Port via Tailscale

Because Zellij is safely listening only on localhost, you cannot reach it from your phone yet. Instead of exposing this to the public internet, we use Tailscale Serve to proxy that local port exclusively to your private Tailnet.

Run this in a new terminal tab:

tailscale serve --bg --https=4000 localhost:4000

The Remote Workflow in Action

The real power of this setup is the seamless handoff. You don't need to craft complex, single-shot prompt strings. The interaction is identical to typing directly into your desktop CLI.

Imagine you are deep into building a Go project. You are sitting at your desk, iterating on some validation logic with OpenCode or Gemini open in your terminal. You realize you need to leave the house, but the task isn't done.

Here is how the dispatch workflow plays out:

1. The Mobile Handoff

While waiting in line for coffee, you open Chrome or Safari on your phone and navigate to your Tailscale URL (https://my-dev-box.domain.ts.net:4000).

After pasting in your authentication token, you are instantly dropped right back into your active desktop terminal. You see the exact same interactive AI prompt you were looking at on your monitor moments ago.

2. Chat and Dispatch

Because you are in a live, interactive session, you just talk to the CLI naturally. You type into your phone:

"I need to head out for a bit. Can you run the tests for the checker package, figure out why the struct validation is failing, and apply the fix?"

The AI acknowledges the request and begins its loop—reading your local files, executing go test, and analyzing the output.

3. Detach and Walk Away

This is the "Dispatch" moment. You simply close your mobile browser tab and put your phone in your pocket.

Because Zellij is managing the session natively on your local hardware, the AI continues to run uninterrupted. It has full access to your local environment to do the heavy lifting.

4. Asynchronous Monitoring

Check back 20 minutes later. Reopen the URL on your phone, and your terminal state is exactly how you left it.

If the AI successfully refactored the code and the tests are green, the output is waiting for you. If it ran into a file-permission error, or if OpenCode paused to ask, "Do you want me to commit these changes?", the interactive prompt is right there in your mobile browser, patiently waiting for your reply.

5. The Seamless Return to Desktop

When you finally get back home, the magic of Zellij really shines. You don't have to sync anything, pull down remote cloud changes, or wonder what the AI did while you were gone. You simply sit down at your physical monitor, attach to the running Zellij session, and pick up exactly where you left off. The AI's responses, the shell history, and the code changes are all right there waiting for you.

Why This Approach Scales

Retrofitting your existing AI workflow with Zellij and Tailscale doesn't just mimic Claude Dispatch; it arguably surpasses it for power users.

Agnostic Architecture: You aren't locked into one provider's ecosystem. You can use this exact workflow for Gemini, OpenCode, or any future terminal-based AI.
Frictionless UI: You don't need a dedicated mobile app or complex SSH key management on your phone. Any modern web browser becomes a window into your live terminal.
Unrestricted Environment: Your AI operates natively. It has full, unrestricted access to your actual development environment—your local databases, Docker containers, and raw file system—without needing to sync cloud workspaces.

By adding this networking layer, you transform your standard interactive CLIs from desktop-bound tools into true asynchronous agents that travel with you, keeping you in the loop wherever you are.

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

Onur Cinar — Sun, 12 Apr 2026 16:00:00 +0000

Not all traffic is created equal. When your system is under heavy load, should a background cleanup task compete for the same resources as a user's checkout request?

In a standard bulkhead, the answer is often "yes"—the first 10 requests get in, and the 11th is rejected, regardless of its importance. This is where Priority-Aware Bulkheads come in.

The Problem: The "Fairness" Trap

Standard bulkheads are fair. They treat every request the same. But in a real-world system, fairness can be a liability:

Critical Traffic: User-facing requests (e.g., "Complete Purchase", "Login") that directly impact revenue or user experience.
Standard Traffic: Regular API calls (e.g., "View Profile", "Search") that are important but not immediately critical.
Low-Priority Traffic: Background tasks (e.g., "Generate Report", "Sync Analytics", "Cache Warming") that can be delayed or retried later.

When your system is at 90% capacity, you want to stop accepting "Generate Report" requests to ensure there's enough room for "Complete Purchase" calls. A standard bulkhead can't do this; it will fill up with whatever arrives first.

The Solution: Priority-Aware Bulkheads

A Priority-Aware Bulkhead uses Load Shedding based on priority levels. It defines utilization thresholds for different types of traffic.

For example:

Low Priority: Allowed only if the bulkhead is less than 50% full.
Standard Priority: Allowed only if the bulkhead is less than 80% full.
Critical Priority: Allowed until the bulkhead is 100% full.

This ensures that your most important traffic always has a "buffer" of capacity reserved for it, even when the system is under significant pressure.

Implementing with Resile

Resile provides a built-in PriorityBulkhead that makes this pattern easy to implement.

1. Define Your Priorities

Resile uses a simple Priority type with three levels: PriorityLow, PriorityStandard, and PriorityCritical.

thresholds := map[resile.Priority]float64{
    resile.PriorityLow:      0.5, // Shed at 50% utilization
    resile.PriorityStandard: 0.8, // Shed at 80% utilization
    resile.PriorityCritical: 1.0, // Shed only when 100% full
}

// Create a bulkhead with a capacity of 20
pb := resile.NewPriorityBulkhead(20, thresholds)

2. Attach Priority to Context

You communicate the importance of a request by attaching a priority to its context.Context.

// Create a context with Critical priority
ctx := resile.WithPriority(context.Background(), resile.PriorityCritical)

// Execute the action within the priority bulkhead
err := pb.Execute(ctx, func() error {
    return processOrder()
})

3. Handle Shedded Load

When a request is rejected because its priority threshold is exceeded, Resile returns resile.ErrShedLoad. If the bulkhead is physically full (100% capacity), it returns resile.ErrBulkheadFull.

if errors.Is(err, resile.ErrShedLoad) {
    // This low/standard priority request was shedded to save capacity 
    // for higher-priority traffic.
}

Why Use Priority-Aware Bulkheads?

Protect the Critical Path: Ensure that your most important business processes remain available even during traffic spikes.
Graceful Degradation: Instead of a total system failure, your service gracefully degrades by dropping non-essential background work first.
Better User Experience: Users performing critical actions see no slowdown, while background "noise" is managed behind the scenes.
Cost Efficiency: You don't need to over-provision your infrastructure to handle peak "background" load if you can simply shed it when necessary.

Comparison: Static vs. Priority vs. Adaptive

Feature	Static Bulkhead	Priority-Aware Bulkhead	Adaptive Concurrency
Limit Type	Fixed (e.g., 20)	Fixed + Thresholds	Dynamic (Auto-tuned)
Traffic Awareness	None (All equal)	High (Priority-based)	None (All equal)
Best For	Simple isolation	Multi-tenant or Tiered apps	Volatile environments

Conclusion

Resilience isn't just about keeping the lights on; it's about keeping the right lights on. Priority-Aware Bulkheads give you the surgical precision needed to manage your system's resources effectively during times of stress.

Check out the full example: Priority Bulkhead Example

Learn more about Resile: github.com/cinar/resile

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

Onur Cinar — Sat, 11 Apr 2026 15:43:15 +0000

Imagine a common scenario in a microservice architecture: A user clicks a "Buy" button, triggering a request to Service A. Service A calls Service B, which in turn calls Service C.

Suddenly, Service A times out. The user sees an error message and refreshes the page. But Service B and Service C are still working on the original request, consuming CPU, memory, and database connections for a result that will never be seen.

These are Zombie Requests. In a high-traffic system, they can lead to cascading failures and resource exhaustion, even if the underlying services are technically "healthy."

To stop the zombies, you need Distributed Deadline Propagation. Here is how to implement it effortlessly using Resile.

What is Distributed Deadline Propagation?

Deadlines are not just local timeouts. A deadline represents the absolute point in time after which the entire request chain should be abandoned.

Distributed Deadline Propagation is the process of:

Tracking the remaining time (the "budget") as a request moves through the system.
Communicating that budget to downstream services via metadata (like HTTP headers).
Aborting early if the remaining budget is too small to realistically complete the work.

The Resile Way: Smart Deadlines

Resile provides two powerful mechanisms to handle distributed deadlines: Early Abort and Header Injection.

1. Early Abort: `WithMinDeadlineThreshold`

Why start a request if you only have 2 milliseconds left? The network latency alone will likely exceed that, and you'll just be wasting resources.

Resile's WithMinDeadlineThreshold allows you to define a "safety buffer." If the remaining time in the context.Context is less than this threshold, Resile will abort the execution immediately with a context.DeadlineExceeded error, before even attempting the work.

import (
    "context"
    "time"
    "github.com/cinar/resile"
)

// Define a policy with a 10ms "Early Abort" threshold.
policy := resile.NewPolicy(
    resile.WithRetry(3),
    resile.WithMinDeadlineThreshold(10 * time.Millisecond),
)

// If ctx has only 5ms left, this returns context.DeadlineExceeded instantly.
result, err := policy.Do(ctx, func(ctx context.Context) (string, error) {
    return apiClient.FetchData(ctx)
})

2. Header Injection: `InjectDeadlineHeader`

To propagate the deadline to downstream services, you need to "inject" the remaining time into your outgoing requests. Resile provides a transport-agnostic InjectDeadlineHeader function that supports both standard HTTP and gRPC.

For REST/HTTP:

You can inject the remaining milliseconds into a custom header (e.g., X-Request-Timeout).

func (c *Client) FetchData(ctx context.Context) (string, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", "http://service-b/data", nil)

    // Inject the remaining milliseconds into the header.
    resile.InjectDeadlineHeader(ctx, req.Header, "X-Request-Timeout")

    resp, err := c.httpClient.Do(req)
    // ...
}

For gRPC:

Resile natively supports the standard Grpc-Timeout header format, ensuring compatibility with the gRPC ecosystem.

func (c *Client) FetchData(ctx context.Context) (string, error) {
    md := metadata.New(map[string]string{})

    // Inject using the gRPC-specific format (e.g., "100m" for 100ms).
    resile.InjectDeadlineHeader(ctx, md, "Grpc-Timeout")

    ctx = metadata.NewOutgoingContext(ctx, md)
    return c.grpcClient.GetData(ctx, &pb.Request{})
}

Why This Matters for Resilience

Without distributed deadlines, your system is vulnerable to Resource Exhaustion Attacks—not from malicious actors, but from your own retries and slow dependencies.

By implementing propagation:

You save money: You're not paying for cloud compute that produces "zombie" results.
You prevent meltdowns: Downstream services are protected from "retry storms" that they can't possibly satisfy in time.
You improve UX: Failures happen faster (Fail-Fast), allowing the UI to react or switch to a fallback immediately.

Comparison: Static vs. Distributed Deadlines

Feature	Static Timeouts	Distributed Deadlines (Resile)
Scope	Single Service	Entire Request Chain
Awareness	Blind to upstream delays	Aware of the total "time budget"
Efficiency	High waste (Zombie requests)	Zero waste (Early Abort)
Protocol	Internal only	HTTP/gRPC compatible

Conclusion

Resilience isn't just about making things "work"; it's about knowing when to stop working.

Distributed Deadline Propagation is the "social contract" of a microservice architecture. It ensures that every service in the chain is working towards a common goal—and respects the reality that sometimes, time simply runs out.

With Resile, implementing this complex pattern becomes a matter of a few lines of configuration.

Explore Resile on GitHub: github.com/cinar/resile

How are you handling request budgets in your distributed systems? Let's discuss!

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

Onur Cinar — Fri, 03 Apr 2026 14:51:48 +0000

You’ve implemented retries, circuit breakers, and timeouts. Your application is now "resilient." But how do you know these policies actually work? Waiting for a production meltdown to verify your configuration is a high-stakes gamble.

Native Chaos Engineering in Resile allows you to synthetically induce failure and latency directly into your application's execution path, ensuring your resilience policies are battle-tested before they're ever needed in production.

The Problem: "Dark Code" in Resilience Policies

Resilience policies—like retries and circuit breakers—are often "dark code." These are execution paths that are rarely traversed under normal operating conditions. Because they only trigger during failure, they are notoriously difficult to test and prone to:

Buggy Configurations: A retry limit that is too high, or a circuit breaker threshold that never trips.
Unintended Side Effects: A retry loop that accidentally consumes all available database connections.
Silent Failures: A fallback strategy that actually panics because it hasn't been executed in months.

Traditional chaos engineering tools often operate at the infrastructure layer (e.g., killing pods or dropping network packets). While powerful, these tools can be difficult to set up in local development or staging environments and often lack the granularity to test specific application-level logic.

The Solution: Fault & Latency Injection

Resile provides a Chaos Injector middleware that can be integrated directly into any execution policy. By injecting synthetic faults (errors) and latency (delays) with configurable probabilities, you can simulate various failure scenarios without touching your infrastructure.

Key Features:

Deterministic Randomness: Uses Go 1.22's math/rand/v2 for efficient and predictable random number generation.
Context-Aware: Latency injection strictly respects context.Context cancellation. If your request times out while Resile is injecting chaos latency, it exits immediately.
Zero Dependencies: Just like the rest of the Resile core, the chaos package depends only on the Go standard library.
Granular Control: Configure error and latency probabilities independently for fine-tuned simulation.

Practical Usage

Integrating chaos into your existing Resile policies is as simple as adding the WithChaos option.

1. Basic Chaos Configuration

You can define a chaos configuration that injects a 10% error rate and adds 100ms of latency to 20% of requests.

import (
    "github.com/cinar/resile"
    "github.com/cinar/resile/chaos"
)

// Configure chaos injection
cfg := chaos.Config{
    ErrorProbability:   0.1,                    // 10% chance of failure
    InjectedError:      errors.New("chaos!"),   // The error to return
    LatencyProbability: 0.2,                    // 20% chance of latency
    LatencyDuration:    100 * time.Millisecond, // Delay to inject
}

// Apply it to an execution
err := resile.DoErr(ctx, action, 
    resile.WithRetry(3),
    resile.WithChaos(cfg),
)

2. Testing Your Circuit Breaker

Chaos injection is exceptionally useful for verifying that your circuit breaker trips under pressure. By setting a high ErrorProbability, you can force the breaker to transition from Closed to Open in a controlled environment.

cb := circuit.New(circuit.Config{
    WindowSize:           10,
    FailureRateThreshold: 50.0,
})

// Force 80% error rate to trip the breaker quickly
cfg := chaos.Config{
    ErrorProbability: 0.8,
    InjectedError:    errors.New("synthetic failure"),
}

for i := 0; i < 20; i++ {
    resile.DoErr(ctx, action, 
        resile.WithCircuitBreaker(cb),
        resile.WithChaos(cfg),
    )
}

fmt.Printf("Circuit Breaker State: %v\n", cb.State()) // Should be Open

Configuration Reference

The chaos.Config struct provides the following options:

Field	Type	Description
`ErrorProbability`	`float64`	The probability of injecting an error (0.0 to 1.0).
`InjectedError`	`error`	The error to be returned when an error is injected.
`LatencyProbability`	`float64`	The probability of injecting latency (0.0 to 1.0).
`LatencyDuration`	`time.Duration`	The duration of the latency to be injected.

Best Practices

Environment Gating: Never enable chaos injection in production unless you are performing a planned game day. Use environment variables to gate the configuration:
```
if os.Getenv("ENABLE_CHAOS") == "true" {
    opts = append(opts, resile.WithChaos(loadChaosCfg()))
}
```
Observability: Ensure your Instrumenter (like slog or OTel) is active. This allows you to see the injected errors and latencies in your logs and traces, making it easier to verify how your application responds.
Start Small: Begin with low probabilities (e.g., 1-2%) to identify subtle race conditions or timeout issues before increasing the "blast radius."

Conclusion

Resilience is not a "set it and forget it" feature. It requires continuous verification. By bringing chaos engineering directly into your application's execution policies, Resile empowers you to build systems that aren't just theoretically resilient, but practically battle-hardened.

For more information and advanced usage, visit the github.com/cinar/resile project.

Beyond Static Limits: Adaptive Concurrency with TCP-Vegas in Go

Onur Cinar — Thu, 02 Apr 2026 19:11:51 +0000

Traditional concurrency limits (like bulkheads) are static. You pick a number—say, 10 concurrent requests— and hope for the best. But in the dynamic world of cloud infrastructure, "10" might be too conservative when the network is fast, or dangerously high when a downstream service starts to queue.

Static limits require manual tuning, which is often done after an outage has already happened. To build truly resilient systems, we need Adaptive Concurrency Control.

Here is how to implement dynamic concurrency limits in Go using Resile, inspired by the TCP-Vegas congestion control algorithm.

The Problem: The "Fixed-Limit" Trap

Imagine your service talks to a database. You've set a bulkhead limit of 50 concurrent connections.

Scenario A (Normal): Database latency is 10ms. 50 concurrent requests mean you're handling 5,000 RPS. Everything is fine.
Scenario B (Degraded): Database latency spikes to 500ms due to a background maintenance task. Your 50 "slots" are now filled with slow requests. Your throughput drops to 100 RPS, and new incoming requests start to pile up in your own service's memory, eventually leading to a cascade of failures.

In Scenario B, 50 is too many. You're holding onto resources that are essentially waiting on a bottleneck. You should have reduced your concurrency limit to prevent your own service from becoming part of the problem.

The Solution: Little's Law & TCP-Vegas

Adaptive Concurrency uses two core principles:

Little's Law (L = λW): The number of items in a system (L) is equal to the arrival rate (λ) multiplied by the average time an item spends in the system (W).
TCP-Vegas AIMD: An Additive Increase, Multiplicative Decrease (AIMD) logic based on Round-Trip Time (RTT).

How it works:

Baseline: The algorithm tracks the minimum RTT (the fastest the system can possibly go).
Additive Increase: If current latency is close to the baseline (no queuing detected), it cautiously increases the concurrency limit by 1.
Multiplicative Decrease: If latency spikes above a threshold (e.g., 1.5 x baseline), it assumes queuing is happening downstream and immediately slashes the concurrency limit by 20%.

This allows your service to automatically "breathe" with the network. It expands to use available capacity when things are fast and contracts instantly to protect itself when things slow down.

Implementing with Resile

Resile makes it trivial to add adaptive concurrency to your Go services.

// 1. Create a shared AdaptiveLimiter.
// This should be shared across multiple calls to the same resource.
al := resile.NewAdaptiveLimiter()

// 2. Use it in your policy.
p := resile.NewPolicy(
    resile.WithAdaptiveLimiterInstance(al),
)

// 3. Execute your action.
err := p.DoErr(ctx, func(ctx context.Context) error {
    return callDownstreamService()
})

if errors.Is(err, resile.ErrShedLoad) {
    // The limiter has dynamically reduced the limit and shed this request
    // to protect the system.
}

Why "TCP-Vegas"?

Unlike other congestion control algorithms (like TCP-Reno) that wait for packet loss to react, TCP-Vegas reacts to latency changes. This is perfect for microservices where "packet loss" usually means a timed-out request or a 503 error—both of which we want to avoid before they happen.

Zero-Configuration Resilience

One of the biggest benefits of Adaptive Concurrency is that it requires zero manual configuration. You don't need to know if your database can handle 50 or 500 connections. The AdaptiveLimiter will discover the optimal limit in real-time.

It even handles "Network Drift." Over time, the minimum baseline RTT is gradually decayed, allowing the system to recalibrate if you migrate your database to a faster region or if the network topology changes.

Conclusion

Resilience isn't just about surviving failures; it's about adapting to them. By moving from static bulkheads to adaptive concurrency, you're building a system that can intelligently protect itself from cascading failures while maximizing throughput during "peace time."

Check out the Adaptive Concurrency Example in the Resile repository to see it in action.

Respecting Boundaries: Precise Rate Limiting in Go

Onur Cinar — Tue, 24 Mar 2026 13:00:00 +0000

Traffic spikes are a double-edged sword. On one hand, you’re busy! On the other, those spikes can overwhelm your services or exceed your downstream quotas.

Whether you're protecting your own database from an unexpected burst or respecting a third-party API’s strict 100 requests-per-second (RPS) limit, you need a precise way to shape your traffic.

Enter the Token Bucket Rate Limiter in Resile.

The Problem: Unbounded Traffic

In a distributed environment, your clients don't know about each other. If 50 different microservice instances all decide to call a downstream API at the same time, the aggregate traffic can easily exceed the capacity of the target system.

When you exceed these limits, you'll often see:

HTTP 429 (Too Many Requests): Downstream services start rejecting you.
Cascading Latency: The target system slows down for everyone because it's processing too many requests at once.
Cost Overruns: Many cloud providers and SaaS APIs charge significant premiums for exceeding agreed-upon quotas.

The Solution: The Token Bucket Algorithm

The Token Bucket is a classic algorithm used for traffic shaping.

Imagine a bucket that refills with "tokens" at a constant rate (e.g., 100 tokens per second). Every request must consume a token from the bucket. If the bucket is empty, the request is rejected immediately. This allows for small "bursts" (filling the bucket) while maintaining a precise long-term average rate.

Implementing with Resile:

Resile makes adding rate limiting to your executions simple.

// Allow 100 requests per second.
// If the limit is exceeded, it fails fast with resile.ErrRateLimitExceeded.
err := resile.DoErr(ctx, action, 
    resile.WithRateLimiter(100, time.Second),
)

Rate Limiting vs. Adaptive Retries

Wait, doesn't Resile already have AdaptiveBucket? What's the difference?

AdaptiveBucket is success-based. It tracks how many requests are succeeding vs. failing and throttles retries accordingly. It's designed specifically to prevent "retry storms" when a service is failing.
RateLimiter is time-based. It enforces a strict, constant quota of requests over a time interval. It’s designed for general traffic shaping and quota management.

For maximum protection, you can even use them together!

Shared Rate Limiters

Often, you want to enforce a global rate limit across your entire service instance. You can create a shared RateLimiter and pass it to multiple executions:

// Shared rate limiter for a specific API key or downstream service
limiter := resile.NewRateLimiter(50, time.Second)

// Each call will consume tokens from the same shared bucket.
err := resile.DoErr(ctx, myAction, 
    resile.WithRateLimiterInstance(limiter),
)

Observability: Seeing the Shaping

Knowing when and why your traffic is being throttled is essential for operational visibility.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic visibility into these events. The OnRateLimitExceeded event is triggered whenever a request is rejected by the rate limiter, allowing you to monitor your quota utilization in real-time.

Conclusion

Rate limiting is not just about saying "no"; it's about being a good citizen in a distributed ecosystem. By respecting boundaries and shaping your traffic at the source, you protect both your own service and the systems you depend on.

Resile provides a production-grade rate limiter that integrates seamlessly into your resilience policies, giving you fine-grained control over your traffic flow.

Learn more about Resile: github.com/cinar/resile

Stop the Domino Effect: Bulkhead Isolation in Go

Onur Cinar — Sun, 22 Mar 2026 17:42:19 +0000

In a distributed system, failure is inevitable. But a failure in one part of your system shouldn't bring down everything else.

Imagine your Go service depends on three different downstream APIs: Payments, Inventory, and Recommendations. Suddenly, the Recommendations API starts taking 30 seconds to respond. If your service doesn't have isolation, your goroutines will start piling up waiting for Recommendations. Eventually, you'll hit your process limit, and even the critical Payments API calls will start failing because there are no resources left to handle them.

This is the Domino Effect, and the Bulkhead Pattern is how you stop it.

The Problem: Resource Exhaustion

When one dependency slows down, it consumes resources:

Goroutines: Blocked waiting for a response.
Memory: Each blocked goroutine carries a stack.
File Descriptors/Sockets: Open connections to the slow service.

Without a bulkhead, a single slow dependency can "starve" the rest of your application, leading to a total system collapse.

The Solution: The Bulkhead Pattern

Named after the partitioned sections of a ship's hull, a Bulkhead isolates failures. If one section of the ship is flooded, the others remain buoyant. In software, we achieve this by limiting the number of concurrent executions allowed for a specific resource or dependency.

Implementing with Resile:

Resile makes it trivial to add bulkhead isolation to any operation.

// Allow only 10 concurrent calls to this specific operation.
// If an 11th call comes in, it fails fast with resile.ErrBulkheadFull.
err := resile.DoErr(ctx, action, 
    resile.WithBulkhead(10),
)

Using a Shared Bulkhead

Often, you want to limit concurrency across multiple different call sites that hit the same downstream service. You can create a shared Bulkhead instance for this:

// Create a shared bulkhead for the "Inventory Service"
inventoryBulkhead := resile.NewBulkhead(20)

// Call Site A
resile.DoErr(ctx, fetchItem, resile.WithBulkheadInstance(inventoryBulkhead))

// Call Site B
resile.DoErr(ctx, updateStock, resile.WithBulkheadInstance(inventoryBulkhead))

By sharing the instance, you ensure that the total concurrency hitting the Inventory Service never exceeds 20, regardless of which part of your code is making the call.

Why "Fail-Fast" Matters

When a bulkhead is full, Resile immediately returns resile.ErrBulkheadFull.

This is much better than waiting for a timeout. By failing fast, you:

Preserve Resources: You don't spawn another goroutine or open another connection.
Provide Immediate Feedback: Your upstream callers get an error instantly and can decide how to handle it (e.g., show a cached result or a "service busy" message).

Observability: Monitoring the Walls

You need to know when your bulkheads are working. If a bulkhead is frequently full, it might mean your downstream service is struggling, or you need to re-evaluate your capacity limits.

If you use Resile's telemetry integrations (like slog or OpenTelemetry), you'll get automatic alerts when a bulkhead saturates. The OnBulkheadFull event is triggered every time a request is rejected due to capacity limits.

Conclusion

Bulkheads are a fundamental building block of resilient systems. By isolating your dependencies, you ensure that a local fire doesn't become a global conflagration.

Resile provides a clean, "Go-native" way to implement bulkheads without complex boilerplate, allowing you to focus on your business logic while keeping your system stable.

Explore Resile on GitHub: github.com/cinar/resile

Infinite Data Processing in Go: Building Resilient Data Pipes with Channels

Onur Cinar — Wed, 18 Mar 2026 16:00:00 +0000

When building data-intensive applications, we usually start with the most obvious approach: loading data into a slice or array, iterating over it to process the data, and returning the result. This batch-processing mindset works great—until the data never stops coming.

Whether you are dealing with live IoT telemetry, continuous log tailing, or real-time financial market feeds, you quickly run into the problem of "infinite" data. If you try to append an endless stream of stock ticks to a []float64, your application will inevitably consume all available memory and crash.

To handle infinite data gracefully, you need to shift your architecture from batch processing to stream processing. In Go, we have the perfect built-in primitive for this: Channels.

The Power of Channels as Data Pipes

Go channels are often taught primarily as a way to synchronize goroutines, but they are also incredibly powerful as sequential data pipes. By treating channels as standard inputs and outputs, you can build decoupled, memory-efficient pipelines where data flows through a series of transformations continuously.

When redesigning my open-source technical analysis library, cinar/indicator, for its v2 release, I faced exactly this challenge. In algorithmic trading, systems need to react instantly to live market feeds without accumulating massive memory overhead. Transitioning the library's core architecture from slice-based arrays to stream-based Go channels solved this elegantly.

Let's look at how to build a continuous data pipe, and some of the tricky edge cases you'll encounter along the way.

Building a Pipeline Stage

Imagine we want to calculate a Simple Moving Average (SMA) over a live stream of data. Instead of taking a slice, our function will accept a read-only channel as its input and return a read-only channel as its output.

package main

import (
    "fmt"
)

// SimpleMovingAverage acts as a pipe: it reads from 'input', processes, and writes to 'output'
func SimpleMovingAverage(input <-chan float64, period int) <-chan float64 {
    output := make(chan float64)

    go func() {
        // Ensure the output channel is closed when the input stream ends
        defer close(output) 

        window := make([]float64, 0, period)
        sum := 0.0

        for val := range input {
            window = append(window, val)
            sum += val

            // Keep the window size fixed
            if len(window) > period {
                sum -= window[0]
                window = window[1:]
            }

            // Only emit a value once we have enough data points
            if len(window) == period {
                output <- sum / float64(period)
            }
        }
    }()

    return output
}

Because the processing happens inside its own goroutine, the function returns the output channel immediately. The goroutine stays alive, eagerly waiting for new data to arrive on the input channel.

Handling Stream Complexities with Helpers

Once you start relying heavily on channels, you run into a few structural challenges. To make working with channels just as easy as working with slices, cinar/indicator includes a robust helper package.

If you are building your own stream-based application, you can leverage these helpers directly from the library rather than reinventing the wheel.

1. The Branching Problem

A major gotcha with Go channels: once a value is read from a channel, it's gone. What if you want to calculate an SMA and a Relative Strength Index (RSI) from the exact same live price ticker? You can't have two consumers read from one channel without them stealing data from each other.

To solve this, the library provides helper.Duplicate. This function takes one input channel and "fans it out" into multiple identical output channels. This allows you to safely branch your data stream to multiple independent technical indicators simultaneously without race conditions or data loss.

// Branching one price stream into three identical streams
priceStreams := helper.Duplicate(livePrices, 3)

smaStream := indicator.SMA(priceStreams[0], 14)
rsiStream := indicator.RSI(priceStreams[1], 14)
macdStream := indicator.MACD(priceStreams[2], 12, 26, 9)

2. Lookbacks and Sliding Windows

Many data processing algorithms require looking back at the last N periods. Instead of managing a sliding window manually inside every single function (like we did in the basic SMA example above), the library uses helper.Buffered. This provides a clean abstraction to maintain a rolling state over a continuous channel, vastly simplifying the development of complex logic.

3. Bridging the Gap: Slices vs. Streams

The rest of the world often still speaks in batches. You might be downloading historical CSV data for backtesting, or you might need to output an array for a charting UI. To bridge this gap, the helper package includes utilities to fluidly move between paradigms:

helper.SliceToChan: Converts a static historical array into a simulated live data stream. It spins up a goroutine, pushes every element from the slice into a channel, and closes it. It's perfect for feeding historical backtests into a live-stream architecture.
helper.ChanToSlice: The inverse operation. It drains a stream back into an array, which is incredibly useful for writing unit tests or rendering charts.

Chaining the Pipes Together

Because all the indicators and helpers in cinar/indicator take channels and return channels, they are highly composable. We can chain them together like Unix command-line pipes (|).

Here is what it looks like to wire up an application using these concepts:

package main

import (
    "fmt"
    "[github.com/cinar/indicator/v2/helper](https://github.com/cinar/indicator/v2/helper)"
    "[github.com/cinar/indicator/v2/trend](https://github.com/cinar/indicator/v2/trend)"
)

func main() {
    // 1. We start with a static slice of historical data
    historicalPrices := []float64{10.0, 12.0, 14.0, 13.0, 15.0, 18.0, 19.0, 17.0}

    // 2. Bridge the gap: convert the slice to a live stream
    marketTicks := helper.SliceToChan(historicalPrices)

    // 3. Pipe the ticks into a 3-period SMA processor from the library
    smaStream := trend.Sma(marketTicks, 3)

    // 4. Drain the output stream 
    for avg := range smaStream {
        fmt.Printf("New SMA tick processed: %.2f\n", avg)
    }
}

Why This Architecture Wins

Memory Efficiency: We only store the exact amount of data needed at any given moment. The Go garbage collector easily cleans up the rest, meaning we can process a continuous websocket stream for months without memory leaks.
Backpressure Handling: Go channels are blocking by nature. If a complex compound strategy at the end of the pipeline is too slow, the channels will naturally fill up, pausing the producers further up the chain until it catches up.
Decoupling: Each pipeline stage is completely isolated. The indicator doesn't know if the data is coming from a historical Tiingo repository, an Alpaca websocket, or a mock unit test. It just reads from <-chan T and writes to <-chan T.

Try It Out

By treating channels as native data streams and relying on robust helper utilities, you can build highly resilient, concurrent pipelines capable of processing truly infinite data sets.

If you are building financial tools, real-time dashboards, or are just looking to explore a Go codebase that relies heavily on generics and channel-based streaming, I highly recommend leveraging the cinar/indicator library. It comes batteries-included with all the helpers and technical indicators you need to get started with stream processing in Go.

How are you handling continuous data streams in your applications? Let me know in the comments!

Self-Healing State Machines: Resilient State Transitions in Go

Onur Cinar — Mon, 16 Mar 2026 13:00:00 +0000

Distributed systems are inherently stateful. Whether you're managing a database connection pool, a multi-step payment workflow, or a complex IoT device lifecycle, you need to transition between states reliably.

Standard state machines (FSMs) are great for logic, but they are often brittle. What happens if a transition involves a network call that fails? Most developers end up wrapping their machine.Transition() calls in manual retry loops, cluttering their business logic and losing visibility into why a transition failed.

Inspired by Erlang's gen_statem behavior, Resile introduces resile.StateMachine: a standardized, resilient state machine where every transition is inherently protected by resilience policies.

The Resile Way: One-Line Resilience for Transitions

With resile.StateMachine, you don't just define how to move from State A to State B. You define a Resilient Transition.

Here is how you implement a self-healing connection manager:

import "github.com/cinar/resile"

// 1. Define your State, Data, and Events
type State string
const (
    Disconnected State = "Disconnected"
    Connected    State = "Connected"
)

type Event string
const (
    Connect Event = "Connect"
)

// 2. Define the Transition Logic
transition := func(ctx context.Context, state State, data Data, event Event, rs resile.RetryState) (State, Data, error) {
    if state == Disconnected && event == Connect {
        // This transition involves a network call.
        // If it fails, Resile will automatically retry it 
        // using the configured backoff and jitter.
        err := apiClient.Connect(ctx, data.Endpoint)
        if err != nil {
            return "", data, err
        }
        return Connected, data, nil
    }
    return state, data, nil
}

// 3. Initialize the Resilient State Machine
sm := resile.NewStateMachine(
    Disconnected, 
    Data{Endpoint: "api.example.com"}, 
    transition,
    resile.WithMaxAttempts(3),
    resile.WithBaseDelay(100 * time.Millisecond),
)

// 4. Handle events safely
err := sm.Handle(ctx, Connect)

What happens under the hood?

When you call sm.Handle(ctx, event), Resile enters a execution envelope.
It executes your transition function.
If the transition returns an error, Resile applies your retry policy (e.g., Exponential Backoff with Jitter).
Only when the transition succeeds does the StateMachine update its internal state and data.
If the retries are exhausted, the StateMachine remains in its previous state, ensuring consistency.

Why "Self-Healing"?

Most state machine implementations are "fire and forget" or "fail and stop." A Self-Healing state machine assumes that transitions are risky and provides the infrastructure to recover from those risks automatically.

Automatic Retries: No more manual loops inside your state logic.
Circuit Breakers: If a specific transition (e.g., to a "Maintenance" state) is failing repeatedly, the circuit breaker can trip to prevent overwhelming the system.
Context Awareness: If the transition is part of a timed-out request, the state machine cancels the transition attempt immediately, preventing goroutine leaks.
Observability: Every transition attempt—including retries—is tracked by Resile's telemetry hooks. You can see exactly how many times your machine "struggled" to reach the Connected state.

Observability: Tracking State Success

By using Resile's OpenTelemetry or slog integrations, you get deep insights into your state machine's health:

Attempts per Transition: See which events are causing the most retries.
Transition Latency: Measure how long it takes to move from one state to another, including backoff time.
Failure Patterns: Identify if a specific state is a "dead end" due to persistent errors.

Conclusion

Resilience isn't just for simple API calls. By bringing resilience to the core of your stateful logic, you build systems that are not only more robust but also significantly easier to debug and monitor.

Stop writing manual retry loops around your state changes. Let resile.StateMachine handle the complexity of the "unreliable world" while you focus on the logic of your application.

Give Resile a star on GitHub: github.com/cinar/resile

How are you managing state transitions in your Go microservices? Let's discuss!

Preventing Microservice Meltdowns: Adaptive Retries and Circuit Breakers in Go

Onur Cinar — Sun, 15 Mar 2026 22:28:33 +0000

We’ve all been there. A downstream database has a momentary blip. Your service instances, being "resilient," immediately start retrying their failed requests.

Suddenly, the database isn't just "having a blip" anymore—it’s being hammered by a self-inflicted DDoS attack from its own clients. This is the Retry Storm (or Thundering Herd), and it’s one of the most common ways distributed systems experience total meltdowns.

Standard exponential backoff protects individual services, but it doesn't protect the cluster. To do that, you need a layered defense-in-depth approach.

Here is how to prevent microservice meltdowns in Go using Resile.

The Problem: Aggregate Load

Imagine you have 100 instances of your API. Each instance is configured to retry 3 times. If the database slows down, you suddenly have 300 extra requests hitting it exactly when it's struggling to recover.

Even with jitter, the aggregate load can be enough to keep the database in a "failed" state indefinitely. To solve this, we need two patterns working together: Adaptive Retries and Circuit Breakers.

1. Adaptive Retries (The Token Bucket)

Inspired by Google's SRE book and AWS SDKs, Adaptive Retries use a client-side token bucket to "fail fast" locally.

The logic is simple:

Every success adds a small amount of "credit" to your bucket.
Every retry consumes a significant amount of credit.
If the bucket is empty, Resile stops retrying immediately and fails fast locally.

This ensures that if a downstream service is fundamentally degraded, your fleet of clients will automatically throttle their retry pressure at the source, giving the service breathing room to recover.

Implementing with Resile:

// Share this bucket across multiple executions or even your entire service
bucket := resile.DefaultAdaptiveBucket()

err := resile.DoErr(ctx, action, 
    resile.WithAdaptiveBucket(bucket),
)

2. Circuit Breakers (The Kill Switch)

While retries assume "eventual success," a Circuit Breaker assumes "statistical failure."

If a service fails 5 times in a row, the breaker "trips" (opens). For the next 30 seconds, every call to that service will fail instantly without even trying to hit the network. This protects your downstream infrastructure from useless traffic and saves your local resources (threads, memory, sockets).

Layering it in Resile:

import "github.com/cinar/resile/circuit"

// Create a breaker: Trip after 5 failures, wait 30s to retry
cb := circuit.New(circuit.Config{
    FailureThreshold: 5,
    ResetTimeout:     30 * time.Second,
})

err := resile.DoErr(ctx, action, 
    resile.WithCircuitBreaker(cb),
)

The Ultimate Defense: Layered Resilience

The real power of Resile comes from combining these patterns. You can layer Retries, Circuit Breakers, and Adaptive Buckets into a single execution strategy.

err := resile.DoErr(ctx, action,
    resile.WithMaxAttempts(3),           // Layer 1: Handle random blips
    resile.WithCircuitBreaker(cb),      // Layer 2: Stop hitting a dead service
    resile.WithAdaptiveBucket(bucket),  // Layer 3: Prevent cluster-wide storms
)

In this setup:

Retries handle the "one-off" network glitches.
The Circuit Breaker stops you from wasting time on a service that is clearly down.
The Adaptive Bucket ensures that even if the breaker hasn't tripped yet, you won't overwhelm the system with aggregate retry load.

Observability: Seeing the Shield in Action

Protecting your system is great, but knowing you’re being protected is better.

If you use Resile's slog or OpenTelemetry integrations, you'll see exactly when these shields activate. Your logs will show retry.throlled=true when the adaptive bucket kicks in, or your traces will show a circuit.open error when the breaker prevents a call.

This visibility is crucial for SREs to understand why traffic is failing and how the system is self-healing.

Conclusion

Building resilient microservices isn't just about making individual calls "smarter." It's about ensuring that your entire architecture can survive a storm without collapsing under its own weight.

By combining opinionated retries, circuit breakers, and adaptive throttling, Resile gives you a production-grade resilience engine that scales with your infrastructure.

Try Resile today: github.com/cinar/resile

How do you prevent "retry storms" in your Go clusters? Let's discuss in the comments!

Beating Tail Latency: A Guide to Request Hedging in Go Microservices

Onur Cinar — Sat, 14 Mar 2026 03:03:35 +0000

In distributed systems, we often talk about "The Long Tail."

You might have a service where 95% of requests finish in under 100ms. But that last 1% (the P99 latency)? Those requests might take 2 seconds or more. In a microservice architecture where one user action triggers 10 different service calls, that one slow dependency will bottleneck the entire user experience.

Standard retries don't help here. Why? Because a "Tail Latency" request hasn't failed yet—it’s just slow.

Waiting for a 2-second timeout to trigger a retry is a waste of time. To beat the long tail, you need Request Hedging (also known as Speculative Retries).

Here is how to implement it safely in Go using Resile.

What is Request Hedging?

The concept is simple but powerful: If a request is taking longer than usual (say, longer than the P95 latency), don't kill it. Instead, start a second, identical request in parallel.

Whichever request finishes first, you take its result and cancel the other one.

This "speculative" approach drastically reduces P99 latency because the mathematical probability of two identical requests hitting the "long tail" simultaneously is extremely low.

The Complexity of Manual Hedging

Implementing hedging manually in Go is a nightmare of goroutine management:

You need a select block with a timer.
You need to coordinate between two (or more) goroutines.
You must ensure that once one succeeds, the others are cancelled immediately to save resources.
You have to handle race conditions where both might succeed at the exact same millisecond.

Most developers end up with hundreds of lines of brittle boilerplate code to handle just one hedged call.

The Resile Way: `DoHedged`

Resile makes request hedging as simple as a single function call. It handles the goroutine lifecycle, context cancellation, and race conditions for you.

Here is how you fetch data with a 100ms hedging delay:

import "github.com/cinar/resile"

// data is automatically inferred as *User
data, err := resile.DoHedged(ctx, func(ctx context.Context) (*User, error) {
    return apiClient.GetUser(ctx, userID)
}, 
    resile.WithMaxAttempts(3),
    resile.WithHedgingDelay(100 * time.Millisecond),
)

What happens under the hood?

Resile starts the first request.
It waits for 100ms (HedgingDelay).
If the first request hasn't finished, it starts a second request.
As soon as one returns a successful result, Resile cancels the context of the other request and returns the data to you.

Picking the Right Hedging Delay

The "magic" of hedging lies in the delay.

Too short: You double your traffic unnecessarily, putting extra load on your downstream services.
Too long: You don't gain much latency benefit.

Pro-Tip: A good rule of thumb is to set your HedgingDelay to your P95 or P99 latency. This ensures you only "hedge" the slowest 1-5% of requests, providing a massive latency win with minimal extra load.

Observability: Tracking the "Speculative" Wins

If you're using Resile's OpenTelemetry integration (telemetry/resileotel), you can actually see these wins in your distributed traces.

Each hedged attempt is recorded as a sub-span. When a hedged request wins, you'll see the first span get cancelled and the second one succeed—providing clear proof that hedging saved your user from a 2-second wait.

Conclusion

Request hedging used to be a technique reserved for companies with massive infrastructure teams. With Resile, it’s a tool that every Go developer can use to build snappier, more resilient microservices.

By moving from "Wait and Retry" to "Hedge and Win," you can turn your long-tail latency into a competitive advantage.

Give Resile a star on GitHub: github.com/cinar/resile

How are you handling tail latency in your Go services? Let's discuss in the comments!

Python's Stamina for Go: Bringing Ergonomic Resilience to Gophers

Onur Cinar — Tue, 10 Mar 2026 02:04:41 +0000

If you've ever worked in the Python ecosystem, you've likely encountered tenacity or its opinionated wrapper, stamina. They make retrying transient failures feel like magic: a single decorator, sensible production defaults (exponential backoff + jitter), and built-in observability.

The Go ecosystem has powerful tools, but they often require a lot of boilerplate, use reflection, or lack the "Correct by Default" philosophy that makes stamina so great.

That's why I built Resile. It’s a love letter to Python's ergonomics, written in idiomatic, type-safe Go 1.18+.

The Ergonomic Gap

In Python, retrying an API call with stamina looks like this:

import stamina

@stamina.retry(on=httpx.HTTPError, attempts=3)
def get_data():
    return httpx.get("https://api.example.com").json()

Before Go 1.18, achieving this level of simplicity was nearly impossible. You either had to write verbose for loops or use libraries that relied on interface{} and reflection—which meant losing type safety and slowing down your code.

With the arrival of Generics, the game changed. We can now have the best of both worlds: Python-level ergonomics with Go’s compile-time safety.

The Resile Way: One-Line Resilience

Resile uses Go 1.18+ Type Parameters to wrap your logic in a resilience envelope. Here is how you fetch data with Resile:

import "github.com/cinar/resile"

// data is automatically inferred as *User
data, err := resile.Do(ctx, func(ctx context.Context) (*User, error) {
    return apiClient.GetUser(ctx, userID)
}, resile.WithMaxAttempts(3))

It looks and feels like a simple function call, but under the hood, Resile is doing the heavy lifting:

AWS Full Jitter Backoff: Spreading out retries to protect your database.
Context-Awareness: Cancelling retries immediately if the request times out.
Memory Safety: Using managed timers to prevent goroutine leaks.

Why "Correct by Default" Matters

One of the best things about stamina is that it makes the right thing the easy thing. Resile follows this philosophy strictly:

Exponential Backoff is the Default: You don't have to configure it; it's there from attempt one.
Jitter is Not Optional: Resile forces randomization to prevent "thundering herd" outages.
Zero Dependencies: The core of Resile depends only on the Go standard library. No bloated dependency graphs.
No Reflection: Unlike many older Go retry libraries, Resile uses static type parameters. This means zero runtime overhead and zero chance of a "type mismatch" panic.

Batteries Included (But Removable)

Just like stamina integrates with structlog and Prometheus, Resile provides optional sub-packages for modern observability:

telemetry/resileslog: High-performance structured logging with Go 1.21’s slog.
telemetry/resileotel: Full OpenTelemetry tracing. See every retry attempt as a sub-span in your Jaeger or Honeycomb dashboard.
Adaptive Retries: A client-side token bucket (inspired by Google's SRE book) to prevent your fleet from killing a degraded service.

Fast CI/CD: The "Stamina" Secret

A hidden feature of stamina that I absolutely loved was the ability to globally disable wait times in unit tests.

Resile brings this to Go through Context Overrides. You can make your 30-second retry loop execute in 1 millisecond during tests without changing a single line of business logic:

func TestService(t *testing.T) {
    // This context tells Resile to skip all sleep timers
    ctx := resile.WithTestingBypass(context.Background())

    err := myService.PerformTask(ctx) // Retries instantly!
}

Conclusion

We don't have to choose between Go's performance and Python's developer experience. By leveraging modern Go features like Generics and slog, we can build tools that are both powerful and a joy to use.

If you’ve been missing stamina in your Go projects, give Resile a try.

Check it out on GitHub: github.com/cinar/resile

DEV Community: Onur Cinar

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

The Missing Link: Zellij Web + Tailscale

Setting Up Your "Dispatch" Server

1. Create the Authentication Token

2. Start the Zellij Web Server

3. Expose the Port via Tailscale

The Remote Workflow in Action

1. The Mobile Handoff

2. Chat and Dispatch

3. Detach and Walk Away

4. Asynchronous Monitoring

5. The Seamless Return to Desktop

Why This Approach Scales

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

The Problem: The "Fairness" Trap

The Solution: Priority-Aware Bulkheads

Implementing with Resile

1. Define Your Priorities

2. Attach Priority to Context

3. Handle Shedded Load

Why Use Priority-Aware Bulkheads?

Comparison: Static vs. Priority vs. Adaptive

Conclusion

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

What is Distributed Deadline Propagation?

The Resile Way: Smart Deadlines

1. Early Abort: WithMinDeadlineThreshold

2. Header Injection: InjectDeadlineHeader

For REST/HTTP:

For gRPC:

Why This Matters for Resilience

Comparison: Static vs. Distributed Deadlines

Conclusion

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

The Problem: "Dark Code" in Resilience Policies

The Solution: Fault & Latency Injection

Key Features:

Practical Usage

1. Basic Chaos Configuration

2. Testing Your Circuit Breaker

Configuration Reference

Best Practices

Conclusion

Beyond Static Limits: Adaptive Concurrency with TCP-Vegas in Go

The Problem: The "Fixed-Limit" Trap

The Solution: Little's Law & TCP-Vegas

How it works:

Implementing with Resile

Why "TCP-Vegas"?

Zero-Configuration Resilience

Conclusion

Respecting Boundaries: Precise Rate Limiting in Go

The Problem: Unbounded Traffic

The Solution: The Token Bucket Algorithm

Implementing with Resile:

Rate Limiting vs. Adaptive Retries

Shared Rate Limiters

Observability: Seeing the Shaping

Conclusion

Stop the Domino Effect: Bulkhead Isolation in Go

The Problem: Resource Exhaustion

The Solution: The Bulkhead Pattern

Implementing with Resile:

Using a Shared Bulkhead

Why "Fail-Fast" Matters

Observability: Monitoring the Walls

Conclusion

Infinite Data Processing in Go: Building Resilient Data Pipes with Channels

The Power of Channels as Data Pipes

Building a Pipeline Stage

Handling Stream Complexities with Helpers

1. The Branching Problem

2. Lookbacks and Sliding Windows

3. Bridging the Gap: Slices vs. Streams

Chaining the Pipes Together

Why This Architecture Wins

Try It Out

Self-Healing State Machines: Resilient State Transitions in Go

The Resile Way: One-Line Resilience for Transitions

1. Early Abort: `WithMinDeadlineThreshold`

2. Header Injection: `InjectDeadlineHeader`

The Resile Way: `DoHedged`