The Cost of @Transactional in SpringBoot

Day 18. I was using @Transactional everywhere. Thinking I was writing safe code. I wasn’t. I was slowing my system down. Every time you add @Transactional, you open a database connection. And you hold it. Until the method finishes. I had it on everything. Read methods. Write methods. All of it. Under load — it broke. Connection pool exhausted. API slowed down. Then stopped responding. That’s when it clicked. @Transactional is not protection. It’s a cost. I had code like this: @Transactional public UserDTO getUser(Long id) { User user = repository.findById(id).orElseThrow(); return new UserDTO(user); } No writes. Still holding a transaction. Completely unnecessary. So I changed it. (see implementation below 👇) What I learned: → Not every method needs a transaction → Read operations usually don’t → Write operations always do The hard truth: → @Transactional is overused → Most developers don’t know why they added it → It only shows under load Adding @Transactional is easy. Knowing when NOT to add it is what makes you a backend developer. Are you using @Transactional everywhere? 👇 Drop it below #SpringBoot #Java #BackendDevelopment #JavaDeveloper #Performance

  • text

Hot take: Most developers use @Transactional because it “feels safe”. Not because they understand it. Transactions are expensive. If you're using them everywhere, you're paying for it. Do you know where your transactions start and end? 👇

Like
Reply

To view or add a comment, sign in

Explore content categories