top | item 36948247

(no title)

abhinav-t | 2 years ago

Without getting into a discussion on what is the correct definition of "edge", I think the article offers 2 solutions to this problem: you have an internet app and you need to provide your users with low-latency reads while maintaining uniqueness constraint and read-your-writes consistency.

The article favours dealing with latency during writes while making some assumptions, - most internet apps are read-heavy (reasonable, but what if it's not the case for you?) - you do not need sharding, all regions have all the data (what if you have a ton of data that is growing quickly? what if you have durations where some data is heavily contended for?) - the primary replica used for writes is highly available (how do you automate handling of the primary replica failure or primary replica getting partitioned?)

Another approach to consider would be Amazon Dynamo style databases (Cassandra, Riak etc.) which can help when the above assumptions are not met, - Dynamo was designed to be always-writable and suitable for heavy writes and reads as well (e.g. the paper mentions teams using it for catalog data with R=1 and W=N) - data is partitioned/sharded using a variant of consistent hashing, which helps with large data volumes and limiting the impact of hot spots as well - failure detection and leader election help automate handling the partitions for which a failed node was holding a primary replica

discuss

order

No comments yet.