Un hared-database-per-service patrón

En el shared-database-per-service patrón, varios microservicios comparten la misma base de datos. Debe evaluar detenidamente la arquitectura de la aplicación antes de adoptar este patrón y asegurarse de evitar las tablas calientes (tablas individuales que se comparten entre varios microservicios). Todos los cambios en la base de datos también deben ser compatibles con versiones anteriores; por ejemplo, los desarrolladores solo pueden eliminar columnas o tablas si las versiones actuales y anteriores de todos los microservicios no hacen referencia a los objetos.

En la siguiente ilustración, todos los microservicios comparten una base de datos de seguros y una política de IAM proporciona acceso a la base de datos. Esto crea un acoplamiento en el tiempo de desarrollo; por ejemplo, un cambio en el microservicio “Ventas” requiere coordinar los cambios de esquema con los del microservicio “Cliente”. Este patrón no reduce las dependencias entre los equipos de desarrollo e introduce un acoplamiento del tiempo de ejecución, ya que todos los microservicios comparten la misma base de datos. Por ejemplo, las transacciones de “Ventas” de larga duración pueden bloquear la tabla de “Clientes” y esto bloquea las transacciones de “Clientes”.

Debería considerar la posibilidad de utilizar este patrón si:

• No querrá refactorizar demasiado su base de código existente.

• Implemente la coherencia de datos mediante transacciones que proporcionan atomicidad, coherencia, aislamiento y durabilidad (ACID, por sus siglas en inglés).

• Desea mantener y operar solo una base de datos.

• Implementar el database-per-service patrón es difícil debido a las interdependencias entre los microservicios existentes.

• No desea rediseñar por completo su capa de datos existente.