Moving beyond request-reply: How smart APIs are different. @berndruecker
Some Service Some Some Service Service Some Service But keep it local! Some Service Failure will happen. Be resilient. Accept it! Some Some Service Service
Photo by Tookapic, available under Creative Commons CC0 1.0 license.
„ There was an error while sending your boarding pass“
Current situation Web-UI Me Check-in
Current situation Web-UI Me Check-in Barcode Output Generator Mgmt
Current situation Web-UI Me Check-in Barcode Output Generator Mgmt
Current situation – the good part Circuit breaker Web-UI Me Check-in Barcode Output Generator Mgmt
Current situation – the bad part Web-UI Me Check-in Barcode Output Generator Mgmt
Current situation – the bad part Web-UI Me Check-in Barcode Output Generator Mgmt
Current situation – the bad part Web-UI Me Check-in Barcode Output Generator Stateful Mgmt Retry
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.
Possible situation – much better! Web-UI Me Check-in Barcode Output Generator Mgmt
Possible situation – much better! Web-UI Stateful Retry Me Check-in Barcode Output Generator Mgmt
Warning: Contains Opinion
Bernd Ruecker Co-founder and Chief T echnologist of Camunda Berlin, Germany http://berndruecker.io/ mail@berndruecker.io @berndruecker
You can use a workflow engine (=durable state machine)! Check-In Barcode REST Stateful retry
Want to see code? https://github.com/berndruecker/flowing-retail
Client Service Provider has to implement has to implement Retry Idempotency
Don‘t worry, it will happen safely – even if you loose connection. Feel free to reload this page any time!
Photo by pixabay, available under Creative Commons CC0 1.0 license.
Requirement: Idempotency of services! Photo by pixabay, available under Creative Commons CC0 1.0 license.
Requirement: Idempotency of services! Photo by Chr.Späth , available under Public Domain.
Make every service idempotent! Credit Payment Card charge Charge Credit Card Not Not idempotent cardNumber amount Generally: create Ids as soon as possible Charge Credit Card cardNumber Idempotent amount transactionId
Distributed systems introduce complexity you have to tackle! Credit Payment Card REST
Distributed systems
It is impossible to Client Service differentiate certain Provider failure scenarios. Independant of communication style!
Distributed systems introduce complexity you have to tackle! Credit Payment Card REST
Distributed systems introduce complexity you have to tackle! Credit Payment Card REST Cancel charge
@berndruecker Being able to implement long running services is essential for smart APIs (on a technical level)
@berndruecker Example Retrieve Payment Booking Payment
@berndruecker Example Retrieve Payment Credit Booking Payment Card
@berndruecker Example Retrieve Payment Credit Booking Payment Card Rejected
@berndruecker Example Retrieve Payment Credit Booking Payment Card Rejected If the credit Rejected card was rejected, the customer can provide new details
@berndruecker Example Retrieve Payment Credit Booking Payment Card Rejected If the credit Rejected card was rejected, the customer can provide new details A few smart god services tell anemic CRUD services what to do Sam Newmann
@berndruecker Who is responsible to deal with problems? Retrieve Payment Credit Booking Payment Card Payment If the credit Rejected card was received Payment rejected, the failed customer can provide new details
@berndruecker Long running services Retrieve Payment Credit Booking Payment Card Payment Rejected received Payment failed Smart endpoints are potentially long-running
@berndruecker Being able to implement long running services is essential for smart APIs (on a business level)
Long running services require async communication
Synchronous communication
Synchronous communication is the crystal meth of distributed programming T odd Montgomery and Martin Thompson in “How did we end up here” at GOT O Chicago 2015
Asynchronous communication Web-UI You need to monitor timeouts Me Check-in Barcode Output Generator Mgmt
Workflow…
Workflow…
@berndruecker Being able to implement long running services makes it easy to get async
Can your company leverage your hipster architecture? You need to change busi sines ess pr processes es and customer er Shutterstock expe perience ience!
@berndruecker Example
Example Seat Booking Reservation Payment Ticket Generation
@berndruecker Example sync
@berndruecker Example
Weaknesses Seat Booking Reservation REST Payment Ticket Generation
Weaknesses: Latency creep 300 ms 1150 + x ms Seat Booking Reservation REST 600 ms Payment 250 ms Ticket Generation
Weaknesses: Availabiliy erosion Seat 99 % uptime Booking Reservation REST 96 % uptime Payment 99 % uptime Ticket Generation 99 % uptime
And it is even hard to implement Seat Booking Reservation REST Payment Ticket Generation
And it is even hard to implement Seat Booking Reservation REST Payment Ticket Generation
T ypical pattern Simulate synchronicty by waiting (callback or polling) Seat Booking Reservation REST Payment Ticket Generation
@berndruecker Redesign your business process accordingly! Sync in happy case happy case Or some interface to poll for status failure case Async response
@berndruecker Redesign your business process accordingly!
@berndruecker Your business processes need to be more reactive! https://www.reactivemanifesto.org/
Yeah! Let‘s go reactive.
Phil Calcado at QCon NYC 2019
„ What the hell just happened ?“ API API API API Microservices API Standard Software API API External Services @berndruecker
@berndruecker 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 Three steps …
@berndruecker (Micro-)services Checkout Shipment Payment Inventory
@berndruecker Event-driven architecture Order Checkout Placed Payment Notification Received Goods Fetched Shipment Payment Inventory
@berndruecker Peer-to-peer event chains Order placed Checkout Shipment Payment Inventory Goods shipped Payment Goods received fetched
@berndruecker Peer-to-peer event chains Order placed Checkout Shipment Payment Inventory Goods shipped Payment Goods received fetched
@berndruecker 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 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 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 Peer-to-peer event chains Fetch the goods before the Order payment placed Checkout Shipment Payment Inventory Goods shipped Payment Goods received fetched
@berndruecker Peer-to-peer event chains Fetch the goods before the Order payment placed Checkout Shipment Payment Inventory Goods shipped Payment Goods received fetched
@berndruecker What we wanted Photo by Lijian Zhang, available under Creative Commons SA 2.0 License and P..19 / CC BY-SA 4.0
@berndruecker Extract the end-to-end responsibility Order placed Checkout Order Retrieve payment Payment Shipment Payment received Inventory
@berndruecker Events & Commands Order Fact, placed Event Checkout happened in the past, Order immutable Retrieve payment Intend, Command Payment Want s.th. to happen Shipment Payment received Inventory
@berndruecker It is not about the protocol! It can still be messaging! Order placed Checkout Order Retrieve payment Shipment Payment Inventory
Recommend
More recommend
