Introduce best practice multitenancy database definition

[Lex-van-Os]

To ensure that the platform will be able to work with multiple database connections, configuration of the database should be enhanced so that an instance of the application will be able to access its own database

[Lex-van-Os]

FIY:

• Middleware to handle multiple tenants (tenant identification & context handling)
• Connection pooling, considering autoscaling
• Dynamic connection string provider
• Horizontal scaling with Docker Swarm(?)
• Distributed cache data cross multiple instances -> Redis cache
• Rate limits / throttling
• Keep API stateless
• Connection string management regarding connection pools (Max Pool Size)
• Handle edge cases to avoid the entire application quiting upon encountering unexpected / unprovided values

[Lex-van-Os]

Dynamic Database Connection Strings: Each tenant should have its own database connection string. The application must dynamically choose the correct connection string based on the tenant making the request. Tenant Identification: You'll need a way to identify which tenant is making a request (typically from the request header, subdomain, or authentication token). Connection Pooling and Caching: Since each tenant uses a different database, manage connections efficiently to avoid repeatedly opening new connections for each request. Database Migrations: Migrations should be applied to each tenant’s database individually.