r/Backend

We had a stack debate on my team back in 2024 that ended with "fine, let's just run both and see." Same microservice, built twice — once in Spring Boot 3.2 / Java 21, once in Node 20 / Express. Same Postgres, same Redis, same AWS ECS setup. 18 months later I went through Cost Explorer and our time tracking.

Sharing the numbers in case anyone else is having this debate:

Infrastructure (18 months):

• Node.js: ~$10,890 (needed 1GB RAM/instance after month 3)
• Spring Boot: ~$5,490 (stayed at 512MB the whole time)

Developer time on production issues:

• Node.js: ~285 hours (memory leaks, npm breaking changes, async race conditions, audit fixes)
• Spring Boot: ~26 hours (dependency updates, one N+1, pool tuning)

Memory pattern that surprised me most: Node.js instances climbed 180MB → 890MB over 4 days, crashed, restarted. Staircase to hell. Traced to event listener leak in a popular npm package (2M weekly downloads). Spring Boot stayed flat at ~280MB the entire 18 months.

Under Black Friday load (10x normal traffic):

• Node.js: 3 instances OOM-crashed during peak. Cold start under load: 2.4s.
• Spring Boot: Zero crashes. Cold start under load: 4.1s (slower, but stable).

Not saying Node is bad. We kept it for internal admin tools and low-traffic stuff. But for customer-facing APIs that need to stay up 24/7, the JVM's 25 years of GC engineering paid for itself many times over.

Curious if anyone else has run this kind of side-by-side. Specifically interested in:

• Did virtual threads (Java 21) change your scaling math?
• Anyone tried Bun or Deno in this same comparison? Would they hold up better than Node?
• How much of the Node memory issue is npm ecosystem vs V8 itself?

While documenting MQTT support in LavinMQ, I ended up digging through the broker internals and found something interesting architecturally.

Internally, MQTT subscriptions are mapped into queue-like structures while still preserving MQTT pub/sub semantics for clients.

That got me thinking:

If you were designing a broker that supports both AMQP and MQTT, would you:

• Keep completely separate routing systems?
• Translate MQTT concepts into queue-based internals?
• Or unify both protocols around a common abstraction?

One thing that surprised me is how much of MQTT can still leverage queue-oriented storage internally while presenting a pure pub/sub model externally.

Curious how people here think about multi-protocol broker design and protocol abstraction layers.

I’m currently an MCA student and thinking long term about backend engineering.

In the current market situation, is it still worth learning Java deeply along with MySQL for a long-term backend career path?

By “deeply” I mean:

• Core Java fundamentals
• OOPs, multithreading, collections
• JDBC, Spring Boot later
• Database design + MySQL
• Building scalable backend systems

I know trends keep changing (Node.js, Go, AI etc.), but I want to build strong engineering fundamentals instead of chasing hype every few months.

For experienced backend engineers:

• Is Java still a solid long-term choice in 2026?
• Does deep Java knowledge still pay well?
• Would you recommend it for someone starting seriously now?
• What should I focus on besides Java + MySQL?

Would appreciate honest industry advice.

every platform i checked to deploy my node backend is asking for card details, is there any platform which deploys it for free. This is for my resume project

I have a good experience with typescript and little knowledge about rust.

But i dont feel like doing rust now, so i wanted to explore either go or elixir but im confused rn, idk what to choose. Idk which helps more for my career growth

Please share your suggestions

Edit - i dont have any particular projects in mind, i just want to explore other than typescipt( im bored of it because i dont write code anymore claude does)

So im just confused, even if i learn elixir now after 6 months or 1 year or so ill learn golang too. So the better question is which one shall i explore first go or elixir?

Also it should help me for my career growth, and make me a better developer too.

Sorry for the rant and for my current state of confusion! 🥲

Edit 2: thank you all for your suggestions, i decided to go with golang as it better suits with my long term goals

Hey guys,

I’m currently a front-end React developer with around 3-4 years of experience.

I originally started programming with C# and .NET, so I do have some backend experience, but it’s pretty vague at this point. At work I’m mainly focused on the frontend, and only occasionally touch the .NET API for smaller fixes to finish tasks.

Lately I’ve been wanting to become more of a full-stack developer using Node.js instead of .NET, since Node interests me a lot more.

The problem is that most Node.js courses start completely from scratch, which doesn’t really work for me because I already have programming experience. I’m looking for something more intermediate/advanced or at least more practical.

I know project-based learning is usually the recommended approach, but I’m struggling with creating a proper roadmap for myself - what projects to build, what concepts to focus on first, and how to progress from “I can build an API” to actually becoming a solid Node.js backend developer.

For people who already made a similar transition:

\\- What helped you the most?
\\- What kind of projects would you recommend?
\\- What topics should I focus on beyond basic CRUD APIs?
\\- Any courses/resources that are better suited for experienced developers instead of beginners?

Would really appreciate any advice!

p99 sitting at 600ms. we checked everything. execution plans, indexes, N+1s, connection pool. added Redis caching on the heaviest endpoints. hit rate came back at 4% because param variation meant almost nothing reused. three weeks in and we'd basically just added a round trip to every request.

