Many developers assume @Transactional works across microservices — but it doesn’t. In Spring Boot, @Transactional ensures ACID properties (Atomicity, Consistency, Isolation, Durability) only within a single service and single database transaction boundary. In banking workflows like Account → Transaction → Loan → Notification, multiple services participate, so local transactions alone cannot maintain consistency. Challenge (Banking Project) Maintaining data consistency across distributed financial services when partial failures occur between services. Solution implemented Used Saga Pattern with Kafka (event-driven choreography) • Each service handled its own local ACID transaction • Events triggered downstream services asynchronously • Compensation logic handled rollback scenarios • Transactional Outbox ensured reliable event publishing Outcome ✔ Achieved eventual consistency across services ✔ Prevented partial transaction failures ✔ Improved resilience in high-volume transaction processing ✔ Enabled independent deployment of microservices Key takeaway: @Transactional guarantees ACID within one service. For distributed transactions, use Saga + Kafka. #Java #SpringBoot #Microservices #Kafka #SagaPattern #DistributedSystems #BankingTech
Postgres provides advisory lock, best in distributed systems. Its application-defined locks that allow developers to implement custom synchronization logic at the database level without locking actual tables or rows
Good point. Postgres advisory locks are useful for coordinating concurrency within a single database. 👍 However, they don’t solve cross-microservice consistency since each service typically has its own DB. For distributed workflows like Account → Transaction → Loan → Notification, Saga + Kafka handles failures and rollback across services more effectively.