You may me able to architect your application to do well-enough without Foreign Keys yet still require features that key-value stores do not provide, like SQL, triggers, etc.

In the specfic case of MySQL, while still horrifying (I agree with you! but it is one of the things you some times have to do at scale), you can create the Foreign Key constraints but then disable their verification and periodically look for violations, as described here: https://www.percona.com/blog/2011/11/18/eventual-consistency...

The application still has foreign key references and JOIN, which you don't get in a k/v store, you just don't have the actual CONSTRAINT. MySQL worked this way for literally decades with the MyISAM storage engine that does not have referential integrity constraints, it just allows the FOREIGN KEY syntax to pass silently.

It repeatedly retrieves the parent row. Look at the URL when replying on HN and change the id by adding a few 0's - the app prevents a comment from being added if the ID isn't found. Of course, this doesn't prevent a developer from circumventing the apps constraint logic.