How to have decoupled systems without setting your company on fire by Eduardo Bellani

Have you heard that having decoupled systems is paramount to dealing with complexity at the heart of software?

Have you also seen companies waste piles of cash and lots of developer time trying to build decoupled systems?

This article might be of your interest, since my goal is to teach you how to build decoupled systems cheaply and using technology that is battle tested and that will keep you in control. How? By

  1. See the problems of the current widespread solution to coupling: microservices;
  2. See how to implement decoupled systems using a SQL DBMS;
  3. Visit a bit of the underlying theory about coupling/modularity/views in light of what was presented.

A summary of the comparison: Microservices vs SQL DBMS

Microservices

  1. Poor performance with serialization and networking
  2. Correctness problems over versioning in a distributed system
  3. Hard to manage multiple binaries and e2e testing
  4. Dangerous to change APIs
  5. Slow development because of lack of atomicity of changes

(Ghemawat et al. 2023)

SQL DBMS

  1. Great performance with data colocation
  2. Correctness by default
  3. Single system, easy to test e2e
  4. Change is made safe by constraints
  5. ACID baby

The core point

this rule means: We have a module N which uses some module M, but only through its type (interface) A. M can be replaced by any other module with the same type, and N will continue to work. That’s modularity. (Koppel 2023)

Or, in non-alien language: It means that the relation between interfaces and implementations is many-to-many. That means that modularity is a logical property that can be implemented in many ways.

The canonical way of doing it in the relational model is through views.

So what about views?

You can have many views (interfaces) over the same base tables (implementations). (many to one)

The same view can have multiple ways of being deduced from the base tables. (one to many)

This implements modularity, as defined in the previous section

The original view (pun intended) about views

In contrast, the problems treated here are those of data independence-the independence of application programs and terminal activities from growth in data types and changes in data representation

…

Activities of users at terminals and … application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.

(Codd 1970)

It used to be called logical data independence. It can also be called de-coupling.

Figure 1: The Church of Ulrich, over 1000 years old, was bombed in 1945 by the americans, but survived. In 1956, it was destroyed by the communists to create the new city center based on communist architecture.

Figure 1: The Church of Ulrich, over 1000 years old, was bombed in 1945 by the americans, but survived. In 1956, it was destroyed by the communists to create the new city center based on communist architecture.

References

Codd, E. F. 1970. “A Relational Model of Data for Large Shared Data Banks.” Commun. Acm 13 (6): 377–87. https://doi.org/10.1145/362384.362685.
Ghemawat, Sanjay, Robert Grandl, Srdjan Petrovic, Michael Whittaker, Parveen Patel, Ivan Posva, and Amin Vahdat. 2023. “Towards Modern Development of Cloud Applications.” In Proceedings of the 19th Workshop on Hot Topics in Operating Systems, 110–17. Hotos ’23. Providence, RI, USA: Association for Computing Machinery. https://doi.org/10.1145/3593856.3595909.
Koppel, Jimmy. 2023. “’modules Matter Most’ for the Masses (Accessed on 2024-10-10).” pathsensitive blog. https://www.pathsensitive.com/2023/03/modules-matter-most-for-masses.html.