.NET Day 19 - Knock. Knock. Who's there? A message from the future by Daniel Marbach

Traditionally we look at time-based business rules like invoice reminders or making a customer preferred as batch jobs. We've always done it that way so why bother changing it? Simply put: the more customers and orders that are added to this system, the longer it will take the batch job to run. Your company's success can be your batch job's undoing. With messaging at hand we can start predicting the future by sending a message to our future selves.
In this talk, I show you how to leverage durable timeouts with messaging and the saga pattern to become the TimeLord in your business domains. You can finally get rid of your batch jobs. To satisfy the Doc Brown in all of us we'll dive into mad scientist implementations of durable timeouts in RabbitMQ and AmazonSQS. Knock. Knock. When's there?

Transcript

1. Knock. Knock. Who’s there? A message from the futur
2. Business logic tends to be complicated
3. Inconsistencie s Hiding
4. Multi user collaboratio n
5. Multi user collaboratio n
6. Back Front ASP.NET CORE Frontend Backend Storage HTTP Orders Read / Write Database
9. And then the customer walks into your office
11. Concurrency and latency in collaborative domains can lead to incorrect application of business rules even in safe architectures
12. Batch Jobs Batch Jobs
13. Back Front ASP.NET CORE Frontend Backend Storage HTTP Orders Read / Write Database Batch
17. Batch Jobs increase the window of consistency problems Batch Jobs for time based business rules are the worst enemy for growth
18. Rethink time
19. 1 week Sum(o => o.Total) t
20. += o.Total -= o.Total 1 week += o.Total -= o.Total 1 week += o.Total -= o.Total 1 week WeekTotal WeekTotal t
21. += o.Total -= o.Total 1 week += o.Total -= o.Total 1 week += o.Total -= o.Total 1 week WeekTotal WeekTotal t
22. Program time
23. Back Front ASP.NET CORE Frontend Backend Storage HTTP Orders Read / Write Database Schedul er
29. Durable scheduling introduces reliability on the server side
30. Resilient HTTP introduces some reliability but doesn’t survive restarts
31. Client side retries help to resolve transient failures but increase the latency
32. Orders might be lost when clients give up on retries
33. Fire & forge Orders are ideal to from the frontend perspe
34. Sagas
35. Sagas
36. Back Front Frontend Backend Storage SQL Database Queue RabbitMQ DiscountPol icy ProcessOrd er
42. docs.particular.net/transports/sqs/delayed-delivery
43. N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.N.destination docs.particular.net/transports/rabbitmq/delayed- delivery
44. Messaging introduces reliability
45. Retries resolve consistency issues automatically
46. Sagas on top of a robust middleware allow to focus on the business logic and stay reactive
47. For ultra high contention domains different approaches might be necessary
48. Ask the collaborative domain question first
49. Business consistency rarely ever needs to be addressed with technical solutions
50. Favor simplicity over complex design wherever you can
51. Thanks
52. go.particular.net/dnd19-parsec
53. go.particular.net/dnd19-
54. github.com/danielmarbach/KnockKnock Slides, Links…
55. Q & A
56. Software Engineer Enthusiastic Software Engineer Microsoft MVP @danielmarbach particular.net/blog planetgeek.ch
57. Thanks