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

.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?

E6cffbf3b7a5fbfee4707033ef1636f5?s=128

dotnetday

May 28, 2019
Tweet

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
  7. None
  8. None
  9. And then the customer walks into your office

  10. None
  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
  14. None
  15. None
  16. None
  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
  24. None
  25. None
  26. None
  27. None
  28. None
  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
  37. None
  38. None
  39. None
  40. None
  41. None
  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