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?

I keep seeing people ask for the “best Spring Boot course” or roadmap.

Honestly, I wouldn’t spend weeks watching tutorials.

Learn only enough Java and Spring Boot to build one basic CRUD application, then start coding.

Build something simple like an Employee Management API:

• Create employee

• Get employee by ID

• List employees

• Update employee

• Delete employee

While building it, learn these concepts in this order:

1. Controller, service and repository layers

2. REST methods and HTTP status codes

3. DTOs and request validation

4. Global exception handling

5. JPA relationships and database migrations

6. Basic Spring Security

7. Unit and integration testing

8. Docker and deployment

That one project will teach you more than watching 20 hours of videos.

After CRUD, add features one by one:

• Pagination and filtering

• Authentication

• Role-based authorization

• Audit fields

• Caching

• Background jobs

• File uploads

The biggest beginner mistake is trying to understand the entire Spring ecosystem before building anything. You don’t need Kafka, microservices, Kubernetes or complex design patterns for your first project.

Build a boring monolith first. Make it clean, testable and deploy it somewhere.

My rule is: use tutorials to unblock yourself, not as a substitute for building.

For experienced Spring Boot developers here: what is the one thing you wish beginners would focus on earlier?

6 months ago, I shared with you my 35-week project-based Spring Boot Roadmap From Zero to Microservices, and I did not expect this whole positive feedback and support from you guys.

Today, the repository reached 200+ stars because of you, so I decided to provide more guidance by drawing this overview visualization on excalidraw to help you create a bird's-eye view of the wide open world of the Spring Boot ecosystem.

An SVG version could be found inside the roadmap itself for a more clear picture.

You can view the full roadmap from this link:
https://github.com/muhammadzkralla/spring-boot-roadmap

Again, thank you for all your support and stars!

Been working with Spring Boot for 10+ years and I keep seeing the same Transactional bugs show up in code reviews and production incidents. Figured I'd share the rules I follow now.

1. Keep transactions short. DB operations only. If your method calls an external API, sends an email, or uploads a file inside Transactional, it holds a DB connection for the entire duration. Not just during queries. During the ENTIRE method. Under load your connection pool runs out and your app freezes.

2. Never call a Transactional method from the same class. Spring uses proxies. When you call a method within the same class its a direct this.method() call. Proxy is bypassed. The annotation is completely invisible. No warning. No error. It just does nothing.

3. Use rollbackFor = Exception.class for critical operations. This one catches people off guard. Transactional only rolls back on RuntimeException by default. If your method throws a checked exception like PaymentException, the transaction commits. Your balance gets deducted but the payment never went through.

4. Don't catch exceptions inside Transactional unless you re-throw. If you catch the exception, the proxy sees a normal return. It commits. Partial data in your database. Silent corruption. Either let it propagate, re-throw after logging, or call TransactionAspectSupport.currentTransactionStatus().setRollbackOnly().

5. Use readOnly = true on all read-only methods. It tells Hibernate to skip dirty checking and snapshot comparison. Saves CPU and memory. Some proxies use it to route to read replicas. But don't rely on it to prevent writes. Explicit save() or flush() still goes through.

6. Only works on public methods. Proxy can only intercept public methods. Put Transactional on a private method and it does absolutely nothing. Spring won't even warn you.

7. Separate Retryable and Transactional into different beans. If both are on the same method and a checked exception is thrown, the transaction commits before the retry fires. Retry starts a new transaction. Same deduction runs again. Triple retry = triple deduction. Outer bean handles retry, inner bean handles transaction.

8. Enable these two configs in every environment. logging.level.org.springframework.transaction.interceptor: TRACE shows when transactions start commit and rollback.

spring.datasource.hikari.leak-detection-threshold: 15000 catches connections held too long with a full stack trace.

The one rule that covers most of these: uTransactional only works on public methods called from outside the bean. Everything else is silently ignored.

