Using a separate database per microservice has direct security implications: it limits the blast radius of a breach but multiplies the number of surfaces that need to be individually secured.
Key Points: • If one service's database is compromised, the breach is contained to that service's data rather than exposing the entire system's data through one shared database. • Each database can apply access controls and encryption tailored to the sensitivity of its own data, rather than a one-size-fits-all policy across all data. • It simplifies auditing who can access what, since access boundaries align with service boundaries rather than needing fine-grained permissions inside one shared schema. • The trade-off is operational: every database needs to be independently patched, backed up, and monitored for compliance, which increases the overall security workload. • Consistent standards (encryption at rest, credential rotation, network policies) must be enforced across all databases, or the weakest one becomes the system's weakest link.
Example: If the Product Catalog Service's database is breached, isolating it means attacker access doesn't extend to the Payment Service's database holding sensitive transaction data, which sits behind separate credentials and network policies entirely.
Interview Tip: A concise interview answer is:
"Separate databases per service contain the blast radius of a breach to a single service and let each database apply access controls suited to its own data's sensitivity. The downside is that securing ten databases takes more coordinated effort than securing one, so consistent standards for encryption, patching, and credential management across all of them become important."