46 people whose identity was a phone number

The €100 Lakehouse — 9/12

46 members stopped existing because a migration used phone numbers as identity. They took €8,511 of revenue with them.

The importer used the phone — an optional field — as identity key. I reimplemented its XLSX reader and norm_phone verbatim and replayed the run line by line:

→ 42 skipped: no usable phone
→ 10: duplicate phone (a partial unique index)
→ 4: birth date in the future (file typos)
→ 2: phone already owned by someone else

1,437 rows → 1,379 imported, 58 skips — matching the original log exactly.

The tell, among the members created: not one blank phone, and no two alike — in a population where families demonstrably share a number. That's not a coincidence, it's the index.

The family signature: adjacent member numbers — 421/422, 622/623, 757/758. Signed up together; one survived.

And the rankings disagree. "No phone" cut the most heads (20 members) and put €0.00 in May's hole — dormant accounts. The 4 future-DOB typos were all still paying: €269 in May. Rank defects by the money they bleed today, not the heads they cut — only one of those rankings pays bills.

Losing your person meant losing every payment with them: 138 payments, €8,511 all-time.

So which system was lying — the new one or the old one? Next week: the verdict nobody dares write.

What's the most innocent-looking field you've seen promoted to an identity key — and what did it silently delete?

Databricks · dbt · Airflow · Terraform · AWS

P.S. New tech post every Wednesday.

#100EuroLakehouse #DataEngineering #DataMigration