Luego de investigar con especialistas en esta materia, programadores de varias ramas y maestros dimos con la respuesta al dilema y la compartimos en este post.
Solución:
No es probable que se beneficie de una arquitectura de microservicios si todos los servicios comparten las mismas tablas de base de datos. Esto se debe a que está acoplando estrechamente los servicios de manera efectiva. Si una tabla de base de datos cambia, todos los servicios tendrán que cambiar.
Debe comprender que la razón principal de una arquitectura de microservicios es reducir las dependencias entre los equipos de desarrollo y permitirles avanzar de forma independiente con lanzamientos rápidos.
Aquí hay una cita de Werner Vogels, el CTO de Amazon (Amazon fue pionera en gran parte de la arquitectura de estilo de microservicios):
Para nosotros la orientación al servicio significa encapsular los datos con la lógica de negocios que opera sobre los datos, con el único acceso a través de una interfaz de servicio publicada. No se permite el acceso directo a la base de datos desde fuera del servicio y no se comparten datos entre los servicios.
Para más información lea esto y esto.
Una actualización en 2021:
Algunos comentaristas señalaron que compartir una base de datos física puede estar bien, por ejemplo, usando tablas o esquemas separados para diferentes servicios en la misma base de datos. Por supuesto, esto es posible y sigue siendo una separación útil de preocupaciones para el desarrollo del servicio. Es una decisión arquitectónica (y también organizativa) si desea que los equipos de servicio sean responsables de toda la pila de servicios y la implementación, incluida la infraestructura, o si desea separar eso en un equipo de infraestructura o devops. Cada enfoque puede tener sus pros y sus contras según las circunstancias de su organización, la escala, los requisitos, etc.
Otro aspecto es que las tecnologías de base de datos escalables más nuevas se están volviendo más populares. Por lo general, abstraen el almacenamiento y la computación para una escalabilidad independiente y se usan como un servicio (por ejemplo, Snowflake, Teradata, BigQuery, etc.). Permiten crecer a tamaños muy grandes con millones de tablas y petabytes de contenido usando un solo clúster. Con ellos, el objetivo sería que los equipos de implementación de microservicios no se preocupen por los detalles de la ejecución de una infraestructura de base de datos, sino que simplemente usen el extremo del clúster de base de datos como una dependencia del servicio. Y sería normal que muchos servicios dependieran de ese mismo clúster de base de datos. Sin embargo, aún querrá prestar atención a la separación del almacenamiento, por ejemplo, tablas lógicas separadas, colecciones o lo que sea que tenga sentido en la tecnología de base de datos específica.
En general, un microservicio debe ser responsable de sus propios datos. Ese es un escenario mundial perfecto.
En la práctica, algunos de los servicios pueden estar muy relacionados entre sí. Por ejemplo, los servicios CustomerShippingDetails y CustomerShoppingCheckout pueden acceder a los mismos datos: la dirección del cliente. Entonces, ¿cómo resolvería un problema de proporcionar la dirección del cliente al servicio de pago del cliente? Si el servicio de pago consulta los detalles de la compra directamente, se rompe el acoplamiento entre los servicios. Otra opción es introducir una base de datos compartida.
Siempre tendrá que haber algún tipo de compromiso en la arquitectura. Lo que se sacrifica es una decisión arquitectónica que depende en gran medida del panorama general (el diseño de todo el sistema).
Al no tener demasiados detalles sobre su sistema, iría con un mixed Acercarse. Es decir, tener una base de datos compartida para servicios que atiendan una lógica de negocio similar. Entonces CustomerShippingDetails y CustomerShoppingCheckout pueden compartir una base de datos. Pero un StoreItemsDetails tendría una base de datos separada.
Puede encontrar más información sobre el patrón de base de datos compartida para microservicios en Arquitectura de microservicios.
Agradecemos que desees añadir valor a nuestra información asistiendo con tu veteranía en las referencias.