1. 2

  2. 3

    I don’t agree with the author, but I think it’s a good excuse to discuss why it’s wrong and segue into correct scalability choices.

    The biggest problem is the character the author describes makes a serious of non-scalable decisions but calls it scalable, and the author seems incapable of differentiating between valid scalability decisions and just making bad choices.

    But his sentiment is something I see often: don’t worry about scalability, it will be good when we have that problem anyways because it means we have succeeded. I think this idea is wrong.

    Scalability can be broken up into two decisions: infrastructure and API.

    Building scalable infrastructure is expensive and time consuming. By this I mean everything from networking to the actual application code being performant and scaled out.

    However, building scalable APIs is upfront work that needs to happen, otherwise you are severely restricted in your ability to scale if you need to. That means your API should not promise anything you cannot guarantee what you do scale. That roughly comes down to strongly consistent guarantees and exactly-once semantics.

    Many people will claim that a scalable API is too complicated a thing to do to start out. But it comes down to one rule: when in doubt, use a 2 phase commit in the API. This means sending some data and getting an opaque token back, then acking that token with another call. This is almost always a scalable solution (I say almost because I don’t know every problem). Default to that and your API will probably be scalable.

    1. 5

      Waiting until you have performance problems does mean you at least know what the problems are.

      1. 1

        I’m not sure I understand the context of your response. I am saying holding off actually building things at scale, but rather just make sure your API can eventually be scaled up. That is, provide scalable semantics even if your actual components are not scalable so that you can scale it later.

        Are you agreeing or disagreeing? Or did I not make my point clearly enough?

        1. 1

          Ah, so in this case, it looks like they roughly took your advice. Running queries directly against the database is not a scalable API, so they built a scalable midlayer API.

          1. 2

            Does it?

            I interprete “provide scalable semantics” in - for example - the case of database calls like: make sure the actual database call gets performed from some seperate container (e.g. a “service class”) so you can swap out actual database interaction to a “rpc” later on.

            Or do I interpret stuff like a madman now?

            1. 1

              Yes, IMO the problem the ‘hero’ in the post hit was that they just made poor technology decisions that.