Anyone run into other Transactional gotchas I missed?

These are errors I keep seeing in code reviews after years of working with Spring Boot. None of them throw errors during development. All of them cause problems at scale.

1. The N+1 you dont know about. findAll() returns 100 orders. Each has a customer. Hibernate fires 1 query for orders plus 100 queries for customers. 101 round trips for what should be 1. Fix with JOIN FETCH or EntityGraph.

2. save() fires a SELECT before every INSERT when using UUID as ID. ID is never null so Spring thinks entity exists. Calls merge() which does a SELECT first. 10000 inserts become 20000 queries. Fix by implementing Persistable and overriding isNew().

3. Returning entities from controllers. Jackson calls getters during serialization. Lazy relationships trigger N+1 queries while writing the response. Always return DTOs.

4. Using Lombok Data on entities. Generates equals/hashCode using all fields including ID. ID is null before save, has value after. HashSet breaks. Use Getter Setter and write equals/hashCode on a business key.

5. Batch inserts dont work with GenerationType.IDENTITY. IDENTITY needs a round trip per INSERT to get the generated ID. Batching impossible. Use SEQUENCE with allocationSize 50.

6. deleteAll() loads everything into memory first. 50000 rows means 50000 SELECT then 50000 individual DELETE. Use Query with bulk delete instead.

7. Batching is disabled by default. Every save() is one individual round trip. Set hibernate.jdbc.batch_size to 50 with order_inserts true. Difference between a 4 hour import and a 5 minute one.

8. Caching entity references. Default cache stores references not copies. One request mutates the cached entity. Every user after that sees corrupted data. Cache DTOs or records instead.

Bonus. Set spring.jpa.open-in-view to false. Default is true. Keeps Hibernate session open during JSON serialization. Hides lazy loading issues that explode in production.

What JPA gotchas have you experienced in production?

Hi there! 😊

This subreddit was without moderation for months (maybe even years?), so I’ve stepped in to tidy things up a bit. I cleared out the entire mod queue, so apologies if some of your comments or posts were accidentally deleted in the process.

I’d like to introduce a few rules—mainly to remove blog post spam and posts that aren’t about Spring or Spring Boot (like Java interview questions or general dev interview questions). Overall, I think the subreddit’s been doing okay, so I don’t plan on changing much, but I’m open to adding more rules if you have good suggestions!

I’ve also added some post and user flairs to make filtering content easier.

A little about me: I’ve been working as a full-stack dev since 2018, primarily with Angular and Java/Spring Boot. I know my way around Spring Boot, though let’s be honest—being full-stack comes with its fair share of memes. 😄

I found these portfolio projects, nice, fun and clear and I think you will too.

Here is a list of 5 springboot based projects to add to your portfolio.

Start with something easy and small, with this video covering JPA and H2 DB development: https://youtu.be/8M3ZxWOr3yQ?si=L-WSZJMDbZeGbWtQ

Then move on to understand DB Migrations using Flyway: https://youtu.be/X6LzJg8P-qI?si=snR712LEAvoIgmrR

Now this is the REAL DEAL, a totally FREE two and a half hours long video explaining how to build an enterprise level system based on Springboot Microservices, it covers various topics such as Kafka, Keycloak, DB migration, Resilience 4J, etc.. 
https://youtu.be/-pv5pMBlMxs?si=O9-6s5wimQDqO9VO

Here is a fun project to build a system using NASA asteroid API, where you’ll learn to send actual emails: 
https://youtu.be/6EYZzgWkKaY?si=eP9n6ww6TGlu1RoZ

This video builds another micro services application, where it also shows you how to write unit tests for your controller, service and client classes. Very good to understand how to structure an enterprise level application with a third party API integration as well: 
https://youtu.be/lDihdYfVACM?si=oBTLj7so6euVbACz

I personally found these videos a great addition to my portfolio projects. I’ve taken these projects and built upon them. They are step-by-step so you should end up with a working program at the end.

