Szymon Pobiega
Engineer particularly interested in software
Kraków, Poland
Szymon works an engineer at Particular Software, the makers of NServiceBus. His main areas of expertise are Domain-Driven Design and asynchronous messaging. He is especially interested in the intersection of these two topics -- in the patterns and tools for ensuring all messages are processed exactly once and in the correct order.
Szymon is a co-author of https://exactly-once.github.io/, a website dedicated to all things related to messaging.
In his free time Szymon plays with Lego, building models of real-life off-road vehicles.
Links
Area of Expertise
Topics
Messaging and consistency: past, present and future
Whether you favor good old microservices or the cutting-edge structured monolith, chances are pretty high that your system uses message queues. That means your business logic is triggered at least once per message, as messages are re-delivered until acknowledged. That forces us to consider problems like idempotency, deduplication, and transactionality. How can we deal with these challenges?
In this talk, we'll explore various options for dealing with message redelivery. We'll discuss what we don't need, zoom in on vendor-provided snake oil labeled "exactly-once" solutions, and also dive into the industry standard for consistent message procession: the Outbox pattern. By exploring multiple variants of the Outbox pattern and comparing their respective strengths and weaknesses, you'll walk away with a thorough understanding of the topic.
To conclude the talk, I'll dust off my glass sphere and share my thoughts on the future of consistent message processing.
HTTP APIs: do not charge my credit card twice
Initiated by Roy Fielding's dissertation, there has been miles of paper written on how to structure the HTTP payloads for machine-to-machine communication. Unfortunately not nearly as much attention has been dedicated transmission of the intent of these payloads.
The specification is clear about the meaning of the verbs e.g. that GET should not change state and PUT should be idempotent. But how exactly can one design a HTTP channel between two software components so that the intent of one is transmitted exactly-once to the other?
In this talk we are going to explore some well-known and not-so-well-known approaches to ensuring the action requested by means of a HTTP request is conducted exactly once.
Exactly-once: the holy grail of distributed systems
Imagine a world in which you could build a distributed system that guarantees that every individual user action travels throughout a multitude of services without ever being lost or duplicated. No lost orders. No duplicate entries that require reviews. No persistent exceptions due to data inconsistencies.
If you're imagining rainbows and unicorns right now, this session is for you!
Before going into specifics, we need to stop thinking about message delivery and focus on message processing instead. We'll explore an end-to-end approach to message processing, starting from the human-to-machine interaction in the front end of the system and traversing component-to-component message-based communication throughout the system.
As a cherry on top, I'll present you with a fully operable example showcasing cross-system, exactly-once, HTTP-based communication.
Ready to explore what's over the rainbow?
Consistency: more than just a database
The consistency guarantees of databases are very well documented. For starter, we have good old standard SQL isolation levels. Recently, with the advent of NoSQL databases, the consistency of data got even more attention. Unfortunately for many use cases this data-centric point of view is not sufficient as modern systems frequently use message-based asynchronous communication in which messages are durably stored and delivered multiple times, until acknowledged.
In this talk we are going to explore consistency violations that arise from anomalies in handling of asynchronous communication between two database-backed components. In the case study we are going to analyze the most common example of a user agent sending a HTTP request that results in a database update and a message being sent. That message is processed by a backend component that updates its database and sends another message.
Cloud DeveloperDays 2020 Sessionize Event
NDC London 2020 Sessionize Event
Szymon Pobiega
Engineer particularly interested in software
Kraków, Poland
Links
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top