Software Architecture

When we design a building, we usually design it base on plane walls and right angles. Why is that? Sometimes we design a round form, however that becomes way more complex to build. Still, we try to stick with simple forms like circle arcs. The Sydney Opera House was architected with unusual round forms at the roof. That project "was completed ten years late and 1,357% over budget " ( source ). The project really gained speed when they reduced the complexity of sail-like round forms to reusable (smaller) building blocks. In software you have the same problem. If you don't find reusable building blocks - as reusable code or reusable patterns - the complexity of the project grows exponentially, and you find yourself over budget (time and cost).  In software, you rarely need something as sophisticated as Sydney Opera House. Therefore, try to reduce complexity as much as possible if you want to finish your project in realistic time. Simplicity is the ultimate sophistication ...

  Problem to solve: We create a core software entity, for example a  Product  - this will become  root  or  parent  entity Then we create multiple "child" entities that depend on  Product . For example  Order  and  Warranty . We have business rules for the "parent" entity that depend on "child" entities. For example you cannot remove a  Product  if there are in-flight  Orders;  or if the  Warranty  period is not over for all the instances of that  Product We want to avoid putting all those business rules in  Product , because such "tight coupling" would make the software harder to maintain as the system grows. Solution: TLDR: It helps to imagine the entities  Product ,  Order  and  Warranty  as defined in separate software modules, either in a modular monolith or in a microservice architecture. This will highlight the loose coupling we want to achieve. Howeve...

You can actually prove that most software systems would work faster in a monolith than in a microservice architecture. Just put back together all the microservices in a monolith, mentally. Replace all the REST calls with direct Java calls, this should eliminate a lot of extra work to serialize/deserialize.  The resulting system will consume less resources overall just by less serialization. The latency should be smaller without the network calls. If you eliminate all the workarounds added just to make the distributed transactions to work, the performance should be significantly higher - with a proper load balancing of course. There are some edge cases, like if your resulting application does not fit into DRAM, however this is rarely the case. The horizontal scalability should still work is you deploy enough of those monoliths and correctly balance the work among them. Of course, the starting time might be higher with the monolith. The risk for Out Of Memory from one module to the o...