How to approach calculating the cost of individual services? Some are light-weight Nodes as are hey weight node.js that pull a plethora of dependencies. Some are light on the cpu, some not so much. What metrics can we use in determining the cost/price per service on offer?

Rolled a new pricing path behind a flag to a small percentage of traffic. Aggregate error rate barely twitched, so we widened it. Support tickets told us the truth a day later. The code caught a downstream failure and fell back to an old value, so nothing threw, nothing 500'd, and every monitor we had looks at the aggregate anyway. Launch Darkly gives us the flag and some metric hooks, but the only metric we’d wired to it was the error rate hud came up because it counts calls and exceptions per function and flags one that starts behaving differently from the baseline, instead of waiting for a rate to shift. No idea if that covers an exception the code already caught. Anyone catching bad flag rollouts at the function level? Or is this just a case for better custom metrics per flag.

About one checkout in a few thousand fails with a 500 from pricing. Fourteen services, mostly node, and it only happens in prod, only some days, no pattern in the customers. Staging, same images, never.

Traces are sampled at 10%, so most failing requests aren't there. The couple that are show pricing answering fast and then throwing "price not found" for a SKU that has a price. My theory is a race between the inventory reservation and the pricing cache refresh, but I can't make it happen.

We had a hud demo last week since this is the kind of incident they lead with. It counts every call and keeps the params and stack trace for the ones that throw. Tail sampling would catch the failing request not the cache refresh it raced, and a race would need hud on inventory too, another team's service. I will ask them anyway.

Fourteen services, mostly node. Roughly one checkout in a few thousand fails with a 500 from pricing. Only in prod, only some days, and the customers have nothing in common. Staging runs the same images and has never once done it.

Three days on it so far. Our traces are sampled at 10%, so most of the failing requests arent even in there, and the couple that are show pricing answering in 4ms and then throwing. Logs say "price not found" for a SKU that definitely has a price. My theory is a race between the inventory reservation and the pricing cache refresh, but I can't prove it and I can't make it happen.

We had a hud demo last week because the voodoo incident is pretty much the case they lead with. It counts every call and every exception instead of sampling, and for the ones that throw it keeps the request, which is the part our traces lose. What I'm unsure about is a race like this. It would need to be in pricing and in inventory, and inventory belongs to another team that's mid migration and not keen on adding anything.

Asking them anyway, after one more day with sampling at 100% on pricing.

Pricing threw a 500 on a checkout again last night. A few times a day out of roughly 40k orders, always "no active price" for an item that has one when you query it a second later. Only in prod and only some days, and the customers it hits have nothing in common.

Traces are sampled at 10%, so most failures only exist as a one line error log with the SKU. Tail sampling on errors goes in this week, but that keeps the pricing request, not whatever refreshed the promo cache at that moment.

Sat through a hud demo since this is pretty much the bug they open with. It grabs the params and call graph from failing runs, but catching a race would need it on the promo service too and that's another team's. For now I'm adding the cache version to the pricing error log.

We run an internal platform and, like most teams, kept accreting the "standard" stack — a service mesh for policy, a discovery cluster for location, a config service for knobs, a flag service for rollouts. Each justified itself in isolation, and each was a 3am wake-up.

So we rebuilt around three cheap objects:

1. Workers dial OUT. Each one opens a persistent gRPC tunnel to a single stateless gateway at startup and holds it open. No ports to expose, no ingress rules, no DNS. The connection is mTLS, so "connection == registration == identity" — the gateway learns who dialed, not just that something did.

2. The gateway IS the registry. The active-worker table is the set of open, authenticated tunnels. A worker drops and it's pruned the instant the connection dies. No discovery cluster, no TTLs to tune, no stale entries by construction.

3. Schemas are files. Protobuf .desc artifacts live in a folder the gateway watches. Drop a new descriptor in and it learns to validate and translate the new endpoint at runtime — no gateway deploy.