then someone looked at the NGINX config. keepalive_timeout was 2 seconds. keepalive_requests was 10. under real load, connections were tearing down and renegotiating constantly, every upstream request paying SSL handshake and TCP setup overhead. gzip wasn't on for API responses. upstream keepalive between NGINX and the app wasn't configured at all. fix was a config file. 40 minutes. p99 dropped to under 200ms. some endpoints hit sub-100ms. zero application changes.

the answer was sitting in a config file the whole time while we were rewriting cache invalidation logic. if your app looks healthy and your db looks healthy, check what's sitting between them before you touch anything else. what's the most embarrassing place you've found a bottleneck?

Say I have a table with users:

USERS

-----

ID

EMAIL

PASSWORD

CREATED_AT

UPDATED_AT

then I also create a table to track changes:

USERS_LOGS

----------

USER_ID

TIMESTAMP

ID

EMAIL

PASSWORD

CREATED_AT

UPDATED_AT

Does it make sense to have CreatedAt and UpdatedAt on the USERS entity if there is already a "TIMESTAMP" field in USERS_LOGS?

Trying to prioritize building rather than complexity and was looking for some suggestions.

Hi everyone. I'm a backend developer working with Java/Spring Boot, and I'm also a fresher. I'm starting to figure out a lot of things and realizing the skills I need to do well in my day-to-day job. One of those things is having a strong understanding of the business rules behind a project, which helps write solid and reliable logic. So I'm trying to work on that.

But here's the thing: if I'm not working on a project for a client who explains all the processes of their organization, where do I find those rules? For example, if I want to work on a finance, banking, or stock management project — where do I find the right business rules? By "right," I mean realistic ones, actually used in the real world.

I feel like this is a big differentiator when it comes to developer levels. So if you guys know any resources that could help, it would be greatly appreciated.

Ive noticed at my company a trend of hiring a lot of juniors devs or ppl who don’t have dev backgrounds and having them exclusively churn out AI code. I see this as a way to undercut salaries, they hire junior or non-devs and pay a fraction of what they pay mid-senior. My questions are, is this a sustainable model? And how can I as someone with 5ish years experience stand out from this?

From a c-suite/management perspective they are all about cost savings, if they can hire a junior/non-dev using AI to build out their codebase why hire a mid-senior at 2-3x the price?

What is the selling point/secret sauce that warrants paying a mid-senior dev if a junior/non-dev can churn out code now with AI?

I used synchronize: true in a NestJS project for way longer than I should have. It was fine in development. But when I renamed a column in an entity, pushed to production, and TypeORM dropped the old column and created a new one on the next restart., data was gone.

You can fix this with migrations, but the TypeORM + NestJS migration setup is very confusing because the TypeORM CLI doesn't know about NestJS's dependency injection. You end up needing two configs, one for AppModule, one for the CLI, and getting them to share the same values without duplicating everything takes a bit of work.

The piece that finally made it click for me was the data-source.ts file. It's a standalone TypeORM DataSource that reads from your .env directly, no NestJS involved. The CLI uses that. NestJS uses ConfigService in AppModule. Both point to the same database, same entities, same migrations folder.

Im front-end leaning dev but Im trying to pick up more backend tickets to expand my backend skills.

I am wondering, what are the responsibilities? Id like to bring it up to my manager and push similar iniatives as well.

So far I have done:

- Done database migration by creating new tables or add/modify columns

- Create and adjust endpoints, so that the client can say update a new column in the database with new API versioning

- Logging and monitoring to some degree

- I only worked on repositories where it's the API and API gateway itself. I don't touch other stuff like Kafka setup, Redis, etc.

I have not done:
- Query optimization. I think for Query optimizaiton I will have a chance if people are reporting the backend to be slow.

Im only doing simple shallow backend tickets now, I think I am missing alot of the 'beef' of backend

we had this ai feature working pretty nicely in staging. clean json coming in, small files, predictable prompts, response time was fine and the model was giving decent answers. logs were clean too, so honestly we thought we were mostly done with the risky part.

then actual users started using it and the whole thing got messy pretty fast. first week only and we were already seeing stuff we never tested properly. pdfs with weird formatting, tables copied from excel, prompts with half the info missing, random extra context pasted in, all that kind of stuff. the annoying part was that most of it still passed validation. api returned 200, latency looked fine, no scary errors in logs. so from backend side it looked healthy.

but the answers were not always healthy. some were slightly wrong, some missed important sections because the parser skipped chunks, some retrieval results were just not relevant enough, and our fallback logic was basically too polite. it kept trying to answer instead of saying it did not have enough clean input for this. we were tracking uptime and token usage like that was enough, but we were not really tracking retrieval misses, low confidence outputs or bad answer patterns.

so yeah, lesson learned the hard way. an ai demo working in staging does not mean the feature is ready for real users. staging tests the happy path. production tests every weird thing people can possibly upload or type. curious what broke first for you after shipping an ai feature?