Motive: Designing a service through which users can upload and see the pictures like feeds on other social media platforms. It’s a photo-sharing app called Instagram. Here, we are not designing a complete architecture. The Instagram System Design post is an overview of the architecture for learning purposes.
What is Instagram?
A social networking platform for photo-sharing on which users can upload pictures, see the pictures in feeds, comment on pictures, like the pictures, like the comments, etc. More than this, messaging/chat is also provided. Users can also upload and see videos that call reels on Instagram.
Users can choose whether their photo/video can be publicly seen by anyone or seen by only a specific set of people. Users can also share their photos and videos on other social networking platforms like Facebook, Twitter, etc.
Functional Requirements:
1. Users should be able to upload/delete photos and videos and view photos and videos.
2. Users can perform searches based on photos/video titles, captions or hashtags.
3. Users can follow other users.
4. Users should be able to see photos in their feed consisting of top photos from all the others the user follows.
Non-functional Requirements:
1. Service should be highly available.
2. Latency of the system should be as low as possible like 200ms for feed generation.
3. Consistency can delay in the favour of availability, if a user doesn’t see a photo for a while; it should be fine.
4. The system must be reliable. Any uploaded picture or video should never be deleted.
Analysis:
1. System is Read-heavy. We build a system that retrieves data as quickly as possible.
2. Efficient storage system for storing a large number of photos and videos.
3. Low latency is expected due to heavy reads.
4. Data reliability should be 100% required.
We need to support two scenarios, one to upload photos and the other to view/search photos. We use object storage servers to store photos and videos. Database servers are used to store metadata information. Designing a database in starting gives us an idea of data flow.
Database Tables: Photo Table, User Table, UserPhoto, UserFollow.
1. We need to store data about users, their descriptions, their uploaded photos/videos, and the people they follow.
2. We can store photos in distributed file storage like AWS S3.
3. The Photo table will have all data related to pictures and videos. We index on (PhotoID, CreationDate) since we need to fetch recent photos first.
4. For the ‘Photo Table’ table, all information of photos /videos is stored in a Database where the ‘key’ would be the ‘PhotoID’ and the ‘value’ would be an object containing PhotoLocation, creation timestamp, etc.
Note: Cassandra gives you the facility of having data type as a set or list in which to carry a list of data in a single column and row otherwise using MySQL needs to create separate tables.Example below:
5. For the ‘UserPhoto’ table, the ‘key’ would be ‘UserID’, and the ‘value’ would be the list of ‘PhotoIDs’ the user owns, stored in different columns. We will have a similar scheme for the ‘UserFollow’ table.
Note: Wait for more content