Hacker News Reader

Comment by lalwanivikas | Hacker News Reader

you need to provide more details to get any useful advice. but just based on what you have described, any db would do the job. add a caching layer and you have your low latencies.

again, what is the traffic and bandwidth load like? peak and average values? what kind of data are you planning to store? small values but huge volumes or the opposite? a lot will change based on your system requirements.

View on HN

To clarify: let's say I have servers in two locations A and B that are 200ms from each other. When I issue a write to the db in A I don't want to wait (multiples) of the 200ms before it returns. I don't really care whether the write appears to a reader at B in 5s or 50 minutes but of course the writes have to be at least causally consistent.

I won't have millions (realistically not even thousands) of users and the database will be comparatively small.

I've looked at NDB cluster but it feels quite complicated to setup and maintain

Can you write to a single rdms C, and maybe cache reads at A and B?

Look at MySQL asynchronous replication.

Consider Couchbase. It uses a combination of asynchronous writes and automatic replication to do a pretty good job of giving low latency writes even at high volume, while also ensuring data integrity. And since reads are served from the cache if possible, you usually get really good read performance as well.

Reply on news.ycombinator.com