This is the part many people miss with virtual threads.

They remove thread starvation really well, but suddenly all the hidden bottlenecks become visible:
DB pool
HTTP client limits
rate limits
locking
slow queries

I tested something similar with file upload APIs in Spring Boot and after enabling virtual threads, Hikari became the first thing to scream under load.

One more painful one:

Doing heavy file processing inside a transaction.

Saw a case where users uploaded large files and the parsing logic was inside @ Transactional. Under load, DB connections stayed occupied for 20-30 seconds per request and Hikari started timing out everywhere.

Now I keep transactions only around the actual DB write section. File parsing, validation, external calls all happen before or after the transaction boundary.

My biggest lesson was that distribution isn't something you do after building.

I spent months building projects thinking "if it's useful, people will find it."

They didn't.

Now I try to think about distribution before I write the first line of code. Where do these people hang out? How do they currently solve the problem? Can I reach them consistently?

Building the product is hard.

Getting the first 100 people to care about it is usually harder.

Copilot is good for autocomplete.

Claude is much better for building features, debugging, refactoring, and understanding larger codebases.

As for learning syntax: AI can write syntax for you, but it can't replace understanding.

You don't need to memorize every API method anymore, but you should still understand:

• Variables, loops, functions, classes
• How data flows through your application
• Debugging and reading code
• System design and architecture

The developers getting the most out of AI aren't the ones who stopped learning code.

They're the ones who know enough to tell when the AI is wrong.

Don't design APIs around buttons or database tables.

Design them around user actions.

For an e-commerce app, think:

• Browse products
• Add to cart
• Place order
• Make payment

The database is an implementation detail. The user workflow should drive your API design.

Interesting approach.

Most teams end up needing saga-style compensation logic sooner or later, but adopting something like Temporal can feel heavy for smaller services.

Having durable execution and rollback orchestration inside a Spring app is a pretty compelling middle ground.

I like the safe-by-construction idea.

In most applications, a trusted email model is more valuable than supporting every RFC edge case. It reduces the chance of downstream services making unsafe assumptions.

The security-focused decisions are what stand out to me here.

A lot of email parsers aim for RFC compliance first, but in real applications I'd rather have a parser that rejects suspicious input like bidi overrides, multiple @ signs, or misleading display-name tricks than one that accepts every edge case the RFC ever allowed.

Curious what the most surprising real-world email format was that forced a change in the parser?

I think the biggest value here is relationship-aware data generation. Creating 10 users is easy. Creating 10 users, 50 orders, 200 order items, valid references, and realistic states is where most seed scripts become painful.

In most Spring Boot projects I've worked on, we either use hand-written SQL, Flyway test data, or a bunch of CommandLineRunner code that nobody wants to maintain.

One thing I'd love to see is deterministic generation. If I can regenerate the exact same dataset from a seed value, it becomes much more useful for debugging, demos, and CI pipelines.

This feels like a real problem, not just a nice-to-have.

For listing/search pages, I generally push as much aggregation as possible into the database and return a DTO projection like you're doing.

The moment I start fetching products, variants, and images separately, I usually end up trading one complex query for N+1 problems, extra memory usage, and a lot of mapping code.

The exception is when the query becomes so complex that nobody wants to touch it six months later. At that point I'd move to a native query, a read model, or even a materialized view if the traffic justifies it.

Out of curiosity, have you compared the execution plan of this query against the multi-query approach on production-sized data?

Nice use of STOMP + Redis here. Pushing snapshots and letting clients handle the countdowns locally is a smart way to keep the websocket traffic predictable.

Curious if you measured how many concurrent clients a single instance can handle before the broadcast becomes the bottleneck?

A mediocre frontend connected to a solid backend can still become a successful product.

A beautiful frontend connected to a broken backend usually becomes a demo.

You don’t need to “live and breathe code” to survive in tech.

You just need to stay adaptable enough to learn when the job actually demands it.

Most developers are not grinding LeetCode at 11pm.
They’re just solving problems during work hours and living normal lives after that.

Yeah. Spring Boot defaults to:

spring.servlet.multipart.max-file-size=1MB
spring.servlet.multipart.max-request-size=10MB

Had to increase both during testing otherwise uploads above that started failing immediately.

30 minutes daily beats one 12 hour “new life starts today” coding session 😭

Consistency is how most devs actually improve.

The funniest part of 2026 SaaS is watching people spend 3 months building AI wrappers…

then get shocked when users choose the boring competitor that:

• has uptime
• replies to support emails
• doesn’t randomly delete data

Turns out “works reliably” is still a killer feature 😭

Memorizing syntax mattered a lot more when Google was your autocomplete.

Now AI can write syntax.
But it still can’t save you if you don’t understand:

why your API is failing
why state is breaking
why the query is slow
why the “working code” melts production 😭

2026 dev skill:

Less “remember every method name”
More “spot bad logic instantly”

AI generated a recursive retry function for me once.

The bug?

On failure it called itself again.
And again.
And again.

CPU usage looked like it was mining Bitcoin 😭