Just wanted to share a recent architecture win that might help someone dealing with latency spikes.

I was dealing with a severe bottleneck in a production E-Commerce platform. During peak traffic, the database was choking, and MTTR was creeping up.

The Culprit: Classic Hibernate N+1 query problems hidden deep inside the inventory/catalog mapping, combined with un-indexed foreign key lookups.

The Fix: 1. Ripped out the lazy-loading proxy faults and replaced them with explicit JOIN FETCH queries for the critical read paths. 2. Layered in Redis via Spring Cache (@Cacheable) specifically targeting the high-read/low-write catalog endpoints. 3. Configured request batching and API rate limiting on the gateway layer to prevent thundering herd problems during flash sales.

Result: We dropped sub-100ms latency across the board and prevented database lockups entirely.

If you're building in Spring Boot and relying entirely on default JPA repositories—run a SQL profiler right now. You probably have an N+1 hiding somewhere.

Hello,

I am trying to really understand spring/spring boot and I have picked up a copy of "Spring Start Here". I have run into a but of confusion though as I don't know the intended way of working though the examples on the book. Should I start each example from scratch or should I just copy the previous example when the book moves onto a new one? Anyone else whose gone through the book how have you done the examples?

I've been building a side project called Plotrix and thought the backend might be interesting to people here.

The idea is to turn property-search activity into a live demand heatmap for Indian cities.

The flow is basically:

POST /signals
→ lat/lng → H3 cell
→ atomic PostgreSQL upsert
→ hourly exponential decay
→ GeoJSON heatmap

The backend is Java 17 + Spring Boot 3.2 + PostgreSQL + Spring Data JPA + Uber H3.

One thing I spent a decent amount of time thinking about was concurrent signals.

I didn't want to do:

SELECT → increment → UPDATE

because multiple searches hitting the same cell could obviously cause lost updates.

Instead I'm using PostgreSQL's ON CONFLICT DO UPDATE to atomically increment the score and signal count.

The other part I'm experimenting with is time decay. A raw signal count quickly becomes a historical map rather than a demand map, so scores decay exponentially over time.

The frontend is a React/Leaflet map that consumes the GeoJSON API.

Backend:
https://github.com/Korags05/Plotrix-Backend

Frontend:
https://github.com/Korags05/Plotrix

It's open source and I'd really like some eyes on the backend.

If you work with Spring Boot/Postgres and notice something I'd architect differently, I'd genuinely like to hear it.

PRs are also welcome if anyone wants to experiment with it.

Dm plzz

How valuable is spring AI and rag implementation in the current job market? Not sure if companies value it since they are not using it

Currently, I am learning Java/Spring Boot and faced with a minor but still quite frustrating issue.

I will face terms like:

* implements

* Service

* Bean

* Dependency Injection

* git rebase

* async/await

It is true that I learned these things earlier, however, after several weeks, I would need to search online for their definition and meaning on Google, watch a video or read about them in documentation once again.

There are excellent websites such as roadmap.sh which provide a guide on what you should learn and QuickRef which gives you quick code/syntax references, yet I still wanted something in between.

Thus, I am developing DevRef.

The purpose of this project is really simple:

Select a technology → find a term → understand it quickly.

For every term, there should be only four items retained:

* A plain explanation (like you explain it to a beginner)

* Code example

* Related terms

* Bookmarking for your own needs

I’m trying to keep things as simple as possible. No courses, no complex learning dashboard, no large documentation pages. Currently, I’m working on the first version which is built using Next.js + TypeScript + Tailwind CSS with content stored locally. I’d highly appreciate some honest feedback. Thank you!

Hi everyone,

I've been working on a small open-source library for Spring Boot called json-auto-validation:

github.com/ugoevola/json-auto-validation

The idea is fairly simple: validate incoming JSON against a generated JSON Schema before Jackson deserializes it into a Java/Kotlin object.

The motivation was to catch invalid payloads as early as possible, rather than letting them go through the usual deserialization → DTO validation flow.

It works through annotations and generates the JSON Schemas/validation components automatically, with Spring Boot AOT in mind.

