Moving beyond request reply - designing smarter APIs
•
1 like•435 views
Slides from my talk at QCon London on March 3rd 2020. Abstract: Integrating microservices or other components is hard, as it involves taming distributed systems. New API technologies are great, but can't magically solve all underlying challenges. This talk distills real-life experiences around typical architecture patterns. You will understand why you have to carefully think about boundaries and responsibilities of all your components. Further you will see why balancing orchestration and choreography is essential to avoid chaos. We also need to talk about idempotency, long-running and event-driven services. Don’t worry if you are new here, I will use easy to understand examples. In the end you will have gained a better feeling how to make your API smarter.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Moving beyond request reply - designing smarter APIs
Similar to Moving beyond request reply - designing smarter APIs (20)
More from Bernd Ruecker
More from Bernd Ruecker (14)
Recently uploaded
Recently uploaded (20)
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/ mail@berndruecker.io @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!