Moving beyond request reply - designing smarter APIs
1 like436 views
The document discusses the importance of resilience and idempotency in API design, particularly in distributed systems. It highlights the need for asynchronous communication to handle long-running services effectively while avoiding common pitfalls associated with synchronous calls. Additionally, it emphasizes the necessity of redesigning business processes to leverage smart APIs and maintain a balance between choreography and orchestration.
Moving beyond request reply - designing smarter APIs
- 1. Moving beyond request-reply: How smart APIs are different. @berndruecker
- 3. Some Service Some Service Some Service Some Service Some Service Some Service Some Service Failure will happen. Accept it! But keep it local! Be resilient.
- 4. Photo by Tookapic, available under Creative Commons CC0 1.0 license.
- 5. „There was an error while sending your boarding pass“
- 9. Check-in Barcode Generator Web-UI Me Output Mgmt Current situation – the good part Circuit breaker
- 11. Check-in Barcode Generator Web-UI Me Output Mgmt Current situation – the bad part
- 12. Check-in Barcode Generator Web-UI Me Output Mgmt Current situation – the bad part
- 13. Check-in Barcode Generator Web-UI Me Output Mgmt Current situation – the bad part Stateful Retry
- 15. 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.
- 17. Check-in Barcode Generator Web-UI Me Output Mgmt Possible situation – much better! Stateful Retry
- 19. Berlin, Germany http://berndruecker.io/ [email protected] @berndruecker Bernd Ruecker Co-founder and Chief Technologist of Camunda
- 20. Check-In You can use a workflow engine (=durable state machine)! Barcode REST Stateful retry
- 21. Want to see code? https://github.com/berndruecker/flowing-retail
- 22. has to implement Retry has to implement Idempotency Client Service Provider
- 25. Don‘t worry, it will happen safely – even if you loose connection. Feel free to reload this page any time!
- 26. Photo by pixabay, available under Creative Commons CC0 1.0 license.
- 27. Requirement: Idempotency of services! Photo by pixabay, available under Creative Commons CC0 1.0 license.
- 28. Requirement: Idempotency of services! Photo by Chr.Späth, available under Public Domain.
- 29. Make every service idempotent! Credit Card Payment Charge Credit Card cardNumber amount Charge Credit Card cardNumber amount transactionId Not idempotent Idempotent charge Generally: create Ids as soon as possible
- 30. Distributed systems introduce complexity you have to tackle! Credit Card Payment REST
- 32. It is impossible to differentiate certain failure scenarios. Independant of communication style! Service Provider Client
- 33. Distributed systems introduce complexity you have to tackle! Credit Card Payment REST
- 34. Distributed systems introduce complexity you have to tackle! Credit Card Payment REST Cancel charge
- 35. Being able to implement long running services is essential for smart APIs (on a technical level) @berndruecker
- 39. Example Booking Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker
- 40. Example Booking Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Rejected @berndruecker A few smart god services tell anemic CRUD services what to do Sam Newmann
- 41. Payment failed Who is responsible to deal with problems? Booking Payment If the credit card was rejected, the customer can provide new details Credit Card Retrieve Payment Rejected Payment received @berndruecker
- 42. Payment failed Long running services Booking Payment Credit Card Retrieve Payment Rejected Payment received Smart endpoints are potentially long-running @berndruecker
- 43. Being able to implement long running services is essential for smart APIs (on a business level) @berndruecker
- 44. Long running services require async communication
- 46. 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
- 47. Check-in Barcode Generator Web-UI Me Output Mgmt Asynchronous communication You need to monitor timeouts
- 48. Workflow…
- 49. Workflow…
- 50. Being able to implement long running services makes it easy to get async @berndruecker
- 51. Can your company leverage your hipster architecture? Shutterstock You need to change business processes and customer experience!
- 57. Weaknesses: Latency creep Payment Seat ReservationBooking Ticket Generation REST 300 ms 1150 + x ms 600 ms 250 ms
- 58. Weaknesses: Availabiliy erosion Payment Seat ReservationBooking Ticket Generation REST 99 % uptime 99 % uptime 99 % uptime 96 % uptime
- 59. And it is even hard to implement Payment Seat ReservationBooking Ticket Generation REST
- 60. And it is even hard to implement Payment Seat ReservationBooking Ticket Generation REST
- 61. Typical pattern Payment Seat ReservationBooking Ticket Generation REST Simulate synchronicty by waiting (callback or polling)
- 62. @berndruecker happy case failure case Redesign your business process accordingly! Or some interface to poll for status Sync in happy case Async response
- 63. @berndruecker Redesign your business process accordingly!
- 64. Your business processes need to be more reactive! @berndruecker https://www.reactivemanifesto.org/
- 66. Phil Calcado at QCon NYC 2019
- 67. API API API API API API API Microservices External Services Standard Software „What the hell just happened?“ @berndruecker
- 68. Example: order fulfillment via dash button Photo by 0xF2, available under Creative Commons BY-ND 2.0 license. https://www.flickr.com/photos/0xf2/29873149904/ @berndruecker
- 74. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
- 75. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
- 76. The danger is that it's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of that larger-scale flow, and thus set yourself up for trouble in future years. https://martinfowler.com/articles/201701-event-driven.html @berndruecker
- 77. Peer-to-peer event chains Checkout Payment Inventory Shipment Order placed Payment received Goods shipped Goods fetched Fetch the goods before the payment @berndruecker
- 78. Peer-to-peer event chains Checkout Payment Inventory Shipment Fetch the goods before the payment Goods fetched Order placed Payment received Goods shipped @berndruecker
- 79. What we wanted Photo by Lijian Zhang, available under Creative Commons SA 2.0 License and P..19 / CC BY-SA 4.0 @berndruecker
- 80. Order Extract the end-to-end responsibility Checkout Payment Inventory ShipmentPayment received Order placed Retrieve payment @berndruecker
- 81. Order Events & Commands Checkout Payment Inventory ShipmentPayment received Order placed Retrieve payment @berndruecker Event Command Fact, happened in the past, immutable Intend, Want s.th. to happen
- 82. Order It is not about the protocol! Checkout Payment Inventory Shipment Order placed Retrieve payment It can still be messaging! @berndruecker
- 83. Order It is about where to decide about the coupling! Checkout Payment Inventory Shipment Order placed Retrieve payment Order decides . to listen to the event . to issue the command @berndruecker
- 85. Workflows live inside service boundaries @berndruecker
- 87. Monolith Chaos Choreography Orchestration @berndruecker Process Monitoring Your services or applications
- 88. Your ITarchitecture Process Monitoring Monolith Chaos Choreography Orchestration Your services or applications Balance choreography and orchestration @berndruecker
- 89. . Distributed systems are complex. At-least-once, retries and idempotency are here to stay. Embrace async! . Long-running services make your life easier and your API smarter. . Change business processes and customer experience accordingly . Use commands + events = balance choreography and orchestration
- 90. Thank you!