Jfokus 2018: Lost in transaction - Strategies to deal with (in-)consistency in modern architectures
•
2 likes•884 views
The document discusses the challenges of distributed systems including asynchronicity, failures, and transactions. It recommends using circuit breakers to handle failures gracefully, workflow engines to manage state and retries across services, and event-driven architectures with compensation for eventual consistency when transactions span multiple services. The document provides examples of how these approaches can help solve common problems in distributed systems.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Jfokus 2018: Lost in transaction - Strategies to deal with (in-)consistency in modern architectures
Similar to Jfokus 2018: Lost in transaction - Strategies to deal with (in-)consistency in modern architectures (20)
More from Bernd Ruecker
More from Bernd Ruecker (20)
Recently uploaded
Recently uploaded (20)
Jfokus 2018: Lost in transaction - Strategies to deal with (in-)consistency in modern architectures
- 1. Lost in transaction mail@bernd-ruecker.com | @berndruecker http://bernd-ruecker.com/ Co-Founder & Developer Advocate
- 2. REST, SOAP, Cloud, Saas, Microservices, SCS, FaaS, Serverless, …
- 4. Distributed systems Challenges of asynchronicity Distributed Transactions Communication is complex
- 6. Some Service Some Service Some Service Some Service Some Service Some Service Some Service But keep it local! Be resilient. Failure will happen. Accept it!
- 7. Let‘s start with a simple example Credit Card Payment REST
- 8. Circuit Breaker Photo by CITYEDV, available under Creative Commons CC0 1.0 license.
- 9. Live hacking Getting from https://github.com/flowing/flowing-retail/blob/master/payment- rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV1.java to V2
- 11. Fail fast is important but not enough!
- 12. Photo by Tookapic, available under Creative Commons CC0 1.0 license.
- 13. „There was an error while sending your boarding pass“
- 15. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt Current situation - the bad part Stateful Retry
- 16. „There was an error while sending your boarding pass“
- 17. We are having some technical difficulties and cannot present you your boarding pass right away. But we do actively retry ourselves, so lean back, relax and we will send it on time.
- 18. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt Stateful Retry Possible situation – much better! The failure never leaves this scope!
- 19. Persist thing (Entity, Actor, …) State machine or workflow engine Typical concerns DIY = effort, accidental complexity Complex, proprietary, heavyweight, slow, developer adverse Scheduling, Versioning, operating, visibility, scalability, … Handling State
- 20. State machines or workflow engines CADENCE
- 21. Live hacking Getting to https://github.com/flowing/flowing-retail/blob/master/payment- rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV3.java
- 22. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt Workflows live inside service boundaries
- 27. generateBoardingPass HTTP 200 OK HTTP 202 ACCEPTED Check-in A synchronous response is possible in the happy case, otherwise it is switched to asynchronous processing.
- 28. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt „Eh – no!“ “The customers want synchronous responses!”
- 29. Synchronous communication is the crystal meth of distributed programming Todd Montgomery and Martin Thompson in “How did we end up here” at GOTO Chicago 2015
- 31. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt Asynchronous communication You need to monitor timeouts
- 32. Check-in 3D- Barcode Generator Web-UI Me Output Mgmt Remember… The failure never leaves this scope!
- 33. Workflow…
- 34. Workflow…
- 35. Duplicates Duplicates 857621972_ded037d1db_b.jpg Photo by oz dean, available under Creative Commons BY 2.0 license.
- 36. It is impossible to differentiate certain failure scenarios. This is also true for synchronous request/response! Service Provider Client
- 37. has to implement Timeout, Retry has to implement Idempotency Client Service Provider
- 38. We are processing your payment. Do not leave this page. And for god sake – do not reload! It is a business problem anyway! We are currently processing your request. Don‘t worry, it will happen safely – even if you loose connection. Feel free to reload this page any time!
- 39. Who has no problems operating a message bus? Dead messages | No context | Inaccesible payload | Hard to redeliver | Home-grown message hospitals | …
- 44. Business transactions (aka Saga pattern) Compensation
- 45. Eventual consistency Temporarily inconsistent state But only temporarily!
- 46. Live hacking Getting to https://github.com/flowing/flowing-retail/blob/master/payment- rest/src/main/java/io/flowing/retail/payment/port/resthacks/PaymentRestHacksControllerV6.java
- 47. has to implement Timeout, Retry, Compensation has to offer Compensation has to implement Idempotency Client Service Provider
- 48. has to implement Timeout, Retry, Compensation has to offer Compensation has to implement Idempotency Client Service Provider
- 49. Event-driven example also available InventoryPaymentOrder ShippingCheckout Monitor https://github.com/flowing/flowing-retail/ Human Tasks H2 H2
- 50. Workflows live inside service boundaries* *in DDD: Bounded Contexts
- 51. # Understand complexity of distributed systems # Know strategies and tools to handle it e.g. Circuit breaker (Hystrix) Workflow engine for stateful retry, waiting, timeout and compensation (Camunda)
- 52. Thank you!
- 53. Contact: bernd.ruecker@camunda.com @berndruecker Slides: https://bernd-ruecker.com Blog: https://blog.bernd-ruecker.com Code online: https://github.com/flowing https://www.infoq.com/articles/ events-workflow-automation With thoughts from http://flowing.io @berndruecker | @martinschimak