Happy Springboot learning !

Solo dev here, running a Spring Boot 3.4 backend in production (~25k users). Sharing a bug that taught me a lot.

My Stripe webhook handler did a retrieveSubscription() (an outbound HTTP call to Stripe) inside the same u/Transactional boundary that wrote to the DB. Looks innocent. Works fine normally.

Then Stripe had a brief hiccup and started retrying. The Stripe SDK's default read timeout is ~80s. So every retried webhook held a Hikari connection open for up to 80 seconds while waiting on a network call that wasn't even touching the database. Pool size was 60. It drained in seconds, and the entire API started returning 503 — nothing to do with Stripe.

Two fixes:

1. Immediate: pin the SDK timeouts (5s connect / 15s read + 2 retries) so a stuck call can't hold a connection forever.

2. Structural: get the HTTP call out of the transaction entirely, do the external call first, then open a short u/Transactional only for the DB write.

The general rule I now follow: a database connection is a scarce, pooled resource. Never hold one open across an external I/O call. It turned out I had the same anti-pattern in a few other places (Google token refresh, LGPD erasure with N revoke calls) and fixed them all the same way.

Curious how others structure this, do you split into "HTTP outside, TX inside" two-phase methods, or push the external calls fully async via an outbox? I went two-phase for the webhook and outbox for the Google sync.

It's not theoretical stuff. things that actually caused incidents.

a) returning entities from controllers seems harmless until jackson calls getters during serialization and triggers lazy loaded relationships. got N+1 happening in the response layer. DTOs everywhere now. more boilerplate but zero surprises.

b) ddl-auto update outside local is asking for trouble. hibernate silently altered a column constraint in staging once. nobody noticed for weeks. validate in staging, none in prod. flyway handles schema changes now.

c) external api calls inside Transactional is the one that got me on a friday night. your method holds a db connection for its entire duration. not just when queries run. 3 second api call means 3 seconds a connection is doing nothing. 10 concurrent requests and pool is gone.

d) catching exceptions inside Transactional without rethrowing is a silent killer. caught it, logged it, moved on. proxy saw a clean return. committed half the data. other half missing. took hours to debug because there was no error anywhere. the catch block was the bug.

e) Async without a configured thread pool looks fine in dev. default executor creates a new thread per call. no pooling. prod with thousands of requests? thousands of threads. OOM. always configure ThreadPoolTaskExecutor with bounded pool now.

f) calling a Transactional method from the same class is something most devs dont even know is a problem. two methods in same service, both annotated. one calls the other. inner annotation completely ignored because proxy is bypassed on self calls. data inconsistency in prod. separate bean or dont bother with the annotation.

g) open-in-view being true by default still bothers me. keeps hibernate session open during entire request including json serialization. hides lazy loading problems that explode later. first thing i turn off in every project.

what have you stopped doing after seeing it break?

Done writing the same CRUD boilerplate for every Spring project.
FlashAPI is coming to the Java/Spring ecosystem, much to the delight of Java developers.
Introducing Spring FlashAPI.
The idea is exactly the same as the Python version:
You define your JPA entities.
FlashAPI takes care of the REST boilerplate.
From a simple entity, you can automatically get:
CRUD
Pagination
Search & dynamic filters
Sorting
CSV / Excel / PDF exports
Bulk operations
Relationships & expand
Soft delete
Audit trail
Rate limiting
OpenAPI / Swagger
Webhooks
WebSocket events
Access control
Multi-tenancy
And most importantly, FlashAPI doesn’t try to take control of your application.
You can start with zero boilerplate, then gradually take back control of your business logic, services, and controllers.
The goal is simple:
Less repetitive CRUD, more time to build your product.
Spring FlashAPI is open source under the Apache 2.0 license.
Java 21+
Spring Boot 3.2+
Spring Data JPA
👉🏽 GitHub: github.com/HackermanMe/spring-flashapi
I’m looking for developers willing to give it a try — and, most importantly, tell me:
What is actually useful… and what isn’t?
#Java #Spring #SpringBoot #JPA #OpenSource #Backend #RESTAPI #SoftwareEngineering

