One idea is that if an email address is updated the bugs are not updated straight away (inconsistency). They are updated as load on the system allows. Then yo

One idea is that if an email address is updated the bugs are not updated straight away (inconsistency). They are updated as load on the system allows. Then you control the spikes as you see fit, to match your performance requirements. Another ideas is you keep a list of un-applied changes and post process with those (fix the inconsistency). Banks used to do those when I was at university (balance = overnight balance + todays transactions, plus an overnight batch to get the balance up to date.) If you original system was normalized, and did not fit in memory, then the joins cost (disk_access_time * items), which could have been 2 seconds of disk io. The notion that a db round trip is worse than a disk io is just wrong.