Costs, stated flat: an extra hop in the path, one stateful-ish box (mitigated: workers redial after a gateway restart, the registry rebuilds from their side), and cert rotation is now on our own calendar.

Full write-up, with the diagram: https://lab.embedinker.com/posts/zero-bloat-microservices-reverse-tunnel-gateway/

How do you keep a small internal platform from eating its own maintenance? What made you keep etcd/consul?

Dapr, the Distributed Application Runtime, a graduated OSS project within the CNCF has released a new version. What it means for you:

• Faster workflows, jobs, and reminders: in nightly performance tests against 1.18.0, workflow throughput is up to 40% higher, actor reminder registration p99 latency is 71% lower, and jobs scheduling p99 latency is 33% lower

• Leaner workflow workers: the Python, Java, .NET, and Go SDKs now get only the new events of each turn, not the full history

• Easier workflow operations: list, inspect, and rerun workflows from the .NET, Java, Go, and Python SDKs

• Workflow governance: operate on workflows owned by other apps, with WorkflowAccessPolicy deciding which operations each caller may perform, and requires rules that allow an operation only when the caller's history contains the events you list

• More for AI agents: new alpha APIs to store files, search documents, and query vectors, plus a Dapr MCP server

• A simpler control plane: run actor placement from the Scheduler and drop one service

Read the announcement: https://blog.dapr.io/posts/2026/10/22/dapr-v1.19-is-now-available/

Circuit breakers are good at stopping traffic and bad at resuming it. When a breaker closes, every replica tends to return to its configured limit at the same moment, so a dependency that just answered a few probes gets the full production load again, often while its caches are cold or capacity is still coming back.

I wrote up the design work behind a recovery ramp for Caracal, a resilience library whose distributed bulkhead, rate limiter and breaker coordinate through Redis.

The post covers the options I rejected, the constraints the surviving design had to satisfy, and a four-replica case study where the dependency's own in-flight samples, not the library's event log, are used to check each step. Envoy/Istio slow start is the closest mainstream analogue, though it shifts endpoint weight rather than admission.

This is the sixth article in a series on distributed resilience. I'd be interested in how others handle post-outage warm-up: traffic shaping, staged rollouts, or accepting the spike.

After years of watching teams coordinate work across services, the property I’d evaluate any workflow engine on is durable execution: every step journaled, so a crash or deploy resumes at the exact step that failed, completed steps never re-run, and a two-day wait costs nothing because no process holds it in memory.

Plain checkpointing isn’t the same thing. Crash after charging the card but before writing the checkpoint, and you charge again. Durable execution closes that gap, though activities still need to be idempotent, since delivery is at-least-once.

Two things bite nearly every team, regardless of engine:

• Non-determinism in workflow code. DateTime.Now, random IDs, or an inline HTTP call work fine until the first replay, then diverge. Push them into activities.

• Nobody capacity-plans the history store. Execution history is a database. Plan retention, indexing, and growth like one.

One pattern I keep noticing: AI agents are starting to look a lot like microservices did a decade ago. They’re independent units, calling tools, coordinating with each other, and failing in partial, messy ways. The coordination problems are the same ones this sub has been solving for years, just with less deterministic participants. Which makes me think workflow is about to matter more, not less.

So what’s your setup? Choreography, an orchestrator, sagas you rolled yourself? And what broke first?

Bias: I co-created CNCF Dapr project with workflow and durable execution and I’m curious what others are hitting.

For your company projects are you deploying without kubernetes? Is azure or AWS alternative options ?

This is something I threw together over a year ago. It was designed to be an easy intro into Microservices since I had noticed lacking in the Spring Boot ecosystem that was something hands-on.

I am remaking it in a monolithic repo as a Spring Modulith project, since I noticed there is also a lack in that area for hands-on learning.

Just looking to share this little project with others who may be curious with no clear picture of where to start with them.

Cheers,

The Midnight Coder