

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Database-per-service patrón
<a name="database-per-service"></a>

El acoplamiento flexible es la característica principal de una arquitectura de microservicios, ya que cada microservicio individual puede almacenar y recuperar información de su propio almacén de datos de forma independiente. Al implementar el database-per-service patrón, usted elige los almacenes de datos más adecuados (por ejemplo, bases de datos relacionales o no relacionales) para sus requisitos empresariales y de aplicación. Esto significa que los microservicios no comparten una capa de datos, los cambios en la base de datos individual de un microservicio no afectan a otros microservicios, otros microservicios no pueden acceder directamente a los almacenes de datos individuales y solo se accede a los datos persistentes. APIs La disociación de los almacenes de datos también mejora la resiliencia de la aplicación en general y garantiza que una única base de datos no pueda ser el único punto de fallo.

En la siguiente ilustración, los microservicios de «Ventas», «Cliente» y «Cumplimiento» utilizan diferentes AWS bases de datos. Estos microservicios se implementan como AWS Lambda funciones y se accede a ellos a través de una API de Amazon API Gateway. AWS Identity and Access Management Las políticas (IAM) garantizan que los datos se mantengan privados y no se compartan entre los microservicios. Cada microservicio usa un tipo de base de datos que cumple con sus requisitos individuales; por ejemplo, “Ventas” usa Amazon Aurora, “Clientes” usa Amazon DynamoDB y “Cumplimiento” usa Amazon Relational Database Service (Amazon RDS) para SQL Server.

![\[Database-per-service diagrama de patrones\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-data-persistence/images/enabling-diagram1.png)


Debería considerar la posibilidad de utilizar este patrón si:
+ Se requiere un acoplamiento flexible entre sus microservicios.
+ Los microservicios tienen diferentes requisitos de cumplimiento o seguridad para sus bases de datos. 
+ Se requiere un control más detallado del escalado.

El uso del database-per-service patrón presenta las siguientes desventajas:
+ Puede resultar difícil implementar transacciones y consultas complejas que abarquen varios microservicios o almacenes de datos. 
+ Debe administrar varias bases de datos relacionales y no relacionales. 
+ *Sus almacenes de datos deben cumplir dos de los requisitos del [teorema CAP](https://www.ibm.com/cloud/learn/cap-theorem): *consistencia*, *disponibilidad* o tolerancia a las particiones.* 

**nota**  
Si usa el database-per-service patrón, debe implementar otro patrón para implementar consultas que abarquen varios microservicios. Se puede usar [Patrón de composición de API](api-composition.md) (que se puede acelerar con el [Patrón CQRS](cqrs-pattern.md)) o el [patrón de abastecimiento de eventos](service-per-team.md) para crear resultados agregados.