I recently interviewed Vlad Mihalcea, a Java Champion and long-time Hibernate ORM contributor, for the Korean developer community. Two persistence questions stood out.

1. If AI can generate SQL, do we still need ORM?

Plain JDBC still requires SQL execution, result processing, and mapping code to write and maintain. AI can now generate much of that work.

Vlad agreed that this changes the trade-off. If a team is comfortable with SQL and wants a lightweight stack, plain JDBC with AI handling some of the boilerplate can be a practical combination.

But his point was that JPA/Hibernate is not merely a way to avoid writing SQL. It also provides facilities that teams would otherwise need to manage more explicitly:

• standardized optimistic and pessimistic locking support

• configurable JDBC statement batching

• inheritance mapping

• persistence context / first-level cache

• association-loading strategies

Vlad’s point was that these patterns have been implemented and tested in real projects for roughly two decades.

If an application does not need them, plain JDBC with AI can be perfectly reasonable. If it does, the team may have to implement or manage the same behavior itself after replacing Hibernate.

2. Spring Data JDBC vs Spring Data JPA

Spring Data JDBC can look like a lighter alternative to Spring Data JPA, but lighter does not automatically mean faster.

Spring Data JDBC has no lazy loading. When a repository loads an aggregate, it also loads the mapped child entities and collections within that aggregate boundary. Without inspecting the actual SQL, a team can still fetch more data than expected.

If the real problem is the shape of the queries or the aggregate design, switching persistence libraries will not fix it by itself.

Vlad also tied this decision to the team’s existing skills:

• A team strong in SQL and database performance may do very well with JDBC or jOOQ.

• A team that has used Spring Data JPA successfully for years may gain little from switching simply because another option is trending.

• Technologies with abundant public documentation and examples are also more likely to yield useful AI answers.

Across both answers, I heard the same criterion: choose a persistence model your team can understand, verify, and operate well. Do not choose based on trends alone.

Full interview, for context (free):
https://www.inflearn.com/en/course/vlad-mihalcea-interview

Disclosure: I work at Inflearn, which hosts the interview.

Has AI changed what your team uses in production, or only how quickly you implement it?

Every Java developer knows the drill: go to Spring Initializr, select dependencies one by one, download the .zip, extract it, create the repository... It's a repetitive process.

To solve this and test the capabilities of GPT 5.3 Codex and Opus 4.6, I built Better Spring Initializr. The idea is to level up the bootstrap experience:

• Smart Presets: forget the manual work. Set up complete stacks (REST + Postgres, Event Driven with Kafka, etc.) with a single click.

• AI-Ready: the project is born optimized for AI Coding Agents (Claude Code, Codex, OpenCode, etc.). The generator already delivers AGENTS.md, CLAUDE.md files and Agent Skills specific to the Spring and Java ecosystem.

• GitHub Integrated: connect your account and the repository is automatically created and versioned. Zero manual setup overhead.

The goal is to ensure no critical dependency is forgotten, delivering an architecturally solid and AI-optimized project.

Better Spring Initializr is available at better-spring-initializr.com

The project is open-source and the code is available on GitHub at https://github.com/henriquearthur/better-spring-initializr

ive done node for a couple of backend projects, a small service in go, played with rust for a side thing. theyre all fine, genuinely

but every time im starting something that actually has to ship and be debuggable in 2 years when im not on the team anymore, i reach for spring boot again. ive been doing this long enough to know its not just inertia

the reason is predictability. when something breaks at 2am i know where to look. theres always a controller, always a service, always a config class, the actuator tells me whats happening, spring security has the same shape it had 5 years ago. its boring in the exact way production systems should be boring

