System Design Hacks :

1. ) Horizontal Scaling vs Vertical Scaling
2. ) Performance vs scalability
3. ) Latency vs throughput
4. ) Availability vs consistency
5. ) Consistency patterns- Weak consistency, Eventual consistency, Strong consistency
6. ) Availability patterns- Active-passive, Active-active
7. ) Replication- Master-slave and master-master
8. ) Caching | Cache update strategies
9. ) CDN- Pull CDN, Push CDN
10. ) Proxy- Forward Proxy,Reverse Proxy
11. ) Partition vs Sharding
12. ) Load Balancer- Layer-4 Load balancing, Layer-7 Load balancing
13. ) Write Heavy system — Reference-1 , Reference-2
14. ) Read Heavy system — Reference-1 , Reference-2
15. ) CAP Theorem -

16.) CP (Consistency with Partition tolerance) - MongoDB(Non Replicated),Redis, Memcached, HBase.

17. ) AP ( Availability with Partition tolerance) — Cassandra, DynamoDB, CouchDB, Riak, Elastic Search, MongoDB (Replicated).

18.) CA (Consistency with Availability) - MySQL, Postgres.

20.) Merkle Tree

21.) PACELEC Theorem

22.) Bloom Filter

23.) Consistent Hashing

24.) Gossip Protocol

25.) Read Repair

26.) ZooKeeper

27.) HeartBeat

28.) QuadTree

29.) Quorum consensus

Reference Short Notes:

MongoDB - MongoDB is strongly consistent by default — if you do a write and then do a read, assuming the write was successful you will always be able to read the result of the write you just read. This is because MongoDB is a single-master system and all reads go to the primary by default. If you optionally enable reading from the secondaries then MongoDB becomes eventually consistent where it’s possible to read out-of-date results. MongoDB also gets high-availability through automatic failover in replica sets: http://www.mongodb.org/display/DOCS/Replica+Sets

Redis Cluster consistency guarantees -

Redis Cluster does not guarantee strong consistency. In practical terms this means that under certain conditions it is possible that Redis Cluster will lose writes that were acknowledged by the system to the client.

The first reason why Redis Cluster can lose writes is because it uses asynchronous replication. This means that during writes the following happens:

Your client writes to the master B.

The master B replies OK to your client.

The master B propagates the write to its replicas B1, B2 and B3.

As you can see, B does not wait for an acknowledgement from B1, B2, B3 before replying to the client, since this would be a prohibitive latency penalty for Redis, so if your client writes something, B acknowledges the write, but crashes before being able to send the write to its replicas, one of the replicas (that did not receive the write) can be promoted to master, losing the write forever.

In Redis, High Availability is more than being Partition Tolerance. Redis has Master Slave architecture and if a Master fails then Redis Sentinels promote a Slave to be the new Master, making the entire solution highly available. And a master can fail (or become unavailable) for number of reasons (e.g. out of memory), it isn’t necessarily due to a Network Partition.

Then comes the case of Network Partition (P), and if (P) happens then Redis becomes unvailable in the minority partition. That’s why from CAP perspective, Redis is CP because it becomes unavailable in minority partitions. Please note it will still be available in majority partition.

You can read more about Redis High Availability here. Refer para titled “Consistency under partitions” for details around Partitioning.

Redis is also called eventually consistent because when (P) happens, the minority parition is still available for a few seconds and any writes done during that period on the minority parition will eventually get discarded.

Cassandra — click here