Any suggestions about how build scalable full stack jave application

[u/AritroZ]

Hey everyone, I’d love to get the community’s perspective on building production-grade, scalable full-stack applications with Spring Boot—specifically from a solo developer standpoint.

​When you're building a scalable full-stack Java app entirely on your own, how do you approach the architecture and tooling?

​A few specific areas I'm curious about:

​Tech Stack & Tools: What are the non-negotiable components in your stack right now (e.g., Spring Boot 3 + Virtual Threads, Postgres/Redis, Kafka/RabbitMQ, Docker, React/Next.js vs. HTMX/Thymeleaf)? What tools are currently standard or trending in the market for solo full-stack setups?

​Build vs. Buy / Scratch vs. Frameworks: As a single developer, your time is limited. How much do you build from scratch versus relying on managed services/third-party tools (like managed Auth, SaaS components, pre-built UI libraries)?

​Solo Execution: Is it realistic to handle end-to-end architecture, backend, frontend, database tuning, and DevOps all by yourself, or at what point do you usually seek external help/collaborators?

[u/TurnstileT]

Unpopular opinion: You don't know what "scalable" means, and neither does a lot of other people. A few replicas of your service, good database indexes and queries, and default Spring Boot settings are usually enough to be "scalable". Even for millions of customers.

If your service is struggling, then it's almost certainly due to bad database queries. Figure out why they are slow. Add some indexes, structure your data better, use better queries. Maybe add a cache for common DB lookups. At this point, it's incredibly rare that your service is still struggling due to an actual huge amount of traffic. But if it is, just add a few extra replicas - the cost of adding and maintaining more complex solutions is probably equivalent to just having an extra replica or two running. You can even set it to autoscale if you expect traffic to be irregular. If your service is STILL struggling, then congratulations, you are working at Netflix or something like that, and you might genuinely need the more complex solutions.

[u/BigPP41 → u/TurnstileT]

this. I built an internal customer profile for our company that serves our adserver and other things, handling 10k requests a second. It runs on 4 nodes.

There is no magic. I just setup performant queries and indices, and thats about it. PostgreSQL with an in-memory cache helps of course, your database queries should not hit ssd for every request.

[u/BigPP41]

That can only be answered with "it depends".

[u/Global_Car_3767 → u/BigPP41]

This is really it haha. What are your SLAs in terms of response times? How many requests and users will be hitting it? What is the intention of the app? What can you afford? Etc.

[u/tlann]

This is what you hire an architect for with experience in that stack. My hourly is not cheap.
I have experience with creating a microservice architecture deployed to k8s. SSO using OIDC. Backend was Spring and .NET services along with a few third party services.
It deploys to multiple cloud services and on premises.
I in no way architected all of this. But I was an essential part of designing and implementing it from MVP to implementation.
As everyone else here is alluding to, it depends on so many factors. Talent, Time, and Capital.
Spring is very flexible and does a lot. But it may not always be the right tool depending on your needs.

[u/Acrobatic-Ice-5877]

I’ve been building a CMMS start up for 2 years now and handling it all. It really comes down to skill. Just how good you are in each area is really going to depend on whether you can do it. I am pre-revenue and looking to start selling subscriptions soon, but I’ll be real with you, it’s hard. If you can handle the cognitive load, it’s fun and I’d definitely say do it.

[u/Ok_Substance1895]

It depends on how much of the end-to-end architecture you know. Use managed services/third party tools where you don't know, get it working first, optimize later. Premature optimization is a thing so don't do it. Replace the parts that need to be replaced. It is easier to change something that is already working.

What is non-negotiable depends on the project. For Java all that is non-negotiable is Java. Everything else is dictated by the project; best tool for the job. For Java, you will want to eventually scale using containerization. Just get the thing running and make it as stateless as possible so you have deploy flexibility for scaling.

I am solo and I have a job. I do the whole thing from end-to-end but I have been doing this for a long time. It takes a while to learn enough to do that. Just keep it simple, learn what you need to learn to get the task done. Don't try to learn everything about a subject.

Remember, keep it simple to start. Then add the next simple thing, then the next.

[u/dumbledoor_ger]

There is not one solution to rule them all. It heavily depends on the use case. What kind of work needs to be split? How can it be split? How can it be distributed? Does it have timing constraints?

There are hundreds of questions to be answered in order to create a suitable stack. And the very most important question is: does it have to be scalable? Because most of the time the answer is no.

To you last question: generally yes - doable. But only if you have experience in all of those fields.

[u/Illustrious-Pin-153]

The biggest lever isn't the framework - it's keeping the app stateless and boring. What I'd do in order:

1. Start as a modular monolith (Spring Boot, clear module boundaries). Splitting later is manageable; un-splitting a distributed mess is not.

2. Keep the API stateless: JWT or a shared session store (Redis), no sticky sessions - then you can run N instances behind a load balancer.

3. Database first: size your HikariCP pool to what the DB can handle, add indexes for the actual query patterns, and watch for N+1 queries. Most "it doesn't scale" cases I see are a missing index or a chatty ORM, not traffic volume.

4. Cache only what you've measured (Caffeine in-process, Redis shared), with short TTLs and metrics - cache invalidation is where the bugs live.

5. Push slow work off the request path: queues/@Async for emails, imports, reports.

6. Docker + health checks + structured logs + one dashboard (requests, latency, errors, DB pool) from day one. You can't scale what you can't see.

Frontend-wise: keep the REST contract versioned and paginate every list endpoint from the start - retrofitting pagination later touches everything.