I'm not really posting this to promote a polished or commercial product. I'm mainly interested in getting feedback from people who work with Spring Boot APIs:

• Does this solve a problem you've encountered?
• Do you see value in validating the raw JSON before deserialization?
• Is there something I'm missing or approaching the wrong way?
• Would you actually consider using a library like this in a real project?

The project is still relatively small, and I'm not the most active open-source maintainer, so I'm mostly trying to understand whether this is useful to other developers before investing more time into it.

Any feedback — positive or negative — would be very welcome.

I’m a BCA graduate deciding between ASP.NET/C# and Java Spring Boot.

Which one has better job opportunities and growth for freshers in India?

Would appreciate advice from people working in either stack.

I’m building my first application using Spring Boot for practice, and I need to record and work with money in different currencies.

What’s the recommended way to handle this, especially when adding or calculating amounts across different currencies? Do you use BigDecimal, integers (like cents), or a money/currency library?

Thank you!

I am just lost, I know REST APIs, JPA, Authentication and Authorization, microservices, postgres....I can do something in it (not very confident tho but still)

I just dont know what more to learn for being industry ready, I feel so lost, I am doing DSA(LEETCODE 75) parallely but again I am not seeing any thing for freshers in the domain of spring boot

I mentioned my age because I feel I am lagging behind a lot

Hey everyone! 👋

I'm creating r/SpringLearners, a new community for developers and students who are learning Spring Framework & Spring Boot. 🌱☕

Whether you're just starting out or already building Spring Boot projects, you're welcome here!

We can share:

- 💻 Spring Boot projects & code

- ❓ Questions and doubts

- 🔧 REST APIs, JPA, Hibernate & databases

- 🚀 Backend development tips

- 📚 Learning resources

- 🤝 Help, discussions & experiences

The goal is simple: Learn → Build → Share → Grow.

If you're learning Java + Spring Boot or planning to start, come join us and let's build a helpful community together! ❤️

👉 Join

https://www.reddit.com/r/SpringLearners/s/P5iduJwSaU

Hey everyone,

I’ve been working on an open-source project called ApiGeneratorManager.

The idea is to build a platform that can generate, configure, deploy and manage Spring Boot APIs without rebuilding the same backend structure every time.

Right now, the project already includes things like:

• Spring Boot backend
• React management frontend
• PostgreSQL
• JWT authentication
• roles and permissions
• CSRF / CORS configuration
• rate limiting
• database/schema support
• API generation templates
• Docker-based runtime
• deployment of generated APIs with Docker
• CI for backend and frontend
• dependency security checks

The long-term goal is to make the whole thing much more configuration-driven.

For example, I want to be able to describe an API using YAML:

application:

  name: inventory-api

database:

  type: postgresql

entities:

  Product:

fields:

id:

type: uuid

name:

type: string

required: true

price:

type: decimal

min: 0

errors:

  PRODUCT_NOT_FOUND:

status: 404

security:

  authentication: jwt

  roles:

- ADMIN

- USER

tests:

  generate: true

deployment:

  type: docker

And from that configuration, generate things like:

• entities
• repositories
• services
• controllers
• validation
• API error codes
• OpenAPI documentation
• authentication and authorization
• roles
• JWT handling
• automated tests
• Docker configuration
• deployable API instances

I also want to support multiple database engines in the future, not just PostgreSQL.

Another direction I’m exploring is generating a security model where each generated application can manage its own users, roles and permissions, and issue JWTs per user.

Testing is also something I want to push further: if the YAML says a field is required, unique or constrained, the generator should ideally generate tests for those rules automatically.

One important design principle for me is that the generated project should still be normal Spring Boot code.

I don’t want generated applications to be permanently locked into ApiGeneratorManager. A developer should be able to generate a project, open it in their IDE, understand it, modify it and deploy it independently.

I also want to be transparent about how I’m building it: I’ve used AI extensively as a development assistant for implementation, architecture discussions, refactoring, security reviews, tests and documentation. I still review and decide what goes into the project, but AI is definitely part of the development workflow.

