4 ms·

Feeding production data into two different paths to compare them is obviously valuable. Does anyone have any good reasons why this has to happen in online code

Feeding production data into two different paths to compare them is obviously valuable. Does anyone have any good reasons why this has to happen in online code and can't happen against database replicas in offline mode? I always feel that it would be great to be able to do this with code that has side-effects (eg. anything that changes the database) but I've never seen a general purpose solution for this. The README mentions using a write replica, but how do you deal with data drifting in case of bad writes?

FrancoisBosun 7y ago
Maybe because of the large increase in complexity?
dyeje 7y ago
They wrote a good blog post about using this gem back in 2016: https://github.blog/2016-02-03-scientist/ https://github.blog/2016-02-03-scientist/
jauco 7y ago
There’s goreplay[0]. But once you start using that you quickly find that many parts of your app use random data (such as uuids) or clock data (timestamps etc) getting these synced between prod and replay or ignored on replay is quite a hassle. [0]: https://goreplay.org/ https://goreplay.org/
hamandcheese 7y ago
Another possibility might be to do the side effects in a transaction that gets rolled back?