Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Clearly, our design is Key, value store, where use is going to query on short url and we'll return the long url.

So, we'll require highly scalable, available and consistent db.

Since, our data is very much structured, we can also use RDBMS database that will have primary key as shortUrl. But we generally face problem as RDBMS is not horizontally scalable. We can shard this database.

say, every query starting with A - K will go to the node1 K - Z to node2 and so no. And if one node goes down, we can have a replica of the same node like leader/follower architecture.

but, this possess 1 serious concern.. say in future, we wants to scale up and wants to add more database nodes.. in that case, we've to do a lot of re-balancing.

We can overcome by this using consistent hashing.

or, we can also go with cassandra database which is Highly available, partition tolerant and we can tune the consistency to ALL. When a write request is coming on the coordinator node and we will write this request to all the replica node and then we'll return the ack for the write. Here, downside is, our read will become slow but we can achieve strong consistency.

But, we can read from any of the replica and will get the correct value.

Also, cassandra maintains Write ahead log and memtable and retains some data in memory. which will be v. fast than accessing disc. Once, data becomes huge, it will convert data to LSM tree and writes to SSTables. (Sorted String Tables, its some sort of AVL/ RED black trees)

Also, we are writing data / flushing data in batch, so writes are also optimized.

Verdict:

Use cassandra with primary key as shortURL and consistency param = WRITE TO ALL REPLICAS

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10