Writing to a system that has no write API, without ever risking live data
To sell online and manage memberships, a business needed sales written into its point-of-sale database exactly as the vendor's own software would write them. We built an isolated lab to capture that behaviour, rather than guess at it.
At a glance
- 819,792
SQL log lines analysed
- 14
rebuild scripts
- 5,347
customer records replaced with synthetic ones
- 0
routes from the lab to the live site
The challenge
The point-of-sale system exposes no supported way to write sales, packages or payments. Getting it wrong wouldn't just fail: it could corrupt the records the business trades on every day.
The only safe approach was evidence. See exactly what the vendor's software does for each scenario, in a place where nothing can reach the live site, and refuse to write anything we haven't watched happen.
Architecture
Swipe to explore the diagram
Data is scrubbed before it enters the lab, the lab can't route to the live site, and the native writer has to match the vendor's own output row for row.
What we built
The lab
- An isolated hypervisor host with a database VM and a Windows VM running the vendor's client and API, on a segment denied any route to the live site
- 14 numbered, idempotent scripts that rebuild it from install media pinned by hash
- A scrub after every refresh that replaces each customer with a synthetic identity, verified by before-and-after digests
The evidence
- Every HTTP request and SQL statement captured per scenario
- A week of background activity analysed (819,792 log lines) to prove the vendor's own jobs never write the business tables our writer will touch
The writer
- A journal of every statement, a unique idempotency key and a vendor-compatible number allocator
- A scenario registry that refuses any scenario without a capture behind it
- A parity harness that diffs every row tied to two receipts, one from the vendor and one from us, and refuses any target but the lab
Engineering decisions
Evidence first, by construction
A scenario isn't writable until it has been captured. The registry refuses it, so nobody can skip the step by accident.
Physical separation
Firewall rules deny lab-to-live routes in both directions, and data moves from the NAS to the bench directly, never via someone's laptop.
Diff whole rows, not fields
Parity is proven by diffing every row a receipt touches, which catches the side effects field-level assertions miss.
Live writes are attended
The writer checks its target host against configuration and refuses a mismatch, and the first live write is a supervised step.
Outcome
The lab is built, scrubbed and baselined, the vendor's background behaviour is characterised, and the write layer is specified with refusal as its default.