MovieBuzz System Design: Coding End To End System From Scratch!
Database Choice

We want to store 10 million user details and 5 million movie details. We are looking for a highly available database. We can compromise with the Consistency of user details and movie details. The best choice for storing this big data is Cassandra.

When the user opens the application we want to show a list of running movies in the user’s city. Once a user selects a movie, we want to show the user a list of the nearest Theatres in the user’s city running the shows for given movie. We can’t achieve this using Cassandra. We need a search engine for that. We can use ElasticSearch to solve these use-cases.

Cassandra is designed for heavy writes. As any write operation is just adding data to Memtable in RAM and appending data to commit log in the target node. So we can store all the movies and theatres details in Cassandra. The read operation in Cassandra is performance intensive. As reads have to go through n number of SSTables on disk via multiple caches in memory and disk. So we should try to avoid reading from Cassandra as much as we can.

Whereas for ElasticSearch, write operation is costly as every time we insert a document in ElasticSearch, we are indexing that document. So we should only store Movies and Theatres fields on which we want searchability. We are not allowing users to search movies by Actor names, so we should not store Actors associated with movies in ElasticSearch.

We can’t compromise on consistency in case of which seats are available and we don’t want multiple users to book the same seats in the same theatre. So we need a highly consistent relational database even if at the cost of availability. For this use-case, we can go with the sharded SQL database.
['Bhushan Gosavi']
['System Design Project', 'Kafka', 'Kubernetes', 'Cassandra', 'Elasticsearch']