Software Architecture

  "If a tree falls in a forest and no one is around to hear it, does it make a sound?" If a system has an inconsistency but no one  is able  to observe it, is it still an inconsistency? Introduction We need to scale data processing systems geographically  to achieve lower Latency and (at least partial) Availability in case of network Partitioning. But  CAP / PACELC  tells us that we cannot achieve strong Consistency in this case. When we increase the Consistency requirements, we have to accept lower Availability and higher Latency. What is the minimum consistency level that we need? If eventual consistency is enough for your system, things are pretty clear and relatively simple. Most probably you want to achieve Strong Eventual Consistency that is relatively cheap and provides nice guaranties. For this you will have to you something like  CRDT . Some theoretical results assure us that you cannot find something way cleverer than CRDT that achieves ...

"Embrace modularity but beware of granularity"  ( Mark Richards)   While using the Microservice architecture in software can buy you some agility if done right, I often see architectures where microservices bring extra complexity that actually increases the implementation time. The microservice architecture often brings incidental complexity, that is often caused by the uninspired choice of our microservice boundaries. Bounded context should guide the choice of microservice boundaries. However, I find bounded context to be a too ambiguous concept. Any unit of software can be seen as a bounded context, even a class. A Payment sounds like a bounded context. What about a CreditCard , can it have its own bounded context? We don't want to create a microservice for each class, for sure. Think about this when you think to create another microservice, are you going too close to the "microservice per class" anti-pattern? On the other end, most real life software syste...