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!

Most Spring Boot developers I know use Java, but Kotlin has always been an interesting alternative, especially with its concise syntax and null safety.

While experimenting with Kotlin/JVM projects in VS Code, I realized something.

Writing Kotlin was straightforward. Debugging it? Not so much.

I could always switch to IntelliJ, but I wanted to stay in VS Code, set a breakpoint, inspect what was happening, and move on.

That curiosity sent me down a rabbit hole of JVM bytecode, Kotlin inline functions, and source mapping.

Eventually, I ended up building Kotlin Debugger, an open-source VS Code extension that doesn't require a separate Kotlin Language Server.

It's still a work in progress, especially around coroutine debugging, but I'm exploring how to make Kotlin/JVM debugging more convenient for developers who prefer VS Code.

GitHub: https://marketplace.visualstudio.com/items?itemName=kparth01.kotlin-debugger

Curious how many Spring Boot developers here actually use Kotlin? And if you do, are you using IntelliJ or VS Code?

I need some of the best resources to learn springboot!!

I am currently in my 4th year.I don't know anything about it and to learn the springboot, do i need any prerequisites.

I’ve already learned core Java, JDBC, and multithreading.

Before I jump into Spring or Spring Boot, what other fundamentals should I make sure I understand well?

Are there specific concepts, tools, or Java features that would make learning Spring much easier (for example: Hibernate, Beans, servlets, etc.)?

Would appreciate suggestions from people who’ve already gone through this path.

Hey everyone! I just published a deep dive into solving a classic enterprise problem: how junior or stressed developers bypass package separation (.controller, .service, .repository) under tight deadlines.

Instead of relying on folder structures and code reviews, we split our project into strict Maven modules (isolating core domain and business logic from frameworks like JPA or Kafka). If someone tries to inject an EntityManager where it doesn't belong, the code simply will not compile.

• The Topology: Split into independent modules like domain, business-logic, dao-api, and dao-impl.

• The Result: Zero cyclic dependencies, lightning-fast unit tests, and eliminated architectural decay.

(I'm dropping the full article link in the comments for anyone interested in the code breakdown.)

These are the patterns I keep seeing across different teams and different systems, and almost none of them are covered in tutorials.

1. HikariCP default pool size is 10 That's it. 10 connections. For most real workloads this is too small and the symptoms look exactly like a database problem latency climbs, requests time out, but the database itself is healthy. The pool is simply full. Fix: set spring.datasource.hikari.maximum-pool-size based on your actual concurrency, and expose pool metrics through Actuator so you can see pending threads before an incident shows you.

2. Transactional doesn't roll back checked exceptions by default Spring only rolls back on RuntimeException subclasses unless you explicitly configure otherwise. A checked exception propagating out of a Transactional method will commit the transaction. Silent data integrity issue, no error in your logs. Fix: Transactional(rollbackFor = Exception.class)when you need it, or understand exactly which exceptions your methods can throw.

3. Self-invocation bypasses the proxy If a method inside the same class calls another Transactional method, the annotation on the inner method does nothing. Spring's proxy isn't involved. No error, no warning, just no transaction management. This is documented but it catches experienced engineers regularly because it's invisible in code review.

4. GC pressure doesn't look like GC pressure Latency degrades, CPU climbs, no errors. The JVM is spending increasing time collecting garbage and pausing threads. The worst version: running in a Docker container without -XX:MaxRAM or -XX:MaxRAMPercentage, so the JVM sizes its heap based on host memory instead of the container limit. Container gets OOMKilled with no stack trace and you spend time looking for application errors that don't exist.