1. 13
  1.  

  2. 1

    For those interested: I couldn’t find this talk on youtube but many similar talks are available by the same presenter if you search her name.

    1. 1

      This was pretty interesting. The key seems to be a central coordinator making idempotent, commutative, and subsequently-cancellable requests to distributed services.

      1. 2

        Wasn’t it? I like how both requests and cancellations are idempotent, but cancellations are not cancellable. It makes the whole system very monotonic, as in the 2-phase commit protocole they seem to draw inspiration from.

        1. 1

          Having given it some more thought, the commutative property of requests and compensating requests is both important and really tricky to get right. For example, from slides 54-59 of her presentation, these two sequences should result in the same outcomes:

          1. Book the Green Toyota for Mrs. Doe
          2. Cancel Mrs. Doe’s Green Toyota

          vs.

          1. Cancel Mrs. Doe’s Green Toyota
          2. Book the Green Toyota for Mrs. Doe

          But that second one is very non-intuitive, and forces the backing services to develop a more sophisticated resource model than just creating vs. deleting something from a datastore. Still, it suggests a lot of thorough and non-obvious tests to write.

          1. 2

            not sure it’s that much more complicated: any task could have a state which follows a simple state machine non-existent -> {ok | error | cancel} -> cancel. Then, a task could be initialized directly in the “cancel” state if the compensating request arrives first (meaning that the normal request will have no effect).

            1. 1

              Oh yeah, once you know that this is a requirement, it’s not hard. Knowing it’s needed and why is the sophistication!

            2. 1

              More sophisticated, sure, but I don’t think by very much. Just requires a “simplification” step before flushing the request queue into actual actions on the database