with node you can have 4 projects at the same company that look completely different. with go you write everything yourself which is fine until you onboard someone. with rust "the right way" still changes every 18 months. spring boot has been mostly the same since 2016, the answer to most "how do i do X" questions is on stackoverflow from 2018 and still works

i know its verbose. but the verbosity is mostly metadata, its telling future-you what the code does without having to read every line

(actuator alone is worth half of why i pick it. health checks, metrics, thread dumps, standardized across every spring app, i can debug any spring service even if ive never seen it before)

i went and tried the alternatives partly to escape spring boot. trying them made me more convinced its the right answer, not less

While exploring Spring Boot and JPA internals, I came across the N+1 query problem and realized why it is considered one of the most impactful performance issues in ORM-based applications.

When working with JPA relationships such as @OneToMany or @ManyToOne, Hibernate uses Lazy Loading by default. This means associated entities are not loaded immediately—they are loaded only when accessed.

Conceptually, it sounds efficient, but in real applications, it can silently generate excessive database calls.

What actually happened:

I started with a simple repository call:

List<User> users = userRepository.findAll(); for (User user : users) { System.out.println(user.getPosts().size()); }

At first glance, this code looks harmless—but checking the SQL logs revealed a different story:

The first query retrieves all users → Query #1

Then, for each user, Hibernate executes an additional query to fetch their posts → N additional queries

Total executed: 1 + N queries

This is the classic N+1 Query Problem—something you don’t notice in Java code but becomes very visible at the database layer.

Why this happens:

Hibernate uses proxy objects to support lazy loading. Accessing getPosts() triggers the actual SQL fetch because the association wasn’t loaded initially. Each iteration in the loop triggers a fetch operation.

How I fixed it:

Instead of disabling lazy loading globally (which can create new performance problems), the better approach is to control fetching intentionally using fetch joins.

Example:

@Query(""" SELECT u FROM User u JOIN FETCH u.posts """) List<User> findAllWithPosts();

This forces Hibernate to build a single optimized query that loads users and their posts in one go—eliminating the N+1 pattern.

Other approaches explored:

FetchType.EAGER: Works, but can lead to unnecessary loading and circular fetch issues. Rarely the best solution.

EntityGraph:

@EntityGraph(attributePaths = "posts") List<User> findAll();

DTO Projections: Useful for large-scale APIs or when only partial data is required.

Final takeaway:

Spring Boot and JPA provide powerful abstractions, but performance optimization requires understanding how Hibernate manages entity states, fetching strategies, and SQL generation.

The N+1 problem isn’t a bug—it’s a reminder to be intentional about how we load related data.

Recently, I had to complete a home assignment for a company I was interviewing with, but unfortunately, I failed. I have tried to put all my experience and knowledge into the README, so hopefully, you can use it or at least learn something from it.
https://github.com/Jojoooo1/project-assignment

By the way, I am still looking for a job. If you like to build stuff and don't care about LeetCode, I would love to chat!

https://drive.google.com/drive/folders/12S3MEleUKmXp1nbJdZYNDwYTdSqv1hkd?usp=sharing

I created notes while preparing and giving interviews, I am still updating it and adding topics I am also removing LLM points and trying to improve quality of topics notes.

Hope these might help some people of this community.

Hey guys!

I’ve been working on a web app called CodeCafé—a collaborative, browser-based code editor inspired by VS Code and Replit, but with no downloads, no sign-up, and zero setup. You just open the link and start coding—together.

The frontend is built with React and TypeScript, and the backend runs on Spring Boot, which handles real-time editing via WebSockets. For syncing changes, I’m using Redis along with a custom Operational Transformation system (no third-party libraries!).

The idea came after I found out a local summer school was teaching coding using Google Docs (yes, really). Google Docs is simple and free, but I wanted something that could actually be used for writing and running real code—without the need for any sign-ups or complex setups. That’s how CodeCafé came to life.

