Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Build a field-level authority matrix and identify which operational edits were legitimate business state versus derived presentation. Define acceptable repair windows, customer notification thresholds, and whether historical intent can be reconstructed.
Establish scale assumptions
- Assume hundreds of millions of profiles and a comparison job that must not overload either store. Start with stratified samples and change recency cohorts before scheduling a full scan.
Functional and non-functional requirements
- Detect and classify every divergence, avoid overwriting newer valid data, make repairs idempotent and reversible, and preserve an audit trail. Stop the divergence source before large-scale repair.
High-level architecture
- Create a canonical change log or database outbox from the chosen authority. A reconciliation pipeline joins versioned snapshots, classifies differences by field and cause, generates repair proposals, and routes high-risk cases to review.
Data model and flow
- Compare normalized records with version, last writer, source event, and checksum. Repair commands include expected current version and provenance so conditional writes fail rather than clobber concurrent edits.
Consistency and transaction boundaries
- The system of record owns business fields; search becomes a derived projection. Legitimate search-only edits are migrated into explicit source commands or a separate authority before reindexing.
Failure modes and recovery
- Run repairs in rate-limited batches, checkpoint results, and retain before-images for reversal. If mismatch rate or customer errors exceed a threshold, stop the affected class without halting safe categories.
Security and privacy
- Reconciliation workers receive least-privilege field access, repair logs redact sensitive values, and human review is tenant-scoped. Historical operational tools must be disabled or redirected to the canonical write API.
Observability and SLOs
- Track mismatch rate by field, age, writer, tenant, and cause; repair success, conditional conflicts, recurrence, and serving impact. A zero scan mismatch is not enough—ongoing change-log reconciliation proves drift stays closed.
Capacity and cost
- Use hashes and range summaries to skip equal partitions, compare on replicas, and prioritize high-value or high-risk tenants. Retain evidence long enough for audit without duplicating complete sensitive records in logs.
Alternatives and trade-offs
- Blind canonical overwrite is fast but can destroy legitimate noncanonical edits. Field-aware classification takes longer but turns an ambiguous cleanup into a controlled business migration.
Evolution and migration
- Freeze new search-only edits, add versions and provenance, deploy outbox-driven projection, then reconcile recent and high-risk cohorts before full history. Remove the dual-write path only after recurrence metrics stay at zero.
What Staff and Principal candidates should emphasize
- Staff candidates do not simply say “rebuild the index.” They establish authority, account for valid exceptions, use conditional repair, and close the architectural cause that made divergence invisible.
Decision trade-offs
Repair policy
Option A
Overwrite destination from one canonical source
Option B
Field-level classification and conditional repair
Recommendation:Use field-level rules when multiple writers carried legitimate intent; reserve full rebuild for purely derived destinations.
Detection
Option A
Periodic full scans
Option B
Continuous log reconciliation plus sampled scans
Recommendation:Use continuous event reconciliation for fresh drift and periodic scans to detect pipeline omissions and historical unknowns.
Follow-up interview questions
- 01How do you decide which store wins for a field edited in both places?
- 02How do you repair without overwriting a change made after comparison?
- 03What evidence proves the divergence source is actually closed?
- 04When should affected customers be notified?
Common weak answers and mistakes
- 01Assuming the relational database is canonical for every field without investigating writer history.
- 02Writing repair results unconditionally and racing live customer updates.
- 03Running a destructive full scan before stopping the source of new divergence.
- 04Declaring success after one clean rebuild without continuous recurrence detection.
Interviewer evaluation rubric
Chooses a source and overwrites the other store without provenance, concurrency protection, or customer-risk analysis.
Creates an authority matrix, compares versions, rate-limits repair, and removes the unsafe dual-write path.
Classifies root causes, preserves valid exceptions, uses conditional reversible repairs, and proves recurrence stays closed.
Treats reconciliation as a governed product incident with audit, notification thresholds, cost prioritization, and a durable ownership redesign.