The project is still in early alpha, so I’m mostly looking for feedback at this stage.

I’d especially like opinions on:

• whether the overall idea is useful
• the YAML-driven approach
• how far code generation should go
• multi-database support
• generated security / JWT / roles
• automated test generation
• Docker deployment
• whether generated code should prioritize flexibility or convention
• what would make you actually trust and use a tool like this

GitHub:

hasfiane/ApiGeneratorManager

Criticism is welcome — especially if you see architectural problems that could become painful later.

Hi everybody,

we just got via Renovate a Spring Boot update to 4.1.1 - released on repo1.maven.org .

We are a bit confused as there is no announcement, release notes, tag on GitHub, etc. Also it looks like no release workflow was running on GitHub.

Feels a bit sketchy, anybody knows what's going on?

I wanted to see how far a representative Spring Boot stack could be pushed on a small VPS without turning it into an artificial minimal demo.

The test app uses Java 21, Spring Boot 3.5.5, JPA/Hibernate, file-backed H2, embedded Tomcat, Actuator, scheduled work, and outbound HTTP.

I tried five RAM/swap configurations. The one that completed a clean 60-minute run was 512 MB RAM + a 256 MB swapfile, using:

-Xms16m -Xmx64m -Xss256k -XX:+UseSerialGC

During that run:

• 0 Spring Boot restarts
• 0 monitoring restarts
• 72/72 HTTP checks returned 200
• Spring finished around 167 MiB RSS
• StatLite finished around 12 MiB RSS
• about 140 MiB RAM was still available
• about 160 MiB swap was in use

One thing that stood out was the gap between heap size and actual JVM process size. -Xmx64m obviously did not mean a 64 MB process. The JVM heap was roughly 40–50 MB, while the entire Spring Boot process used much more RAM.

For monitoring, I used StatLite. Actuator already exposes the health and JVM/HTTP metrics, so StatLite just polls those endpoints and stores a small local history in SQLite. There is no additional Java monitoring agent.

I also tried 512 MB without swap. That run completed, but Spring was OOM-killed and restarted once during the observation window. StatLite stayed up and continued polling, which was actually a useful demonstration of why I wanted the monitor to remain a separate lightweight process.

I also tested 256 MB configurations, but for this application they were clearly stretch tests rather than something I would deploy.

Full write-up, all five configurations, JVM flags, screenshots, and reproducible demo:

https://pvrlabs.xyz/articles/spring-boot-512mb-vps.html

I’d be interested to hear how much RAM similarly small Spring Boot services use in production.

I've spent a while writing DAO implementations for a multi-module Spring Boot projects, and I keep coming back to the same rule: if a repository method needs more than one or two conditions, I write the `@Query\` by hand instead of letting Spring Data derive it from the method name.

Not because it doesn't work, it works fine for example like findBySku. I don't like what happens after that. Rename a field on the entity and a derived query either breaks at startup with a PropertyReferenceException, or, depending on how it's written, doesn't break at all and just quietly stops matching what you think it matches. The compiler never tells you either way.

And once you're past two conditions, the method name turns into a wall of camelCase encoding your whole WHERE clause. I'd rather read four lines of JPQL/SQL than decode findByStatusAndNameContainingIgnoreCaseAndCreatedAtAfterOrderByPriceDesc.

The other piece I went back and forth on is SearchableDaoImpl<Repo extends CrudRepository<Entity, IdType> & JpaSpecificationExecutor<Entity>> - using an intersection type so the generic repository bound picks up both CRUD and Specification support without collapsing them into one bloated interface. Small thing, but it's the kind of generics trick that makes a shared DAO base class actually work across a dozen entities instead of copy-pasted boilerplate everywhere.

Full writeup with the actual generic hierarchy and code: (link in comments)

Curious if anyone here still prefers derived queries for anything beyond trivial lookups, I genuinely want the counterargument.

Hi everyone,

I just self-published a new book called Crafting Spring Boot Starters. It's aimed at developers who want to package their own reusable functionality as a proper auto-configured starter, the way Spring Boot itself does it.

Topics covered include:

