And you are here why?

Irreducible Complexity Swapping out your monolith for micro-services — or just using micro-services in the first place — is, in theory an obvious thing to do. After all, the larger your monolith (“one big thing”!) gets, the harder it is to for you to keep track of everything in it. The architecture eventually get to a place where you just can’t visualize it all in your head. Oh, loose-coupling helps, as does componentization, layered architectures, queues/service-buses, and whatnot, but, in the end, you’re limited by the irreducible complexity of the system. So, you do the obvious. You extend loose-coupling to the breaking point, by, literally, breaking apart the individual components into distinct micro-services. Now, each of these micro-services can be visualized in entirety by  its development team, and you can task somebody else with visualizing how all the individual components fit together. So simple, right? You’ve basically  decoupled  the individual compo...

Do you know what your component’s dependencies are? OK, fine,   you   know, but does everybody else on your team know? Great, they know too. Now for the really important part — does what   you   know match what   they know? You’d be surprised how often that   semantic mismatch happens. The folks working on   component XXX   need to temporarily persist stuff, and use the postgres infrastructure that the   component YYY   folks are so conveniently running in production. Which is awesome, right up to the point that the   component YYY   folks finish their migration to ElasticSearch, and deprecate postgres… The moral of the story — document (and share!) the design assumptions behind the architecture across all your teams. Whats more, on a fairly regular basis, reassess these assumptions, and see if anything needs to be added, updated, or removed!