Foreign key references usually can't be "broken" in any system where "foreign key references" make actual sense, namely RDBMS systems: that's the guarantee they provide by definition.
Sure, there are databases that might misappropriate the term, but as an engineering community, we should not let that slide.
It's obvious that velocity at Twitter is not about being as fast as safe today: it's simply about being fast.
I don't think that's necessarily the wrong approach from an engineering outcomes perspective (iow, it can work well with an early phase product with early adopters), but it is sure to alieniate most of the existing userbase, when that userbase was the one thing Twitter had going for it.
I simply meant a key that is intended to refer to another entity, but as you said its common for RDBMSs to enforce that referential integrity, but you can also have a DB like mongo or dynamo which store an ID , but when you de-refer it (look up the other entity by ID, perhaps by an API call to a peer microservice) the item is no longer there.
It gets even weirder with denormalization of some of the data where maybe you can get the title or preview of an item, but going (clicking) into it is broken.
Sure, there are databases that might misappropriate the term, but as an engineering community, we should not let that slide.
It's obvious that velocity at Twitter is not about being as fast as safe today: it's simply about being fast.
I don't think that's necessarily the wrong approach from an engineering outcomes perspective (iow, it can work well with an early phase product with early adopters), but it is sure to alieniate most of the existing userbase, when that userbase was the one thing Twitter had going for it.