Pick strong consistency whenever possible
I used to agree until I was forced to use an eventually consistent system.<p>Both have their place, but I think you get better architected, more reliable software with an eventually consistent system.<p>In and eventually consistent system, the programmer must consider what to do in the case of data failure.  I think this is a good thing.  When building a user authentication system, who better to decide what to do when you can&#x27;t access the user database than the person writing the user auth system?  Should it fail open or closed?  Well if you&#x27;re a bank, you should probably fail closed.  If you&#x27;re Netflix?  Fail open.  The programmer should know the business case better than the database, which will alway fail closed.<p>Sure, in a consistent system the programmer <i>could</i> think about that, but they aren&#x27;t forced to, which I think is good.<p>Also, it means that joins must be done in your application.  Sometimes its good to have the programmer deal with that too, because it means they will have to really consider what data they need and be much more familiar with how much data is needed to create the join.  If you&#x27;re just relying on the database to do the joins, it might be hiding a lot of load from you, especially if you inadvertently create multiple table scans.  In an eventually consistent system, you <i>know</i> if you created a table scan, because you have to pull back a full table&#x27;s worth of data (or not, because you saw that issue and fixed it).<p>I just feels like the programmer gets better insight into what is happening to the data and can make better decisions on what to do when they are closer to the business cases the software is being built for.