r/Backend • • 20h ago

5+ years into backend development - how should I navigate my career with AI evolving so rapidly?

22 Upvotes

Hey everyone!

I have 5+ years of experience as a backend developer. In my current role, most of my work revolves around building RESTful APIs and endpoints, and I’ve developed a pretty solid understanding of that area.

My current project is coming to an end, and I’m looking at this as an opportunity to explore new technologies, expand my skill set, and move towards the next stage of my career.

With AI evolving so rapidly, I’m trying to figure out where I should focus my efforts. I don’t want to blindly jump on the AI bandwagon, but I also don’t want to miss out on technologies that could be important for my career in the coming years.

I’d love to hear from people who have been in a similar position or are already working in the AI space.

A few things I’m trying to figure out:

What should I focus on next?
Should I deepen my backend/system design skills, learn AI/ML fundamentals, explore LLMs and AI application development, or consider a more significant career shift?

How can I leverage my existing backend experience?
Are there specific AI-related roles or skills that would complement my current experience?

Where do you keep up with AI developments?
What newsletters, communities, YouTube channels, blogs, or other resources do you follow to understand what’s actually happening beyond the hype?

Are there any courses or hands-on projects you’d recommend?
I’d prefer something practical that helps me build real skills rather than just collect certificates.
If you were in my position today, with 5+ years of backend experience, how would you approach the next 6–12 months?

Would really appreciate any advice, resources, or personal experiences.

Thanks!


r/Backend • • 15h ago

Client retries a DELETE after a timeout. Second call: 404, 204 or 410?

16 Upvotes

A small API design question where I keep seeing different answers.

A client sends DELETE /orders/42. The server deletes the order and starts sending the response, but the connection drops and the client times out. The client doesn’t know whether it worked, so it retries the same request. This time the order doesn’t exist anymore.

What should the second call return?

A. 404 Not Found
Literally true: the resource isn’t there. Simple to implement and what most frameworks do by default. The downside is that the client sees an error for something that effectively succeeded, so it has to treat 404 on a retry as success.

B. 204 No Content (same as the first call)
Makes the retry look identical to the original. The client never needs special handling. The downside is that you also return 204 for ids that never existed, which can hide typos and bugs on the client side.

C. 410 Gone
Says “this existed and was removed on purpose”, which is more informative than 404. The downside is that you need to remember what used to exist, so you need a tombstone or a soft delete, and that’s more state than many services want.

My understanding is that DELETE is meant to be idempotent in the sense that the server state ends up the same after one call or ten, and that the response status doesn’t have to be the same each time. So A is technically fine. But “technically fine” and “pleasant to use” aren’t the same thing.

Where I lean right now is B for internal APIs, where clients are retrying automatically, and A for public ones, where I’d rather surface mistakes. But I don’t feel strongly about it, and I can see C being worth the extra state if you already keep audit records.

Which one do you pick, and does it change when the clients are automated retriers rather than people poking at an API?


r/Backend • • 18h ago

New backend engineer here, how would you approach optimizing a slow API?

5 Upvotes

Hey everyone!
I’m fairly new to working with production backend systems, and I’ve been given a task to look into the performance of an existing service and figure out where improvements might be possible.
The service handles a few different things, including business logic evaluation, configuration management, automated workflows, data processing, and logging. Some API requests are taking longer than expected, and I’d like to understand what’s causing the delay and what could be done to improve things.
I don’t want to jump straight into suggesting random optimizations without understanding the actual problem first, so I’d love to hear from people who’ve dealt with similar situations.

A few things I’m curious about:
-When you encounter a slow API, where do you usually start? Profiling, distributed tracing, database analysis, or something else?
-How do you figure out whether the bottleneck is in the application logic, database queries, repeated computations, or calls to other services?
-What common performance issues have you come across in systems that deal with configurable business logic?
-When does it make sense to consider caching, parallel execution, or moving certain operations to background jobs?
-How do you identify worthwhile improvements in an existing codebase without risking changes to its existing behaviour?

Since I’m still early in my career, I’d really appreciate hearing how you’d approach this in a real-world environment. If you’ve worked on something similar, I’d love to know what worked for you, what didn’t, and any tools or resources you’d recommend.
Thankyouu in advance

TL;DR: I’m a new backend engineer looking into why some API requests are slow and how to identify potential performance improvements. I’d appreciate practical advice on finding bottlenecks, choosing the right profiling tools, and deciding which optimizations are worth recommending.


r/Backend • • 3h ago

How do you structure the adapter layer when normalizing dozens of third-party provider APIs?

1 Upvotes

We're integrating a few dozen external content providers behind one internal interface, and each one does things differently: auth schemes, how a session gets launched, callback formats, currency handling, and how promo-style grants are modeled.

Right now we have a thin per-provider adapter for each one, but the amount of duplicated glue code is starting to hurt. The alternative we're weighing is a generic, config-driven mapper where each provider is mostly a declarative mapping plus a few escape hatches for quirks.

For people who've run something like this at scale: - Did you stay with per-provider adapters or go config-driven, and where did the abstraction start to leak? How do you deal with provider-specific quirks without polluting the core domain model? - How do you handle versioning when a provider changes their API, and do you do contract testing against their sandboxes (or record/replay), given that sandboxes are often flaky or behind production?

Would love to hear what worked and what you'd avoid.


r/Backend • • 18h ago

In which email do you have your app tools signed up with?

0 Upvotes

Hello, I need to know. Do you create separate email to have database, posthog, revenuecst,... signed up with this email? If so, which provider do you use? Im looking into something that's not going to ban my email because it wants to. Thank you for any tips!


r/Backend • • 23h ago

Pattern for handling long CPU-blocking tasks behind persistent WebSocket connections

0 Upvotes

Hello backend devs,

In an offline backend architecture, client apps communicate via WebSockets while tasks are processed by a local background engine. On CPU-only systems, synchronous processing steps can create 30+ second gaps before streaming begins, causing connection timeouts.

We are refactoring the transport layer to immediately return an async job ID, queue work in a bounded worker pool, and emit regular heartbeat/ping frames over the WebSocket during execution gaps.

How do you typically decouple persistent transport layers from blocking compute steps to prevent transport dropouts in local desktop backends?

Context: Architectural feedback query on async job queuing and WebSocket state management.