Runtime Tenant Onboarding for Replicated Database-per-Tenant Spring Boot Applications

Software-as-a-service systems holding sensitive records, such as clinical laboratory data, are often built on the database-per-tenant isolation pattern, which gives every customer a physically separate database. The pattern is well described for a single application instance, but two problems remain open once the application runs as several replicas behind a load balancer: adding a tenant and its database without restarting the service, and keeping the tenant-to-database routing tables of all replicas consistent. This paper presents a method addressing both for applications built on Spring Boot. It combines a control-plane database holding tenant connection metadata, an idempotent provisioning workflow, request-scoped tenant context, a routing table replaced atomically and consulted without fallback, and a broker event that causes every replica to reconcile against that database. A prototype was deployed on Kubernetes and measured. Every replica converged in all 160 provisionings at 3 and 10 replicas. The median was 419 ms at 3 replicas and 595 ms at 10 for up to 20 tenants, rising to 4.9 s at 120 tenants, and provisioning latency did not grow with the number of existing tenants. A routed request cost a median of 3.90 ms. An idle tenant holds no database connection, because pools release connections when idle, and adds about 10 KiB of live heap beyond the first 25 tenants, so neither cost grows linearly with tenant count.