* you have two competing subscription id columns.
* a uuid is not a string, it is a 128 bit integer. If your database limits to 64 bit integers then use a 64 bit integer for the id instead of a string, or use an array of 128 bytes.
* you have two competing subscription id columns.
* a uuid is not a string, it is a 128 bit integer. If your database limits to 64 bit integers then use a 64 bit integer for the id instead of a string, or use an array of 128 bytes.
That's kind of rational, id is their own internal id. subscription_id is the id on stripe. A better name would be stripe_id.
Also, is there a way to set up foreign key constraints on `userId` with this ORM? That seems like another oversight.
Sure you should have tests, sure you shouldn't copy paste code you don't understand and you shouldn't push directly to production.
But, regardless of all that, the main issue of all this incident is not the rookie mistake itself, is how they didn't have logs or alerts and it took them 5 days of customer complaining to find out they had "duplication errors" in the db.
That's the thing that should have been fixed first and extensivly mentioned in the post-mortem
Many ORMs represent UUID as a string.