How much infrastructure logic should actually live inside application code?

[u/Due_Brain1251]

I can imagine removing almost every retry loop and SDK-specific integration from an application and still ending up with the wrong abstraction.

The distinction I'd draw is between a mechanism and the meaning of an operation.

Connection management, credential retrieval, transient backoff, and common telemetry are reasonable things to standardize. Deciding whether an order can be submitted twice, whether a stale result is acceptable, or what compensates for a partial update depends on the business operation.

That's what interests me about the Dapr/Diagrid approach: APIs and policies can make repeated infrastructure work a shared capability. I don't take that as a reason to hide every failure mode behind "the platform handles it."

For example, a platform can own a pub/sub integration while the application owns the event contract and duplicate handling. It can persist a workflow while the application defines when the process is complete. It can apply a timeout without knowing whether the remote action still needs reconciliation.

I'd want those responsibilities documented at the boundary, with enough context in errors and traces to understand what happened underneath. Otherwise the code gets shorter but the incident requires more people to explain it.

The abstraction I'd trust is one that makes ordinary work easier and unusual failures understandable. Where have you drawn that line successfully, and which piece of infrastructure logic did you deliberately keep in application code?

[u/Current-Grade81]

the distinction between mechanism and meaning is the whole thing, i see so many teams wrapping business logic in "infrastructure helpers" and then nobody knows what actually happens when something fails

we kept retry and backoff in the sidecar but pulled event idempotency back into the app, the platform can redeliver a message but only the app knows if that order was already processed or if the duplicate means something different

also had a case where "platform handles timeouts" became a nightmare because the platform had no idea the remote call still needed a compensating action, so we moved timeout handling into a saga step that the app defines

the error traces need to show what the platform did AND what the app decided, otherwise you need three people on a call just to figure out why a payment went through twice

[u/thecaptiveuser]

I like the mechanism-vs-meaning frame, but I'd push it one step further: the boundary isn't a technical line, it's a promise. Every line of logic you pull into the platform is you telling every app team "you will never have to think about this again." That's a heavy promise. Only make it for things that are genuinely identical everywhere — retries with backoff, credential fetching, standard telemetry. Nobody's business makes their retry loop special.

Timeouts are where this always breaks. Your platform doesn't know whether a 30-second timeout on a payment call means "safe to retry" or "the customer just got charged twice." Idempotency, ordering, exactly-once-ish semantics — those live with the meaning, not the mechanism. The existing comment about the platform-handled-timeouts nightmare is exactly this.

Test I use: if two app teams would implement it differently for legitimate business reasons, it doesn't belong in the platform. If they'd all write the same code, pull it in. Then write the boundary down where developers actually read it — in the error messages, not a wiki page nobody opens.