&gt; These systems seem (from my outside view) to have a tendency to become giant monoliths. So when developing you must fight against increasing monolithic complexity.<p>You aren&#x27;t wrong, that&#x27;s my experience as well. It&#x27;s just as annoying for programmers (or, at least, for me) as it is for users. The following question has popped out countless times in my head: “Why do I have to rely on an implicit convention that this application module never touches this database table?” There was never a good answer.<p>The only reason why I put up with such things is that I have no idea how to prevent more modular designs from turning into a data integrity nightmare. (I&#x27;ll freely admit my lack of education is to blame here.) For instance, let&#x27;s say we have three modules: inventory, sales and shipping. Furthermore, let&#x27;s assume each module is its own actor and uses its own backend database. We must implement the use case “enter a sale in the system”:<p>(0) The sales module queries the inventory module whether there is enough of a product in stock to satisfy a customer order. The expected sequence of actions is:<p>(1) The inventory module “locks” the requested quantity&#x2F;amount of the product [so that it can&#x27;t be used, say, for another sale], and gives the sales module a “token” that can be used to confirm or cancel the withdrawal.<p>(2) The sales module queries the shipping module if there are enough available trucks&#x2F;ships&#x2F;whatever to ship the product to the customer&#x27;s location by a given delivery date.<p>(3) The shipping module “locks” however many trucks&#x2F;ships&#x2F;whatever it deems necessary to ship the product, and gives the sales modules a “token” that can be used to confirm or cancel the shipping.<p>(4) The sales module queries the user for the customer&#x27;s credit card number and verification code, interfaces with the bank&#x27;s system, blablabla...<p>(5) The sales module confirms to the inventory and shipping modules [in this specific order] that the product will be withdrawn and shipped.<p>Now some exception handling:<p>(6) If step 3 fails, the sales module cancels the product withdrawal.<p>(7) If step 4 fails, the sales module cancels the product withdrawal and shipping.<p>(8) If any system [inventory, sales, shipping] goes down, neither the product nor the trucks&#x2F;ships&#x2F;whatever can be kept locked forever. So each lock must have a timeout, and, if it&#x27;s neither explicitly confirmed nor explicitly cancelled by the sales module, it will be implicitly cancelled by the inventory and&#x2F;or shipping module when the timeout elapses.<p>(9) It may happen [unlikely, but not impossible], that the inventory and shipping module&#x27;s clocks get unsynchronized in such a way that, when the product withdrawal has been been confirmed, the shipping lock has already elapsed. <i>Oh, the nightmare.</i><p>Implementing all of this <i>correctly</i> in all cases is actually tricky! And if anything is implemented <i>slightly</i> wrong, the whole system goes kaboom! With a monolithic database, there is no need to “lock” any resources, nor issue “confirmation tokens” - just use the DBMS&#x27;s built-in transaction system!