Transaction Management in Microservice Applications

Transcript

1. Transaction Management in Microservice Applications Ahmet Pirimoğlu Solution Architect
2. Ahmet Pirimoğlu • 2006 yılından beri yazılım geliştirici • 15+ yıldır farklı sektörlerde • Finans Çözümleri • Yükseköğretim Çözümleri • Genellikle yazılım altyapı ekiplerinde • Yaklaşık 4 yıldır Dgpays • Şu an “Core Banking" projesinin yazılım altyapı takımında “Çözüm Mimarı"
3. Agenda •Microservices Challenges •Distributed Transaction Patterns •Implementation Strategies •Best Practices •Production Lessons Learned
4. Microservices Architecture What are Microservices? • Scalability • Flexibility • Fault isolation • Technology diversity Benefits • Independent, loosely coupled services • Each service owns its data • Communicate via APIs • Deployed independently • Technology agnostic
5. ACID Properties Monolithic Systems Microservices • Atomicity • Consistency • Isolation • Durability • ACID becomes complex across service boundaries • CAP Theorem: Consistency, Availability, Partition tolerance • Need for new approaches
6. Traditional Monolithic App Single database Simple transaction management
8. Microservice Challenges • Multiple databases/data stores • Network communication • Partial failures • Eventual consistency • No single point of control
9. Distributed Transaction Patterns
10. Two-Phase Commit Phase 1: Prepare phase - all participants vote Phase 2: Commit/Abort phase - coordinator decides
12. Saga Pattern Sequence of local transactions Each step has compensating action
13. 2PC vs Saga Özellik 2PC Saga Pattern Blocking Evet Hayır Locks Var Yok Performance Yavaş Hızlı Consistency Strong Eventually Microservices Uygun değil Uygun Compensation Automatic rollback Business logic rollback
14. Saga Pattern Choreography: Event-driven coordination Orchestration: Central coordinator
15. Choreography- based Saga
18. Orchestration-based Saga
21. Orchestration vs Choreography Özellik Orchestration Choreography Koordinatör Var (Orchestrator) Yok İletişim HTTP/gRPC calls Events/Messages Akış kontrolü Merkezi Dağıtık Görünürlük Kolay izlenir Zor izlenir Coupling Orta Düşük Karmaşıklık Basit Karmaşık
22. Saga Orchestration Tools • Orkes Conductor (Netflix Conductor) • OpenSleigh (.NET Core için) • MassTransit (Saga desteği ile) • Temporal.io • Camunda / Flowable • Dapr Workflow • AWS Step Functions
23. Orkes Conductor
24. MassTransit 24
25. Camunda / Flowable
26. Best Practices
27. Outbox & Inbox Pattern
28. Handling Failures Types of Failures • Network timeouts • Service unavailability • Partial completion • Data inconsistencies Mitigation Strategies • Retry with exponential backoff • Circuit breaker pattern • Timeout configuration • Idempotent operations
29. Monitoring and Observability Metrics • Transaction success/failure rates • Average transaction duration • Compensation frequency • Service availability Tools • Distributed tracing (Jaeger, Zipkin) • Application Performance Monitoring (APM) • Custom business metrics • Log aggregation
30. Our Solution
31. Core Banking Platform • Microservice Application • CQRS & DDD • Dapr • DB & Cloud & Platform Agnostic • Code First Migration • BPM Process & UI Integration • 40+ Microservice & BFF Services • 40+ X Tenant Count Databases • Multi-DB Provider • PostgreSQL • Oracle • MS SQL Server
32. Camunda BPM Process
33. Expectations • Auto Commit / Rollback • No additional commit / rollback endpoint • Camunda Community edition not support process monitoring • Domain Priority • External Integration Commit / Rollback Support
34. BPM User Task
35. BPM Compensating Transaction • Main Table Fields • pending_type (N, I, U, D) • Compensating Kernel Module • Clean and Dirty Data Access • Transactional Event Handling • CorrelationId Commit Process
36. BPM Compensating Transaction • Single Table SPOF • Complexity in Rollback Logic • Incomplete Structure • Dirty Read Needs (Different Transactions)
38. Conclusion • Microservices require new transaction approaches • No one-size-fits-all solution • Choose patterns based on business needs • Design for failure from the start • Distributed Failures Management • Debugging and Tracing Difficulties • Data Integrity Risks
39. Teşekkürler pirimoglu@gmail.com https://www.pirimoglu.com https://twitter.com/ahmetpirimoglu https://www.linkedin.com/in/ahmetpirimoglu
40. Kaynaklar • https://microservices.io/patterns/data/saga.html • https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction • https://learn.microsoft.com/en-us/azure/architecture/patterns/saga • https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html • https://blog.bytebytego.com/p/the-saga-patternhttps://newsletter.systemdesignclassroom.com/p/every-outbox-needs- an-inbox • https://orkes.io/blog/saga-pattern-in-distributed-systems/ • https://temporal.io/blog/mastering-saga-patterns-for-distributed-transactions-in-microservices • https://dev.to/fauna/the-why-and-how-of-distributed-databases-4p1p • https://sefikcankanber.medium.com/saga-pattern-nedir-e4a447bef361