Monoliths Are the Future
I couldn&#x27;t agree more with an article.<p>Most people think a micro-service architecture is a panacea because &quot;look at how simple X is,&quot; but it&#x27;s not that simple. It&#x27;s now a distributed system, and very likely, it&#x27;s a the worst-of-the-worst a distributed monolith. Distributed system are hard, I know, I do it.<p>Three signs you have a distributed monolith:<p>1. You&#x27;re duplicating the tables (information), without transforming the data into something new (adding information), in another database (e.g. worst cache ever, enjoy the split-brain). [1]<p>2. Service X does not work without Y or Z, and&#x2F;or you have no strategy for how to deal with one of them going down.<p>2.5 Bonus, there is likely no way to meaningfully decouple the services. Service X can be &quot;tolerant&quot; of service Y&#x27;s failure, but it cannot ever function without service Y.<p>3. You push all your data over an event-bus to keep your services &quot;in-sync&quot; with each-other taking a hot shit on the idea of a &quot;transaction.&quot; The event-bus over time pushes your data further out of sync, making you think you need an even better event bus... You need transactions and (clicks over to the Jepsen series and laughs) good luck rolling that on your own...<p>I&#x27;m not saying service oriented architectures are bad, I&#x27;m not saying services are bad, they&#x27;re absolutely not. They&#x27;re a tool for a job, and one that comes with a lot of foot guns and pitfalls. Many of which people are not prepared for when they ship that first micro service.<p>I didn&#x27;t even touch on the additional infrastructure and testing burden that a fleet of micro-services bring about.<p>[1] Simple tip: Don&#x27;t duplicate data without adding value to it. Just don&#x27;t.