How would you capture changes from a vendor database where you cannot enable log-based CDC?

## Start by naming what you lose Without the change log you lose three things: deletes, intermediate versions, and low latency at low cost. Every option below recovers some subset, and the job is to pick deliberately and then be honest about the remainder. The most common failure here is not the technical choice; it is delivering a polled extract while consumers believe they have a replica. ## The ladder **1. Get access after all.** Ask specifically, not generally: a read-only replication role on a dedicated replica; logical-level logging enabled on a standby rather than the primary; a supported managed export or share. Vendors refuse "give us your WAL" and often accept "a replica with a capture role, at our cost, with a retention cap so we cannot affect your primary". Offer the safeguard that removes their real objection — the slot risk — before they raise it. **2. Use the vendor's own event interface.** Many SaaS-backed databases sit behind a product that already emits webhooks, an event stream, or an audit-log API. This is their supported surface, so it survives their upgrades, and it usually includes deletions. Weaknesses to check: delivery guarantees (almost always at-least-once, sometimes best-effort with no replay), whether history can be replayed after an outage, payload completeness versus a change-notification that forces you to call an API back, and per-call rate limits which turn a burst into hours of backfill. **3. Triggers, if you may create objects.** Row triggers into a shadow table recover deletes and every intermediate version. The price is writes inside their transactions and a shared failure surface — a trigger error fails their application's writes — which is exactly why a vendor who owns the database usually says no. If they say yes, scope it to a few tables, keep the trigger body trivial, and own the audit table's drain and purge. **4. Polling plus reconciliation.** The floor. Poll a monotonic marker for inserts and updates, and close the delete gap with a scheduled comparison of primary-key sets between source and target — cheap relative to full rows, and the only way a poll ever learns about a removal. For small tables, extract everything and compare row hashes, which additionally catches rows updated without the marker moving. Both are periodic, so deletes have a detection latency measured in the reconciliation interval, and you must publish that number. **5. Application-level change events.** If the vendor's product is being built alongside yours, the right long-term answer may be neither: have the producing application emit domain events as part of its own transaction. That is a product commitment, not a pipeline choice, and it belongs in a roadmap conversation rather than an incident. ## What to decide beyond the mechanism - **Per-table, not per-source.** A reference table of 400 rows can be fully re-extracted and hash-compared hourly, which gives perfect delete accuracy for nothing. A 300-million-row transaction table cannot. Applying one strategy to a whole source is how teams end up paying full-extract cost on the big table and carrying the delete gap on the small one. - **Cost shape.** Polling cost scales with table size times frequency, and someone else's database pays it. If the vendor charges for compute or throttles you, freshness is now a budget line, and the honest answer to "can we have it every minute?" may be no. - **Blast radius on their side.** You are load on a system you do not operate and cannot see. Rate-limit yourself, schedule heavy reconciliation off-peak, and expect to be asked to back off. - **Reversibility.** Land the raw extract before transforming, so that when log access does eventually arrive you can switch capture without rebuilding everything downstream. Assume you will re-seed at least once. - **Verification.** Whatever you choose, run a continuous parity check — row counts and a key-set difference against the source — because with no log you have no other evidence that the copy is right. ## The deliverable The answer an interviewer is listening for at this level is not a tool. It is: I would try to buy or negotiate the capability first; failing that I would choose per table from a ranked ladder; I would state the resulting guarantee in the data contract downstream consumers read — freshness, delete detection latency, no intermediate states — and I would instrument parity so divergence is detected by us rather than reported by a stakeholder. A team that documents "deletes are detected within 24 hours" is in a defensible position; a team that quietly delivers a lossy copy labelled "replica" is not.