Idempotency of commands in distributed systems
0 likes99 views
This document summarizes a presentation about idempotency in distributed systems. The presentation covered Command Query Responsibility Segregation (CQRS) and how to implement idempotent commands using CQRS and REST. It also discussed using a message bus instead of a command bus to allow workloads to be delegated to microservices. Finally, it introduced the concept of event-driven architecture and the idempotent consumer pattern to process messages and events only once.
Idempotency of commands in distributed systems
- 1. PHPers #10 Poznań Idempotency of commands in distributed systems Max Małecki 22.02.2023
- 3. I’m Max As the Last PHPdeveloper
- 5. Who is running microservices in production?
- 7. So again. Who is running microservices in production?
- 8. You got in the project: ● Purgers? ● DataFixers? ● DataCleaners?
- 9. Did your project: ● Spams sentry with UniqueConstraintViolations without any reason? ● Does your endpoints often return 500 status on retry?
- 10. PHPers #10 Poznań Idempotency of commands in distributed systems Max Małecki 22.02.2023
- 11. Let’s start from the very beginning
- 12. CQRS Command Query Responsibility Segregation 00
- 14. Command It’s a class that represents a change to be made in the system. 00
- 15. Query It’s a class that is responsible for data retrival. 00
- 16. Command Bus This is a class that contains all the information about commands and handler assigned to them. 00
- 17. Command Handler This is a class responsible for handling the command. 00
- 18. Now you can CQRS
- 19. Idempotence It’s a characteristic of a single argument function that the equation below is true. 01 f (f (x))=f (x)
- 21. Idempotence Command called that can be called multiple times and another calls doesn’t change the result of the first execution. 02
- 22. Life example
- 23. Black Friday
- 24. send Request POST /order TIMEOUT php-fpm don’t respond to ngnix Retry Request POST /order What a bargin! We just bought same thing twice! And we need to pay for the return delivery. TIMEOUT PDO responded with timeout of transaction. Idempotentność w Black Friday
- 26. Idempotence? 404 – Not fo
- 28. Producer Broker X 2. Append X 1. Send(X)
- 29. X Producer Broker X Y 4. Send(Y) 6 . A c k ( Y ) X Y Y 2. Append (Y) 1. Send(Y)
- 31. Yes. This producer isn’t idempotent
- 32. We reach the new frontier. frontier of youtube tutorials . Warning!
- 34. CQRS i REST 04 Commands instead of verbs!
- 36. Idempotentność Command Bus 1) Calls the handler Handler 1) Execute the business logic for given command. 2) In case of failure it throws Exceptions 3) It triggers events Controller 1) Validates the input 2) Builds a command 3) Dispatches command to Command Bus 4) Catches exceptions 5) Returns an response CQRS & REST
- 39. Idempotence REST CRUD HTTP Path Action Command GET /product/{id} /products ::show($id) ::index() POST /product ::new() CreateProductCommand($name, $desc, $price, $stock, $status) PUT /product/{id} ::edit($id) UpdateProductCommand($name, $desc, $price, $stock, $status) PATCH /product/{id} ::edit($id) EnableProductCommand($id) DisableProductCommand($id) UpdateProductPriceCommand($id, $price) DELETE /product/{id} delete($id) RemoveProductCommand($id)
- 40. Let’s do this with Commands. Shall we?
- 41. Idempotence CQRS & REST HTTP Path Command POST /createProduct CreateProductCommand($name, $desc, $price, $stock, $status) POST /product/{id} UpdateProductCommand($name, $desc, $price, $stock, $status) POST /product/{id}/enable EnableProductCommand($id) POST /product/{id}/disable DisableProductCommand($id) POST /product/{id}/remove RemoveProductCommand($id)
- 42. Now we gonna take care of Idempotence
- 43. Idempotence CQRS & REST HTTP Path Command POST /product/create_or_update CreateOrUpdateProductCommand($name, $desc, $price, $stock, $status) POST /product/{id} UpdateProductCommand($name, $desc, $price, $stock, $status) POST /product/{id}/update_price UpdateProductPriceCommand($id, $price) POST /product/{id}/enable EnableProductCommand($id) POST /product/{id}/disable DisableProductCommand($id) POST /product/{id}/remove RemoveProductCommand($id)
- 45. Pros: ● While building the REST we create commands. So our commands are transport agnostic. CLI / Messages / API ● Getting rid of big fat controllers ● Controller is only for validation and response ● We can trigger REST purists
- 47. Cool. But where are microservices?
- 48. Message Bus / Broker 05 from Command Bus to Message Bus
- 49. What a name. But we are changing only the transport.
- 51. Okay. Not only But thanks to that we can delegate workloads to other microservices
- 52. Communication between microservices Message Bus 1) We’re adding another interface in app besides CLI i HTTP 2) Thanks to that our command are not limited by HTTP that adds 1 second for TCP frame 3) We can copy-paste message contract from our api documentation 4) Our commands start to be asynchronous
- 54. Event Driven Architecture 06 In the way to event bus
- 55. Event Driven Architecture ● In our context: – Every Command Handler emits an Events. – Events can be local – and go to the event store – Events can be global – and they go to the EventBus – Global Event should have contract – Global Event can be listened by Event Subscribers from many different micro-services in our system.
- 56. Event Bus Event Bus microservice #1 microservice #2 microservice #3 EventPublisher EventSubscriber EventSubscriber
- 57. ● Can listen to multiple events ● Can dispatch a command on command bus ● Can’t emit another event. Event Handler
- 58. Indepotent Consumer Pattern 07 Yes it exists
- 59. ● Why is it special: – It works like every consumer. – It deduplicates Messages and Events. ● What it needs? – Unique id for each processed message – Repository of a message ids that been already processed (table in db, index in redis/memchache), to keep the idempotency betw Idempotent Consumer
- 60. Idempotent Consumer Start Check UniqueID Stop Duplicate Execute Commit Done? Rollback False True
- 61. Indepotent Consumer ● Distributed system are using message brookers, who try to deliver message at least once. ● Consumer can recognize duplicates and process a message just once skipping detected duplicates. ● When you scale your consumers, you must remember that duplicate storage must be shared.
- 62. Summary 08
- 63. Idempontency Pros ● We’re increasing system resilience – Just sopped spamming errors in the logs – In case of fire we allow ourselves to retry request/command ● Parallel processing is possible now! – We can accept same event/message from multiple instances – But remember it isn’t a cure for every consumer race condition. ● Finally we take care of data consistency – Each request (no matter it’s quantity) only represent single entity/resource in the system
- 64. What Next? 09
- 65. What next? ● You may check how Apache Kafka is dealing with idempotency in consumers and producers ● Check in your projects how many times you implement idempotent commands without realizing they are idempotent
- 66. Questions? 10
- 67. Yes this presentation will be available online.
- 68. Yes the code example is on mine github. https://github.com/emgiezet/phpers10
- 69. THANK YOU maxmalecki.com twitter: @mgz github: @emgiezet