Right now, the app doesn’t store files anywhere, and you can’t export your work. That’s one of the key features I’m working on currently.

If you like what you see, feel free to star ⭐ the repo to support the project!!

Check it out and let me know what you think!

• GitHub: github.com/mrktsm/codecafe

• Web App: codecafe.app

I recently came across this channel on YouTube, and this guy seems to be very underrated. He hardly gets any views, but most of his videos are very informative and useful. His projects are too good, and I have been continuously following him. The least I can do to support him is to share his channel with others and help him gain more views.

YouTube Channel: LeetJourney

P.S. - This isn't a self/paid promotion. He deserved more views for his quality content, so I dropped his channel link here to help him and you.

https://github.com/spring-projects/spring-boot/releases/tag/v4.0.0

Looking forward to upgrading a few projects next week!

Ran into a wild memory leak recently in one of our backend services — turned out to be caused by a ConcurrentHashMap that just kept growing. 😅 It was being used as a cache... but nobody added a limit or eviction logic.

Over time, it started blowing up heap memory, causing full GCs and crazy latency spikes. Sound familiar?

The solution: just 20 lines of an in-memory LRU cache using LinkedHashMap. No external libraries. No Redis. Just fast, safe caching right inside the JVM.

I wrote a blog breaking it all down:

• Why HashMap can lead to silent memory leaks

• How LinkedHashMap makes LRU caching dead simple

• Real-world patterns and anti-patterns in caching

• How to scale safely with in-memory data

👉 Read the full breakdown on Medium

Curious if others have hit similar issues — or have different go-to solutions for in-memory caching. Let’s talk!

Spring Boot Project

Most Spring Boot tutorials teach you to build a CRUD app and call it a day. But that's not really what the job looks like day to day, so I put together a project that mimics what you'd actually work on as a backend dev at a company with real infrastructure. I've added following 12 Tasks that you'd need to complete.

• Project setup: spin up Postgres + messaging brokers, verify everything's healthy

• Kicking off development: request validators, custom exceptions, a new order status API

• Debug a critical bug: chase down a duplicate-insert caused by misusing EntityManager.persist() vs save()

• ActiveMQ + Apache Camel: configure routes, consume from a queue, handle dead letter queues, publish to a Virtual Topic

• RabbitMQ: set up exchanges/bindings, fix an infinite redelivery bug, publish to a topic exchange

• DB schema migration: add a table with Liquibase, write rollback SQL, fix an N+1 write

• Testing: unit tests with Mockito, snapshot tests, integration tests with TestContainers

• Code style: enforce formatting automatically with Spotless + Palantir Java Format

• Prometheus metrics: expose app metrics via Actuator, configure scraping

• Grafana: connect to Prometheus, build dashboards, add @Timed annotations

• Load testing: run JMeter tests, interpret throughput, watch the impact in Grafana

• Global exception handling: swap per-controller try-catch for @ControllerAdvice + RFC 7807 Problem Details

Everything runs locally via Docker Compose, and there's a Bruno collection included so you can hit the APIs without writing your own Postman setup.

It's completely free and open source, so fork it, work through the tasks in order, and you'll come out the other side with a much better feel for what the job actually involves beyond "make endpoint, save to DB."

Would love feedback from people!

1.  `spring.jpa.open-in-view` is true by default.  It keeps a database connection open for the whole request, including view rendering. Turn it off and fetch what you need in the service layer.

2.  `ddl-auto=update` in production.  Use migrations (Flyway or Liquibase) instead. "update" never drops anything and drifts quietly.

3.  Actuator exposure.  Only `health` is exposed over HTTP by default. If you set `include=*`, you've exposed env, beans and more.

4.  Hikari's default pool size is 10.  Size it for your database and instance count, not by guessing.

5.  No timeouts on outgoing HTTP calls.  One slow downstream service can exhaust your threads.

Which of these has bitten you, and what's missing from the list?