u/Capable-Morning-9518

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?

You added Transactional. You’re sure it’s there. You can see it in the code.But the database is in an inconsistent state. The rollback didn’t happen. And there’s no error in the logs.

We had a 14-hour outage caused by a circular Hibernate entity reference that generated a 40-page query plan. That was the end of 6 years of JPA for us. Wrote about the decision and what we use now.

A customer called and said their dashboard showed they paid twice. Their bank showed once. Turned out we had a self-invocation bug on the payments path Transactional on a method calling another Transactional method in the same class. No proxy. No transaction. Two DB writes. One card charge.

We'd been doing this for 8 months without knowing.

Wrote about what we found, what else broke when we started looking, and what we replaced it with.

We used Lombok in our Spring Boot services for about 2 years.

It was great at first, but debugging production issues started to get harder over time. Stack traces pointing to generated code, constructors we couldn’t see things just took longer to understand.

We didn’t remove it because it’s bad.
We removed it because debugging became easier without it.

Curious if anyone else had a similar experience.

Stack traces pointing to methods we didn't write. Juniors asking "where's the constructor?" for the 10th time. Builder silently skipping final fields.

We thought it was saving us time. It was hiding problems we couldn't see.

After the third 3AM incident we made the decision. Full writeup.

What's your experience with Lombok in production — keep it or remove it?

847 database queries. For one page load.

We had Hibernate. We had Redis caching. We had indexes. Everything the tutorials told us to have.

And our database was on fire.

Took us 3 years to figure out what was actually happening.