Skip to main content

Notification Migrations

Summary​

The extracted schema has exactly one migration and one model snapshot. It is applied automatically at startup unless an environment variable suppresses it.

Audience​

DevOps engineers, engineers, architects, QA and support.

Reference Content​

The verified reference material for this topic is set out in the sections below.

Migration inventory​

ArtifactCountFile
Migration120260705113059_InitialNotificationSchema.cs
Migration designer120260705113059_InitialNotificationSchema.Designer.cs
Model snapshot1NotificationDbContextModelSnapshot.cs
Design-time factory1declared in NotificationDbContext.cs

The schema has never been revised — the initial migration is also the current one, so the snapshot and the migration describe the same model.

Migration ownership​

What the migration creates​

The migration ensures the notification schema exists, then creates 7 tables and 14 indexes. It issues no foreign-key statement, no check constraint and no default constraint, which matches the model exactly.

Startup migration behavior​

Program.cs applies migrations during startup, before the host begins serving. The block is guarded by an environment variable that, when set to the string true, skips both migration and seeding. Migration runs inside a temporary service scope resolved from the built application.

Two operational characteristics follow. Applying migrations at startup means every instance attempts it, so a multi-instance rollout has concurrent migration attempts. And because the guard also skips seeding, suppressing migrations in an environment silently suppresses default-template seeding as well.

Design-time factory​

The factory implements the Entity Framework design-time interface so tooling can build a context without the host. It reads a connection string from an environment variable and falls back to a hard-coded local development value when unset. The presence of a credentialed development fallback in source is noted as a governance observation; its value is not reproduced here.

Monolith migrations​

The monolith's three notification tables live in its own shared migration history, which is separate from and unrelated to the extracted service's. No migration in either history references the other.

Verified absence​

There is no idempotent SQL script artifact, no rollback or down-migration testing, no migration bundle, no seed data embedded in the migration, and no migration-history table configuration override.

Classification​

Implemented.

Requires confirmation​

Whether startup migration is appropriate for multi-instance deployment, and how the schema is intended to be evolved under load, require confirmation.

See Also​

Keywords​

  • Notification database
  • Migrations
  • Draft database documentation

Source References​

  • microservices/src/notification-service/Infrastructure/Migrations/20260705113059_InitialNotificationSchema.cs
  • microservices/src/notification-service/Infrastructure/Migrations/NotificationDbContextModelSnapshot.cs
  • microservices/src/notification-service/Infrastructure/Migrations/20260705113059_InitialNotificationSchema.Designer.cs
  • microservices/src/notification-service/Program.cs
  • microservices/src/notification-service/Infrastructure/NotificationDbContext.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly