1. 13
  1. 2

    This is clever and it sounds like it probably works well, but it feels like they’re solving it at the wrong layer? Surely it’d be cleaner and less hacky to just have the Rails frontend in Sydney issue writes to the Postgres server in Paris, instead of starting the request over with a frontend in Paris. I can’t imagine that’s much harder to implement, either.

    I guess there’s a performance penalty here if the frontend ends up issuing many writes, but I imagine that’s a fairly rare case, and we’re already in the rare case of a write happening at all—I can’t imagine performance matters much here?

    1. 2

      Definitely depends upon how chatty the application is with the database.

      I worked on a project which did something similar to this article because we saw the latency in a non-primary datacenter when having a direct to the primary database was too close to our SLA.

      This traffic pattern came from a global customer which had their users become very active in their local timezones, so simply moving the data wasn’t acceptable. It ended up being drastically cheaper to “forward” the incoming request to the primary datacenter when a write was detected.

    2. 2

      The article kinda gets stuff wrong, PUT, PATCH, and DELETE, are all supposed to be idempotent (this is what distinguishes PUT from POST).