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: Needsjobstable (for uploads & job status) and maybeusers(if it grows beyond OIDC). -
worker: Needsjobstable (to read queued jobs, mark complete/failed). -
parser_service: Doesn’t need DB access (just parses and returns). -
logging_service: Needslogstable (stores centralized logs). -
identity(OIDC): Needsauthcodes(stores short-lived codes for login).
Each service imports only its models — they don’t see each other’s tables.
Comments
Post a Comment