Category Archives: Без рубрики

You monitor migrations in prod by combining (1) the tool’s schema history table, (2) structured app logs around migration lifecycle, and (3) metrics/alerts. In interviews, I’m looking for all three. 1) Treat the migration history table as the source of … Continue reading →

Merge conflicts in changelog/migration files happen for one reason: multiple people append to the same “central” file or reuse the same version/id space. Fix that by making migrations append-only, isolated, and deterministic. 1) Stop editing a single “big” changelog Liquibase … Continue reading →

To simulate a migration safely before prod, you want repeatability, prod-like data, and the same execution path your deployment will use. Here’s the playbook I expect a senior backend engineer to describe in an interview. 1) Use a prod-like environment, … Continue reading →

1️⃣ What is a tree (in computer science)? Think of a tree like a family tree 🌳 One root (top person) Each node can have children No cycles (you can’t come back up in a loop) Key words (very important) … Continue reading →

the “best” approach depends on what kind of data you’re seeding. The senior answer is: don’t treat all seed data the same—split it into categories and choose the mechanism that matches the lifecycle. 1) Classify seed data first A) Reference … Continue reading →

1) First: decide what “legacy” means Usually one of: DB exists, no migration history table DB exists, some scripts exist but not reliably reproducible Multiple environments drifted (prod ≠ stage ≠ dev) Your approach depends on which one it is. … Continue reading →

“migrations that work on both MySQL and Postgres” is mostly about choosing the common subset, and when you can’t, splitting by DB in a controlled way. If you try to force 100% identical SQL, you’ll either lose important constraints or … Continue reading →

1️⃣ “No CREATE INDEX without CONCURRENTLY (Postgres) if table is large” What actually happens in Postgres CREATE INDEX (default) Takes a SHARE LOCK on the table Blocks writes (INSERT / UPDATE / DELETE) On large tables → lock can be … Continue reading →

Automating “validate before apply” is basically: (1) static checks + (2) dry-run SQL generation + (3) run against an ephemeral DB + (4) gate merge/deploy. Below are the best-practice ways teams do it for Liquibase and Flyway. 1) Static validation … Continue reading →

for zero-downtime with Flyway/Liquibase the tool is not the magic — the migration strategy is. The standard interview answer is Expand → Migrate → Contract (aka parallel change), plus operational guardrails. Core pattern: Expand → Migrate → Contract 1) Expand … Continue reading →