u/zvronsniffy

Curious how backend teams here think about modularity at scale.

At what point does a backend stop feeling like a system and start feeling like a pile of scripts, SDK wrappers, env files, auth handlers, retries, queues, webhooks, and debugging tools duct-taped together?

Feels like most teams eventually reinvent an internal layer just to keep everything connected and observable.

What tradeoffs are you actually willing to tolerate to get that modularity?
Extra latency from a middle layer?
Routing calls through a third party?
Some vendor lock-in?
Less direct control over infrastructure?

I keep wondering what “true modularity” for backend systems would actually look like.

Like if services, APIs, queues, databases, auth providers, workflows, and internal tools could just connect together predictably — and you could actually see everything happening in one place. Every request, retry, event, failure, webhook, transformation, credential, and flow.

Less plumbing. Less scattered scripts. Less hidden infrastructure logic. More composable systems.

It’s something I’ve been working on lately and I’m curious whether other backend engineers are interested in this direction too

If you’re a backend developer, you know writing code is only part of the job.
A lot of engineering time goes into what people usually call “plumbing”.
You end up building the same kinds of abstractions everywhere: authentication, secrets management, database access, external API integrations, retries, error handling, queues, background jobs, and all the glue that actually makes systems work.
That’s just normal backend development.
Over time, you naturally try to clean this up. You create modules, shared utilities, internal libraries. You abstract repeated logic so you don’t have to rewrite everything from scratch.
And within a single service, that works pretty well.
But the problem starts when you move across multiple services or codebases.
Even when the underlying logic is basically the same, it still gets rebuilt again and again. Slightly different implementation. Slightly different structure. Slightly different assumptions.
At first it feels harmless.
But over time, that duplication starts to compound.
Now changes have to be made in multiple places. Behavior starts to drift across services. Some systems get updated, others don’t. Maintenance becomes heavier than expected. And the architecture becomes harder to reason about as a whole.
At that point, the problem is no longer just about writing clean code.
It becomes about where backend logic actually lives.
Is it inside each individual service?
Or is there a way to treat it as something more shared and reusable across systems?
Curious how others are thinking about this.
Do you just live with the duplication and manage it carefully, or have you found better ways to structure shared backend logic across multiple codebases?

Hey everyone,
For those of you building backends that connect to multiple external systems (different APIs, databases, message queues, storage, notifications, LLMs, etc.), I have a real question:
Is the setup and ongoing maintenance actually painful for you?
I know there are always workarounds: custom wrappers, internal libs, raw HTTP clients, etc. But I’m curious:
When you’re wiring up yet another API or swapping providers, do you feel the friction of inconsistent patterns, repeated boilerplate (retries, logging, auth, error handling, env configs), secret sprawl, and brittle multi-step flows? Or is it honestly not that big of a deal in practice?
I’m working on a project in this space and I’m trying to get a honest read from engineers on how much this actually sucks day-to-day. Would a more consistent, unified way of talking to all these components be genuinely useful, or are most teams fine managing the zoo of SDKs?
Appreciate any war stories or straight opinions, especially from people running moderately complex backends. Thanks