1. 10
    3factor app devops programming web 3factor.app
  1.  

  2. 5

    Factor #1 is a specific technology that the authors just so happen to sell…

    1. 3

      It has one mention to the product they sell, in the form of a link on the “Read More”. GraphQL doesn’t require their product.

    2. 4

      “State”

      1. 3

        To support this architecture pattern, your State store should have the following properties:

        • Consistent. Since you’re using it to dedupe and correctly order messages from your event queue.
        • Available. Since in this architecture pattern all requests hit the State store at least twice, and possibly N times due to fanout on your event queue, it’s critical that this single point of failure be highly available.
        • Partition-tolerant. Since you’re operating in a distributed environment, your serverless functions must be able to tolerate network partitions from the State store and still ensure application consistency without impacting availability.

        We call these “CAP databases” (for Consistent, Available, and Partition-tolerant databases), and it’s best-practice for your State store to support all three of these properties.

        :P

        1. 1

          Also are they implicitly assuming, specifically with some of the phrasing around the third factor, that the CALM theorem always holds? Seems like their out of order requirements are a little limiting.

        2. 2

          Most of the services I’ve seen at work lean pretty heavily on the second and third factors, and in my experience, they’ve been pretty nice to work with. I can’t vouch for GraphQL, though.

          1. 1

            This can be applied to narrow range of apps. White 12factor to wast.