Modules vs Microservices
I don&#x27;t have much ideology behind going with microservices vs. monolith, but what we&#x27;ve done on some recent projects is organize our code into modules that only communicate with each other through a narrow and well defined boundary layer.  If we need to split a module out into a separate service, then it isn&#x27;t nearly as much work to split it out later.<p>One of the practical issues we&#x27;ve had with microservices that need to interact with each other in real time is ensuring a consistent state across systems.  For example, let&#x27;s say I need to change the status of an object and afterwards, call a separate service to change state there as well.  What happens if the call fails in some way?  You can&#x27;t just run all of this inside a single database transaction anymore.  Now you have to design your code to deal with several potential failure points and edge cases, which adds complexity.  The other consideration is all calls to a service should be idempotent if possible.  It makes coding from the client side a lot easier if you can just fire off a call multiple times (in case of local or remote failure) and not have to worry about state.<p>Just some of my thoughts, since this stuff has been on my plate recently.