Four ways to map a Java bean, one JMH harness, real numbers. MapStruct costs almost nothing over hand-written code. One of the others is about 300x slower. Here is which, and when it matters.
Do Java virtual threads make a Spring Boot app faster? I load-tested the same app both ways on real AWS hardware. The honest answer: below saturation they do nothing, on CPU-bound work they do nothing, and where they win on blocking I/O, a properly tuned platform pool matches the throughput. The real case for virtual threads is not raw speed, it is having no pool to tune and a cheaper thread.
AWS says Graviton gives up to 40 percent better price-performance. I put the same Spring app on same-rank Intel, AMD, and Graviton instances and measured it. It is true, I got 43 to 60 percent, but the reason is not that Graviton is faster. It is cheaper, and same vCPU does not mean same cores.
Most database optimization guides hand you a list of ten techniques and skip the one question that matters: which problem do you actually have? Here is the diagnosis-first version. Find the real bottleneck, then apply the cheapest fix that clears it.
I benchmarked both. Locally, Redis at 0.86ms was no faster than hitting the database. Move the database away and it wins. How to pick, with numbers.
Most teams reach for sharding years before they need it. There is a ladder of cheaper, lower-risk fixes that comes first, and the right rung depends on which bottleneck you actually have: read load, write load, or data size. Here is the ladder, from cheapest to last resort.
