Database

 

Design


microservice-per-database is the cleanest design for security and isolation:

  • Security: Each service only gets DB credentials for its own data. Even if compromised, it can’t access other services.

  • Resilience: Schema changes in one service won’t break another.

  • Scalability: You can shard or move a single microservice’s DB independently later.

  • Migration Flexibility: Easier to move a single service to another DB engine (MySQL → Postgres) if needed.

Who Creates the Database?

  • Database itself (schema): One-time setup (can be automated via migration tool like Alembic or manual Base.metadata.create_all()).

  • Each service: Creates only its own tables at startup if missing (idempotent).

Benefits of This Approach

  • Encapsulation: Each service owns its schema slice.

  • Loose coupling: No service can accidentally query/modify unrelated tables.

  • Easier migrations: Per-service migrations possible if schemas diverge.

  • Security: Can enforce MySQL users with limited table privileges.

Separate Models Per Service

  • api_gateway: Needs jobs table (for uploads & job status) and maybe users (if it grows beyond OIDC).

  • worker: Needs jobs table (to read queued jobs, mark complete/failed).

  • parser_service: Doesn’t need DB access (just parses and returns).

  • logging_service: Needs logs table (stores centralized logs).

  • identity (OIDC): Needs authcodes (stores short-lived codes for login).

Each service imports only its models — they don’t see each other’s tables.

Comments

Popular posts from this blog

Feature: Audit log for one login, and identity service

Getting started - Build your data science lab environment

QA - Run #1 - Results