{"id":303430,"date":"2020-03-19T07:48:36","date_gmt":"2020-03-19T14:48:36","guid":{"rendered":"https:\/\/css-tricks.com\/?p=303430"},"modified":"2020-03-26T14:31:20","modified_gmt":"2020-03-26T21:31:20","slug":"consistent-backends-and-ux-what-are-the-barriers-to-adoption","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/consistent-backends-and-ux-what-are-the-barriers-to-adoption\/","title":{"rendered":"Consistent Backends and UX: What are the Barriers to Adoption?"},"content":{"rendered":"\n

Article Series<\/h4>\n\n\n
  1. Why should you care?<\/a><\/li>
  2. What can go wrong?<\/a><\/li>
  3. What are the barriers to adoption?<\/a><\/li>
  4. How do new algorithms help?<\/a><\/li><\/ol>\n<\/div><\/div>\n\n\n\n

    There are very few scenarios in which an eventually consistent database is preferable over a strongly consistent database. Further, in a multi-region application scenario where scaling is necessary, choosing either an undistributed database or an eventually consistent database is even more questionable. So what motivates engineers to ignore strongly consistent distributed databases? We have seen many reasons, but wrong assumptions drive most of them.<\/p>\n\n\n\n\n\n\n

    \u201cThe CAP theorem says it\u2019s impossible\u201d<\/h3>\n\n\n

    As we explained in Part 1 of this series<\/a>, the CAP theorem is widely accepted yet often misinterpreted. When many people misinterpret a well-known theorem, it leaves a mark. In this case, many engineers still believe that eventual consistency is a necessary evil.<\/p>\n\n\n

    \u201cBuilding a strongly consistent distributed database is too hard\/impossible\u201d<\/h3>\n\n\n

    It is slowly sinking in that consistency should not be sacrificed, yet many databases still put consistency second. Why is that? Some popular databases offer options that deliver higher consistency, but only at the cost of potentially very high latencies. Their sales messaging might even claim  that delivering consistency at low latencies in a multi-region distributed database is incredibly hard or even impossible, and the developer audience has salient memories of experiencing very poor latencies in databases that were not built for consistency. Combined, they jointly fortify the misconception that strong consistency in a distributed database with relatively low latencies is impossible.<\/p>\n\n\n

    \u201cPremature optimization is the root of all evil\u201d<\/h3>\n\n\n

    Many engineers build according to the \u201cPremature optimization is the root of all evil\u201d<\/a> (Donald Knuth) principle, but that statement is only meant to apply to small inefficiencies<\/a>. Building your startup on a strongly consistent distributed scalable database might seem like a premature optimization, because initially, your application doesn’t require scale and might not require distribution. However, we are not talking about small inefficiencies here. The requirement to scale or distribute might arise overnight when your application becomes popular. At that point, your users have a terrible experience, and you are looking at a substantial challenge to change your infrastructure and code. 
    <\/p>\n\n\n

    \u201cIt\u2019s hard to program against a distributed database\u201d<\/h3>\n\n\n

    This used to have some truth to it since distributed databases were new, and many came with severe limitations. They did not allow joins, only allowed key-value storage, or required you to query your data according to predefined sharding keys, which you couldn’t change any more. Today, we have distributed databases that have flexible models and provide the flexibility you are used to with traditional databases. This point is very related to the previous point, which ignores that nowadays, starting to programming against a strongly consistent distributed database is just as easy and probably easier in the long run compared to a traditional database. If it’s just as easy, then why not optimize from the start?<\/p>\n\n\n

    Working with an eventually consistent database is like…<\/h3>\n\n\n

    Distributed databases are often created by people who have experienced problems with eventual consistency. For example, FaunaDB<\/a> was built by former Twitter engineers after having experienced how difficult it is to build a scalable system on top of the eventually consistent databases that were popular around that time, such as Cassandra. These problems typically manifest when a new company starts to scale, hence many younger engineers have never experienced them first hand.<\/p>\n\n\n\n

    Sometimes painful things can teach us lessons that we didn\u2019t think we needed to know.<\/p>\u2014 Amy Poehler<\/cite><\/blockquote>\n\n\n\n

    Discussing the dangers of eventual consistency typically leads to the “it works for me\u201d argument from engineers who simply haven\u2019t experienced any issues yet. Since that often takes months (or years, if you are lucky), let’s look at an analogy.<\/p>\n\n\n

    \u2026riding a bike with loose wheels. <\/h4>\n\n\n

    A while ago, my best friend was about to miss an appointment, so I lent him my bike. I was happy that I helped out, he was happy, and everything went well. That happiness quickly turned into pain when he tried to jump the bike onto a side-walk. You see… I had tinkered with the bike earlier that day and had forgotten to tighten the front wheel. He came back with a huge purple bruise.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    The bike example is very similar to working with a database that is not strongly consistent. Everything will go well until you try to lift the bike\u2019s wheel (or in other words, until your company lifts off and starts scaling up).<\/p>\n\n\n\n

    At the moment your application needs to scale up, you typically do so by replicating services. Once the database becomes the bottleneck, you replicate your traditional database or move to a distributed database. Sadly, at that point, features in your application might break when you start replicating your database. Until now, you hadn’t noticed these problems since the database ran on a single node. At that point, two things might happen: <\/p>\n\n\n\n