Requirements

Functional Requirements:

Support Get

Support Set

Support conditional updates

Non-Functional Requirements:

Highly durable

Availability >> Consistency

Highly scalable (Burst factor : 10x)

Low latency for get and set (<300 ms)

Read heavy ? read >> writes ?

Capacity Estimation

QPS:

Reads: 100k qps ?

Writes : 1k qps

Storage: 1kb * 100k * 1k (perday)

100 GB (pre day) ==> petabytes per year

API Design

GET v1/entities/{eId} -> Entity

SET v1/entities {Entity} -> {eId}

High-Level Design

Use HashMap with Doubly Linked List.

For Get and Set operation o(1)

Database Design

Key, Value

Detailed Component Design

.) Partition by the Id (as partition key)

Doesn't scale when nodes fail.

2.) Use Consistent Hashing. Use Murmur hash

Have nodes palced. on the ring. Now failures won't create a hotspot

Failed node now causes uneven load on the other node. even with consistent hasing. Hence use Virtual nodes.

For reads:

Use virtual nodes which have replaictaed data. Separate from the write path.

Cons: Stale data

Writes:

Single Node which takes writes ?

Pros: Easy.

Cons: Singlle ;point of failure

Gossip protocol. All nodes can take writes ?

Pros: No SPOF

Cons: Write conflicts