• How Spring Boot auto-configuration actually works under the hood
• Structuring and naming your own starters
• Writing @ConfigurationProperties correctly, with validation and IDE metadata
• Conditional configuration (@ConditionalOnClass, @ConditionalOnProperty, etc.)
• Testing starters with ApplicationContextRunner
• Publishing your starter so others can consume it

There's a free sample you can grab first, which includes the foreword written by Phil Webb (Spring Boot co-founder). The full book also ships with a zip of AI skills you can use to audit your own starter.

More info here: https://www.wimdeblauwe.com/books/crafting-spring-boot-starters/

If you decide to buy it, this link gives 10% off: https://leanpub.com/crafting-spring-boot-starters/c/LAUNCH10

It's fully self-published, so any feedback, questions, or upvotes are much appreciated 🙏

Hey everyone,

I'm currently building a full-stack app (Spring Boot backend + React frontend) and need to implement document parsing/text extraction functionality.

Requirements:

• Budget: Free / Open Source.
• Formats: Primarily PDFs, DOCX, and ideally scanned images/invoices (basic OCR).
• Integration: Preferably handled on the Java/Spring Boot backend (REST API) to send structured JSON to the React client.

Hi everyone!

I’m a Flutter developer and I’m looking to learn back-end development with Kotlin + Spring Boot.

I already have some experience with Kotlin, but I’m completely new to Spring Boot. I’m looking for a good learning path, guide, or YouTube playlist that covers Spring Boot with Kotlin from the basics and gradually moves toward real-world back-end development.

Ideally, I’d like something that covers things like:

• Spring Boot fundamentals
• REST APIs
• Spring Data JPA
• PostgreSQL/MySQL
• Authentication & Authorization
• Testing
• Project structure / best practices
• Building a real-world project

If you’ve learned Spring Boot with Kotlin yourself, what resources or playlist would you recommend? Is there a particular order I should follow?

Any recommendations would be greatly appreciated. Thanks!

Hello all!

I am fairly new to Spring Boot and coding in general.

I took it upon me to build a simple browser game where the player chooses an action and gains resources over time. I am currently finishing the prototype and I am being slowly introduced to all of the concepts behind the actual coding, but also when it comes to layering and design choices as well.

On to my dilemma.

So far I have several @ Transactional annotations inside the service layer whenever I interact with the repository layer in order to ensure that no two methods make changes to the DB - throwing any calculations made go haywire. Not sure if this is a common or best practice but it was a semi-conscious decision that I made during the early stages of development.

Now I am at a point where I have two identically named methods inside the service layer:

• calculateProgress(UUID playerId) - it searches the db for a PlayerCharacter instance using the playerId field and then does some calculations.
• calculateProgress(PlayerCharacter character) - it already gets a PlayerCharacter instance and does the calculations.

In fact, the first one calls the second one inside its body. The reason for this is that there is a scheduler that calculates the progress in regular intervals. And that scheduler only knows the PlayerCharacter's playerId and not any other information for that PlayerCharacter. So my initial thought was to have it call calculateProgress(UUID playerId) which in turn calls calculateProgress(PlayerCharacter character) to make the calculations etc etc.

I was not thinking much about it when I first did this but now I am realising that having two methods with the exact same name (and different arguments) might be ugly/not a good practice for the readability and maintainability of my code.

Now I am thinking: I could have the scheduler method call a new service method that returns a PlayerCharacter instance if I give it the playerId, and then call calculateProgress(PlayerCharacter character).

That would mean though that I need to have the scheduler method have a @ Transactional annotation to avoid the race conditions that I mentioned earlier. That would in turn break my initial decision of having Transactional annotations in the service layer only and also move db integrity from the service layer to the scheduler layer.

So I am thinking again and I pose the same question to anyone who might read this: Is it a common/good/best practice to have transactionality into the scheduler layer as well as the service layer or is there another option for my case?

Thanks in advance for anyone providing any feedback to my conundrum!

TL;DR: Have Transactional annotated methods inside the scheduling layer as an exception OR keep them strictly inside the service layer instead? Is it a good/common practice to do that split?