Change data capture streams row level changes out of a source database. Log based CDC reads the transaction log directly, so it captures inserts, updates, and hard deletes in commit order with almost no load on the source. Polling an updated_at column is simpler but misses hard deletes, misses intermediate states between polls, depends on the application maintaining the column, and can miss rows on clock or transaction boundary issues.
Why interviewers ask this
This is a real architecture decision on almost every ingestion project. Interviewers want to hear the specific weaknesses of timestamp polling, particularly deletes and in flight transactions, and whether you understand what log based CDC demands from the source: replication slots, log retention, permissions, and a plan for the initial snapshot.
How to structure your answer
- Define CDC and name the two main implementations.
- List exactly what timestamp polling misses.
- Describe what log based CDC requires from the source database.
- Explain the snapshot plus stream handoff.
- Say how you would handle schema changes on the source table.
Example answer
CDC is about getting row level changes rather than re reading whole tables. Log based CDC, with something like Debezium reading the Postgres write ahead log or MySQL binlog, gives you every insert, update, and delete in commit order and puts almost no query load on the primary. Polling an updated_at column is much easier to set up, and it is fine for slowly changing reference data, but it has real holes. It cannot see hard deletes at all, so rows silently persist downstream forever. It misses intermediate states if a row changes twice between polls, and it depends on every writer remembering to set the column, which one legacy job in our estate never did. Log based CDC has its own operational cost. You need a replication slot, and if your consumer stalls the log will not be reclaimed and the source disk fills up, which is a genuinely dangerous failure. So I monitor slot lag as a first class alert alongside pipeline lag.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you handle the initial snapshot without blocking the source?
- What happens if a Postgres replication slot falls behind?
- How do you represent a delete downstream in an append only table?
Related data engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions