> it is only practical for situations where the write rate (<100/s total) and data volumes (<10GB total) are low.
This comment from the GitHub project page is pretty important. Configuration data often sees slow change, and isn't huge so a custom approach seems viable. I wonder how close they are to that 100/s ceiling.
There's also an unmentioned transition to eventual consistency happening here:
> The implications of this decoupling is that the data at each instance is usually slightly out-of-date (by 1-2 seconds).
> The reader API provides a way to fetch an approximate staleness measurement that is accurate to within ~5 seconds.
That's could lead to more complex application logic or risk of confusing users with stale behavior. No free lunch here.
1 comment
[ 2.4 ms ] story [ 10.0 ms ] threadThis comment from the GitHub project page is pretty important. Configuration data often sees slow change, and isn't huge so a custom approach seems viable. I wonder how close they are to that 100/s ceiling.
There's also an unmentioned transition to eventual consistency happening here:
> The implications of this decoupling is that the data at each instance is usually slightly out-of-date (by 1-2 seconds).
> The reader API provides a way to fetch an approximate staleness measurement that is accurate to within ~5 seconds.
That's could lead to more complex application logic or risk of confusing users with stale behavior. No free lunch here.
[1] https://segment.com/blog/separating-our-data-and-control-pla...
[2] https://github.com/segmentio/ctlstore