The accepted practice to solve this sort of need is not to write stored procedure code to enforce referential integrity. No matter how well it is written, if you proceed with such a solution, you have already failed.
You have already failed because such a solution will either always fail eventually and result in data integrity problems, or it is written so effectively to always succeed but it requires a distributed transaction that will lock the involved tables so vigorously and inefficiently that you will have concurrent session performance nightmares.
The accepted practice is to use the robust, well-tested, high-performing replication features of the database platform(s), and then establish referential integrity conventionally through unique keys and foreign keys, letting the database do what it does many thousands of times better than you writing stored procedure code to enforce referential integrity.
Every serious database developer at one point in time dabbles in roll-their-own replication and except in the simplest of circumstances, they always fail miserably.