What mistakes do candidates make on this question?

Lists approaches but doesn't explain trade-offs between them No discussion of exactly-once delivery, ordering guarantees, or schema evolution Missing real architecture: what goes between source and target? (Kafka, event schemas) Doesn't address the #1 CDC challenge in production: handling schema changes mid-stream No mention of DELETE handling, which is where most CDC implementations break

hardSystem Design/ArchitectureAnswer Breakdown

CDC / Change Data Capture — The System Design Answer That Gets L5+ Offers

Most candidates only know Debezium. See the comprehensive CDC answer covering log-based, trigger-based, and timestamp approaches with real architecture trade-offs.

Original Interview Question

CDC During Migration - explain approaches for real-time Change Data Capture

View Full Question

✗

The Weak Answer (What Most Candidates Say)

CDC captures changes (inserts, updates, deletes) from a source database and applies them to a target. Common approaches include timestamp-based CDC which uses a last_modified column, trigger-based CDC which uses database triggers to capture changes, and log-based CDC which reads the database transaction log. Debezium is a popular tool for log-based CDC.

⚠

Why This Answer Fails

1.Lists approaches but doesn't explain trade-offs between them
2.No discussion of exactly-once delivery, ordering guarantees, or schema evolution
3.Missing real architecture: what goes between source and target? (Kafka, event schemas)
4.Doesn't address the #1 CDC challenge in production: handling schema changes mid-stream
5.No mention of DELETE handling, which is where most CDC implementations break

✓

The FAANG-Level Answer

CDC captures row-level changes and propagates them downstream. Three approaches, each with real trade-offs:

1. Log-based CDC (recommended for production):

Reads the database's Write-Ahead Log (WAL/binlog/redo log).

Tools: Debezium, AWS DMS, Fivetran
Pros: Zero impact on source DB, captures all operations including DELETEs, preserves ordering
Cons: DB-specific (Postgres WAL ≠ MySQL binlog), requires replication slot management

Postgres WAL → Debezium → Kafka → Spark Structured Streaming → Delta Lake

2. Timestamp-based CDC:

Query rows where updated_at > last_sync_time.

Pros: Simple, works across any DB
Cons: Misses DELETEs entirely, requires indexing updated_at, clock skew between source/target can lose rows

3. Trigger-based CDC:

Database triggers write changes to a shadow table.

Pros: Captures DELETEs, works on any DB
Cons: Significant write amplification (2x writes), triggers degrade source DB performance

Production architecture I've built:

Source DB → Debezium Connector → Kafka (Avro + Schema Registry)
  → Spark Structured Streaming
    → Bronze table (raw CDC events)
    → Silver table (MERGE with dedup)
    → Gold table (business aggregates)

The hard problems interviewers want to hear about:

Schema evolution: Schema Registry with backward compatibility mode; downstream consumers handle new columns gracefully
Exactly-once: Kafka transactions + idempotent MERGE INTO (Delta Lake MERGE handles this natively)
Initial load + CDC: Full snapshot first, then switch to incremental — the handoff is where most implementations break
DELETE handling: Debezium emits tombstone events; downstream MERGE must handle op='d' by soft-deleting or hard-deleting

Key Takeaway

Listing three CDC types is a mid-level answer. The senior answer includes a real architecture diagram, explains the hard problems (schema evolution, exactly-once, DELETE handling), and shows you've dealt with the initial-load-to-CDC handoff.

Want to know if YOUR answer is weak or strong?

Paste your answer and get instant AI-powered feedback with a FAANG-level improved version.

Analyze My Answer — Free

3 free analyses per day. No sign-up required.

CDC / Change Data Capture — The System Design Answer That Gets L5+ Offers

Most candidates only know Debezium. See the comprehensive CDC answer covering log-based, trigger-based, and timestamp approaches with real architecture trade-offs.

Original Interview Question

CDC During Migration - explain approaches for real-time Change Data Capture

View Full Question

✗

The Weak Answer (What Most Candidates Say)

⚠

Why This Answer Fails

1.Lists approaches but doesn't explain trade-offs between them
2.No discussion of exactly-once delivery, ordering guarantees, or schema evolution
3.Missing real architecture: what goes between source and target? (Kafka, event schemas)
4.Doesn't address the #1 CDC challenge in production: handling schema changes mid-stream
5.No mention of DELETE handling, which is where most CDC implementations break

✓

The FAANG-Level Answer

CDC captures row-level changes and propagates them downstream. Three approaches, each with real trade-offs:

1. Log-based CDC (recommended for production):

Reads the database's Write-Ahead Log (WAL/binlog/redo log).

Tools: Debezium, AWS DMS, Fivetran
Pros: Zero impact on source DB, captures all operations including DELETEs, preserves ordering
Cons: DB-specific (Postgres WAL ≠ MySQL binlog), requires replication slot management

Postgres WAL → Debezium → Kafka → Spark Structured Streaming → Delta Lake

2. Timestamp-based CDC:

Query rows where updated_at > last_sync_time.

Pros: Simple, works across any DB
Cons: Misses DELETEs entirely, requires indexing updated_at, clock skew between source/target can lose rows

3. Trigger-based CDC:

Database triggers write changes to a shadow table.

Pros: Captures DELETEs, works on any DB
Cons: Significant write amplification (2x writes), triggers degrade source DB performance

Production architecture I've built:

Source DB → Debezium Connector → Kafka (Avro + Schema Registry)
  → Spark Structured Streaming
    → Bronze table (raw CDC events)
    → Silver table (MERGE with dedup)
    → Gold table (business aggregates)

The hard problems interviewers want to hear about:

Schema evolution: Schema Registry with backward compatibility mode; downstream consumers handle new columns gracefully
Exactly-once: Kafka transactions + idempotent MERGE INTO (Delta Lake MERGE handles this natively)
Initial load + CDC: Full snapshot first, then switch to incremental — the handoff is where most implementations break
DELETE handling: Debezium emits tombstone events; downstream MERGE must handle op='d' by soft-deleting or hard-deleting

Key Takeaway

Want to know if YOUR answer is weak or strong?

Paste your answer and get instant AI-powered feedback with a FAANG-level improved version.

Analyze My Answer — Free

3 free analyses per day. No sign-up required.

CDC / Change Data Capture — The System Design Answer That Gets L5+ Offers

The Weak Answer (What Most Candidates Say)

Why This Answer Fails

The FAANG-Level Answer

1. Log-based CDC (recommended for production):

2. Timestamp-based CDC:

3. Trigger-based CDC:

Production architecture I've built:

The hard problems interviewers want to hear about:

Want to know if YOUR answer is weak or strong?

Related Interview Questions

CDC / Change Data Capture — The System Design Answer That Gets L5+ Offers

The Weak Answer (What Most Candidates Say)

Why This Answer Fails

The FAANG-Level Answer

1. Log-based CDC (recommended for production):

2. Timestamp-based CDC:

3. Trigger-based CDC:

Production architecture I've built:

The hard problems interviewers want to hear about:

Want to know if YOUR answer is weak or strong?

Related Interview Questions