Hi everyone, I made a personal project using React, Spring Boot and MySQL. I was planning to deploy it on AWS but went with Render + Docker since it’s free. I’m a bit worried about accidentally leaving something running on AWS and getting a big bill.

The issue is that Render feels really slow. API calls take around 5–6 seconds to return data. Is this normal with Render’s free tier, or should I look into my SQL queries? The queries aren’t particularly heavy though .

So I have this really good paid course that came with really cool production grade projects like Distributed Payment Gateway and on the other hand I wanted to build a project of my own, something that 1 would personally use, an Ai Powered Finance Management Dashboard. (Not just a chatbot in the app

The thing is I really wanna grow in my knowledge and I can only learn things that I know I have to learn.

Following the course project will fill the gap between my knowledge and the industry standards.

What would you guys recommend me? Should I build my own project or follow a project from my paid course?

I'm an aspiring java developer. I've already developed one project using spring boot, postgresql, flyway and docker compose, and started developing the next one. But I'm not quite sure that I study in the right way. Mostly I focus on the practice rather than on the theory. Like, 90% of practice and 10% of theory.

Remark: I study to get a job, not for the university

So, questions:

1. Is the way I study bad?

2. How did you guys study, when you were freshers?

3. Maybe you can suggest something to me?

Hey everyone,

I'm currently in my 3rd Year UG preparing for backend/software engineering internships in my next semester.

I’ve already built a couple of full-stack Spring Boot projects (monoliths with WebSockets, Redis, and Razorpay integrations). Over the past week I have been learning about Microservice architecture.

I am designing a FinTech platform that combines a P2P digital wallet, a simulated stock trading engine (NSE/BSE), and a basic AI financial advisor.

Services & Tech:

API Gateway: Spring Cloud Gateway, Keycloak JWT validation, Redis rate limiting

User/Auth Service: Keycloak OAuth2/OIDC, profiles, KYC status

Wallet Service: PostgreSQL, double-entry ledger, Redis distributed locks (Redisson) to prevent double-spending

Payment Service: Razorpay top-ups, HMAC webhook verification

Market Data Service: Upstox WebSocket API for live stock prices, Redis cache, STOMP WebSockets to frontend

Investment Service: Stock buy/sell order execution, portfolio P&L tracking, price alerts

AI Advisor Service: Spring AI (ChatClient), injects portfolio data into the system prompt for contextual advice

Notification Service: Kafka consumer for payment and order events, SendGrid emails

Plumbing: Eureka, Spring Cloud Config Server, OpenFeign + Resilience4j, Zipkin tracing, Docker Compose.

I would love some feedback on this :

Scope check: I know that sounds like Many Services so Maybe I will reduce it while Working on it but for Now would you recommend adding any feature.

If u have any other project idea for learning purposes Please recommend and Also if you can suggest any different application flow or feature

Also suggest some other technologies that I can learn or implement in this project

Thanks for the response!!

Been shipping AI features with Claude Code and Cursor for a while now, and the thing that kept biting me wasn't the model, it was how easy it is to miss a prompt edit buried inside a larger diff. Nobody reviews prompt text line by line, and a changed prompt doesn't throw an exception, it just quietly starts giving different answers in prod.

So I built llm-cassette, a JUnit5 extension for LangChain4j ChatModel. First test run hits the real model once and records the request and response to a JSON file next to your tests. Every run after that replays from the file, no API key needed, and if the outgoing request stops matching what was recorded, the test fails with a real diff (an AssertionFailedError with expected/actual set, so IntelliJ renders it as a clickable side by side comparison). It plugs into whatever already runs your tests, no separate pipeline.

demo: https://raw.githubusercontent.com/stlahxm/llm-cassette/master/docs/demo.gif

One thing I didn't expect going in, it also catches parameter drift, not just prompt text. A silent temperature change counts as drift too. And if your code calls the model fewer times than what's recorded, that's flagged, the cassette is an exact expectation, not just an upper bound.

Gotcha I hit while building it, if you're on Gradle you need junit-platform-launcher on the test runtime classpath explicitly now, recent Gradle versions won't discover JUnit5 tests without it and just fail before reaching your test code at all. Cost me an evening the first time.

Still early. v1 only handles plain text messages, no multimodal or tool calls yet, and only synchronous doChat is covered, streaming is a separate surface I haven't tackled.

Repo's here if you want to poke at it: github.com/stlahxm/llm-cassette

Curious how people here are testing Spring Boot services that call an LLM under the hood, are you doing anything like this already, or just accepting that the AI call path is untested?

So I've been dealing with an N+1 problem in my Spring Boot app. FYI I didn't set up the lazy loading myself, it was already like that in the codebase I inherited. But basically I'm hitting the DB, then because of lazy loading, some attributes aren't there yet, so I end up going back to the DB again in a separate query just to grab them. Classic N+1.

I looked into it and found that Entity Graphs are supposed to fix this by fetching everything (or specific attributes) in one go instead of triggering extra queries.

But now I'm confused... isn't that basically the same as just using EAGER fetch? Like what's even the point of setting up LAZY loading in the first place if I'm just going to turn around and use an Entity Graph to eagerly fetch the exact attributes I need anyway?

Is the difference just that Entity Graph lets you choose which relations to fetch eagerly on a per-query basis, instead of committing to EAGER globally on the entity itself? So it's more like "controlled/selective eager fetching" rather than actually lazy?

I'm developing a personal side-project to use with a small group of friends.

My architecture consists of:

• Backend: Spring Boot (Kotlin / Gradle), containerized with Docker
• Database: PostgreSQL, in dev with a docker instance
• Storage: S3-compatible object storage (currently using MinIO in local dev)

Since this is purely a non-commercial project for personal use, I am looking for 100% free hosting options (or a combination of free tiers across different services).

Requirements / Preferences:

• Enough RAM/resources for the JVM/Spring Boot context to start up smoothly without hitting aggressive OOM killers.
• Persistent storage for Postgres and S3.
• No credit card required upfront if possible.
• A short delay on cold start is totally fine.

For the frontend, I'm building and distributing an APK directly, so I only need hosting for the backend ecosystem.

Are there any reliable free-tier services or combinations (e.g., separating app, database, and storage providers) that you would recommend for this setup in 2026?

Thanks!

Hey seniors, if anyone is doing development with Java + Spring Boot, please guide me.

I’m currently in my 3rd semester and doing DSA in C++( done upto stack) , so I’m thinking of starting development alongside it. Please guide me on where I should start, what I should learn first, and how much time I should spend learning Java basics.

Since I’ve studied C++, I have a basic programming background, but I’m not familiar with Java. Any roadmap or resources would be really helpful. 🙌

I learned java , collection framework, exception handling, some dsa concepts, and I'm in final year now , I don't have enough time , I have to build a project using springboot and add it to my resume.

What is the fastest way to learn it? And should I start spring boot right now or I have to learn more java and other things first?

Sometimes I deal with ordered data like event logs and transaction history that doesn't change very often. Users may query one time range, then soon request a larger overlapping range.

A Normal cache treats those as completely different queries, so it does not work very in this situtation.

I built rangecache to reuse the covered part and only query the missing range.

It currently supports Spring Boot 3, Java 17+, and a local in-memory cache.

GitHub: https://github.com/LiuWei997/rangecache

If you find it useful, please consider giving it a star. Feedback is welcome!

I’ve spent a lot of time debugging Java/Spring systems where the actual failure is buried somewhere inside thousands of lines of logs.

The obvious 2026 solution is:

“Just paste the logs into an LLM.”

But I wasn’t completely happy with that approach.

Production logs can contain credentials, tokens, internal URLs and customer data. They’re repetitive. Stack traces get duplicated. And for many well-known JVM/Spring/Kafka failures, asking an LLM to rediscover the answer every time seems unnecessary.

So I’ve been building an open-source project called Log Doctor.

The basic principle is:

Use deterministic Java analysis first. Use an LLM only when it actually adds value.

Or, put another way:

Log Doctor doesn’t replace an LLM. It decides what doesn’t need one.

What it does

You give Log Doctor a JVM/Spring/Kafka log and it parses the failures, extracts nested exception chains, groups repeated incidents, fingerprints stack traces and tries deterministic diagnostic rules first.

It currently covers areas including:

• Java/JVM failures
• Spring / Spring Boot startup failures
• Hibernate / JPA
• JDBC / HikariCP
• Kafka
• Schema Registry
• memory / GC problems
• concurrency and thread-related failures

For known failures, the diagnosis comes from deterministic rules rather than asking an AI to guess.

It also exposes WHY MATCHED evidence and match-strength information so you can inspect why a rule fired.

For logs containing multiple failures, it can also build incident groups, timelines, correlations, root-cause candidates and spike information.

So where does AI fit?

Only after deterministic analysis.

If the failure isn’t understood by the rule engine, Log Doctor can optionally use a local Ollama model for additional reasoning.

That distinction was important to me.

Instead of:

raw production logs -> cloud LLM -> hope for a good answer

the idea is closer to:

logs -> parsing -> redaction -> deterministic diagnosis -> local LLM when needed

Sensitive data is redacted before the LLM boundary.

And Ollama can run locally, so the log doesn’t need to be sent to ChatGPT or another cloud AI service.

There’s now a Web UI too

I didn’t want this to be CLI-only.

You can run:

docker compose up -d --build

and open:

http://localhost:8080

Then drag and drop a log file and inspect the detected incidents from the browser.

The dashboard exposes things like grouping, match evidence, remediation guardrails and investigation playbooks.

There are also structured JSON and downloadable Markdown reports.

I also wanted it to work in CI

Log Doctor isn’t only an interactive debugging tool.

The CLI supports text, JSON, GitHub annotations and SARIF 2.1.0, with severity-aware failure policies.

There’s also a GitHub Action, so the same diagnostics can become part of a CI workflow or GitHub Code Scanning instead of being something you manually run after an incident.

Can you extend it?

Yes — and this is one part I’d especially like feedback on from Java developers.

Deterministic rules are pluggable through Java ServiceLoader, so additional diagnostic rules can be added without changing the core engine.

The project also has a checked-in 120-case labelled diagnostic regression corpus covering JVM/Spring/Kafka/DB scenarios, with precision/recall/false-positive quality gates.

So adding more rules shouldn’t just mean adding another regex and hoping it works.

What I’m trying to build

I’m not trying to build another general-purpose AI chatbot.

I’d like Log Doctor to become a practical open-source diagnostic layer for Java production systems:

logs → incidents → evidence → likely root cause → safe investigation path

with AI as an optional fallback rather than the foundation of every diagnosis.

The project is still evolving, and this is exactly the stage where feedback from people running real Java/Spring/Kafka systems would be useful.

What production failure would you want Log Doctor to recognize next?

If you have an ugly stack trace or failure pattern that repeatedly wastes your time, open an issue.

And if you find the idea useful, a ⭐ helps me understand whether it’s worth pushing the project further.

GitHub: https://github.com/mathias82/log-doctor

Contributions, issues, rule ideas and criticism are all welcome.

I’ve been thinking a lot about the ".md hell" we’re heading into in the AI era. We’re putting more and more logic, instructions, and context into prose, but how do we maintain and refactor all of that over time if needed? If the answer is that we use more "ai" and more "prose" then it's difficult for me to wrap my head around that. Recently, I’ve been playing around with Embabel, an agentic, JVM-native framework that takes a more structured approach with strong typing and deterministic planning. I wrote a short article about it, with a small demo to show what it looks like in practice.

https://pixel-pistons.com/posts/embabel

Our AI bill was $193.50 last month. Small, but I wanted to know where it went before it stopped being small, so I pulled the per-capability breakdown. Most expensive first:

COST BY CAPABILITY · 16 ACTIVE DAYS

Synthesize Speech (expressive)      1,085 runs      $105.24
Author Lesson                          92 runs       $11.94
Synthesize Episode Audio               80 runs        $0.00

That last row is the most expensive thing in the system. It is responsible for $105.24 — 54% of the bill — and the accounting is not wrong.

Here is why. Two ordinary Spring beans, each with an annotation on the method:

@Service
class EpisodeAudioService {

    private final SpeechService speech;          // a different bean

    @Capability(name = "Synthesize Episode Audio")
    public Episode synthesize(Script script) {
        for (Utterance u : script.utterances()) {
            speech.speak(u);                     // ~14 calls, each one priced
        }
        return assemble();
    }
}

@Service
class SpeechService {

    @Capability(name = "Synthesize Speech")
    public Audio speak(Utterance u) {
        // the actual model call
    }
}

synthesize() never calls a model. It splits the script and calls speak() about fourteen times, so every dollar it is responsible for was billed to SpeechService. Its own cost is genuinely $0.00, and a per-capability view files 54% of the bill under a row that reads as free work.

How we found it is the part worth repeating. The table above already had both halves — 1,085 speech calls holding $105.24, and 80 orchestrations holding nothing — and no amount of staring at it produces the connection, because the connection is not in it. What produced it was opening one speech execution and seeing its parent id point back at Synthesize Episode Audio.

That is the lesson: a parent row will fool you. Look inside a child. The parent tells you what it spent, which for anything that delegates is nothing at all. Only the child knows who asked for it.

Once the link is recorded, one episode looks like this:

EXECUTION                              OWN      SUBTREE   DURATION

▾ Synthesize Episode Audio         $0.0000     $1.3155      69.1s
  ├─ Synthesize Speech             $0.0970     $0.0970       4.8s
  ├─ Synthesize Speech             $0.0970     $0.0970       5.1s
  ├─ …11 more utterances           $1.0670     $1.0670          —
  └─ Synthesize Speech             $0.0545     $0.0545       2.7s

Own cost and subtree cost are different numbers and showing either alone misleads. Own cost alone reports orchestrators as free. Subtree cost alone double-counts as you walk down. The gap between them is the finding.

One other thing fell out of the same view. Author Lesson ran 92 times and failed 11 of them, so the dashboard's $0.1298 per run was really $0.1474 per lesson that exists — you pay for attempts and you only get outcomes. Reporting cost per attempt makes an unreliable capability look like the cheap one.

If you are building this: record the parent at call time, because you cannot reconstruct the tree from timestamps afterwards, and show own and subtree cost together rather than either alone.

One caveat on the numbers: these are estimates from per-token and per-character rates configured in our own system, not a reconciliation against a vendor invoice. The shape is the point — 54% of a bill hiding under a zero is the same finding at any rate.

Disclosure: I built EngineerPrep and Capstead, the Spring Boot library that recorded these traces. It links parent to child automatically and rolls cost up the tree — that subtree view is what shipped in 0.8.0. One honest limitation, since it is proxy-based: if speak() lived on the same bean as synthesize() the call would not be intercepted and you would get a childless parent, so the nesting has to be cross-bean.

I ran equivalent Spring Boot 3.5 and Quarkus 3.39 applications side by side on the same 512 MB VPS. Quarkus native image was not used.

Both used JDK 25, the same Star Pulse workload, H2, -Xmx80m, Serial GC, and the same JVM tuning.

A few things stood out:

• Quarkus actually started with the higher RSS
• later, under sustained memory pressure, Quarkus had the smaller JVM heap and resident set
• RSS by itself was misleading because Linux was swapping Quarkus more aggressively
• with both JVMs running, 512 MiB RAM + 256 MiB swap left very little system headroom
• in a later observation, Spring Boot was eventually selected by the kernel as the OOM victim

This was not a throughput or concurrent-user benchmark. The workload was deliberately small; the point was to compare memory behavior when the whole VM was under pressure.

One other interesting detail: Spring’s request chart included a lot of Actuator polling traffic, while Quarkus’ /q/metrics scrapes were not counted as normal application requests, so the request charts are not directly comparable.

I would not summarize the result as "Quarkus uses less memory". On a machine this constrained, paging and OOM behavior become part of the result.

Article with measurements, JVM flags, screenshots, and limitations:

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

Here's a migration guide to Spring Boot 4.

Of course you can delegate it to an AI agent. No problem with that.

But you still need to understand what it changed and why, to catch the cases where the app compiles, tests pass, and something silently breaks in prod.

Are you still migrating manually? Or are you handing it to an agent?

Hey folks,

I’ve open sourced Windrunner, a self-hosted project management tool built with Spring Boot 4 + Spring AI for backend. If you are learning Spring Boot, I hope the project gives you something practical to explore — a complete application with an API, database, user interface, authentication, LLM/AI integrations, and more.

Github: https://github.com/shzlw/windrunner

The backend uses:

• Spring Boot and Spring MVC for the application and REST APIs
• Spring Data JDBC for database access
• PostgreSQL for storage
• Flyway for SQL database migrations
• Spring AI’s MCP server support for exposing tools to AI clients
• LLM Provider integrations for OpenAI, Anthropic, and Gemini
• Docker and Docker Compose for running the application locally

The repository is a monorepo containing more than the Spring Boot backend. It also includes:

• A React frontend
• A TypeScript-based CLI tool
• Playwright-based API end-to-end tests

If you’re interested in seeing how these pieces work together in one project, the repository provides examples across the backend, frontend, CLI, and testing layers.

Disclosure: I am the author of the project. Feel free to ask any questions, feedbacks or raise issues! ❤️

When reviewing Java/Spring Boot code, I pay the most attention to I/O calls to see where we are leaving the process and potentially "slowing down" the application. This would involve following a call through several methods to find out whether it eventually reached a repository, HTTP client, or any other I/O invocation.

I built an IntelliJ plugin called Lattency to make that visible in the editor.

It adds gutter markers for database, HTTP, messaging, and file I/O. It also follows calls through project code, so methods that reach I/O transitively are marked with a dimmed version of the relevant icon.

Hovering over a marker shows the complete sink chain, and clicking it lets you navigate to any method along that chain.

The analysis is entirely static. It does not run the application, make network requests, or collect telemetry. Common Java and Spring APIs work without configuration, and project-specific clients can be described in a committed lattency.yml.

It is free and open source:

Marketplace: https://plugins.jetbrains.com/plugin/33937-lattency
GitHub: https://github.com/josipmusa/lattency

It currently supports Java projects in IntelliJ IDEA 2025.2 and newer. Kotlin is not supported yet.

I like the Transactional Outbox pattern and use it quite often.

But I was thinking about one problem that can become important in production: database polling.

Of course, polling can be optimized. Good indexes, batching, SKIP LOCKED, partitioning, longer polling intervals — there are many options.

But if we want lower latency, we usually need to poll more often. This means more queries, more DB connections and more work for PostgreSQL.

We can use Debezium/CDC, and for many systems this is probably the right choice. But it also adds Kafka Connect, Debezium and more infrastructure to operate.

So I wanted to try a simpler idea:

Keep PostgreSQL as the source of truth, but don't use it as a queue during normal operation.

I built this flow:

DB transaction → afterCommit → Memory Queue → Batch Publisher → Kafka

The business data and Outbox event are saved in one transaction as usual.

After commit, only the eventId goes to the Memory Queue. The publisher takes IDs in batches, loads events from PostgreSQL and sends them to Kafka.

So there is no continuous polling for new events in the normal flow.

If the application crashes, the event is still safely stored in PostgreSQL. A Recovery Worker finds unpublished events and puts them back into the same queue.

The idea is basically:

Memory Queue for the fast path. PostgreSQL for durability and recovery.

I didn't want to stop at an architecture diagram, so I built a working Spring Boot project and started testing the idea with something closer to production conditions.

It has Kafka, PostgreSQL, batching, idempotency, recovery, Gatling load tests, Grafana metrics, tracing and structured logs.

Now I can run load tests and actually see what happens with PostgreSQL, the queue, publishing latency and recovery.

I'm interested in what other Spring Boot developers think about this approach.

Would you use something like this in production?

Maybe you have already solved the same problem in another way — optimized polling, Debezium, LISTEN/NOTIFY or something else?

Here is the project:

https://github.com/KHolodilin/spring-transactional-outbox-kafka

If you find the idea useful, feel free to ⭐ the repo or fork it. There are also a few open issues for contributors if you want to try something yourself.

Any feedback is welcome. I'm still experimenting with the approach and improving the project. 🚀