System design for Social media platforms.

This is the first phase of a sequel for building the server side of social media applications that includes activities like garnering followers, following users, creating posts and comments, liking posts, getting posts, feed and message notifications,searching for posts and sending private messages.

It is a matter of fact that system design or software architecture is the most fundamental section to which softwares are built. We would be using social media applications as a case study in this sequence of articles, with this very first one rendering the blue-print and most fundamental guideline upon which our later subjects would be predicated upon.

The Sub-sections this article would be covering includes:

• ER Diagram and Entity Peculiarities.

• Inter & Intra Entity Connections.

• User Security.

ER Diagram and Entity Peculiarities :

Entity relationship diagram for social media platform.

connection symbols and their meanings

This is the Entity Relationship diagram and the representation of the inter/intra connection symbols. The ER Diagram comes in the pre implementation phase and establishes the most efficient and effective infrastructural network between every logic and an ordered chunk of data regarded to be described as a wholesome entity.

I'd be running through each and every of the entities, its' uniqueness, inter and intra(in cases where applied) connections to other entities.

Note the symbols used aswell going forward.

• pk : private key.

• fk : foreign key.

• ObjectiD : although a string, but can be populated to represent the object to which it is a private key to.

• [ ] : symbolises an array of whatever field contained in it.

I divided the entities into two.

• Data entities

• Soft entities

Data entities: Data entities are the entities that have an actual schema representation on the database, a model representation, they contain unique data that can be saved and retrieved on the database which has a unique pointer entry value (pK) to which the database could be queried with, and the corresponding document(s) fetched.

i) User_Profile : The user profile is central to the product. It interacts with other data entities and logic entities. Looking round the various connections made to reference the User_profile from the ER Diagram above, it's either a one and only connection or a one to many connection. It shows the indispensability of the user_profile and while writing the code for other entities it's imperative to ensure that the user field is always represented in the entity model, In the entity diagram above it was represented in various alias per entity, user, user_id, sender_id, followings, followers etc. All fields in the User_Profile model is quite common and some reoccurs in other entities except the Socket_Ids. The Socket_Ids type here is mixed because it could either be null or an inactive key when a user goes offline or a string and active key when a user is connected to the server. The Socket_id is what enables the node.js script to send notifications and private chats to a particular user. It's not necessarily in the PK section because the null values are not unique and it's activeness only exist throughout the lifetime of the user's connection.

ii) Message : This model embodies every single chat sent to any particular user with their data stored on the site, whether their socket_id is active or inactive. The message entity is only connected to the User_Profile, this shows its exclusivity and privacy. The only fk represented in the Message entity is the chat_id(although it does not have entity of its own in my representation). The chat_id is used as a tag on every message, to collectivize the chat documents into unique containers, with each chat_id shared between two users involved in a chat. Hence, chat_id for User_Profile is an array of ids(containing all chats made by that user), while chat_id for Message is a string, for just the chat_id to which the message exists on.

Comment and Post Entities:

These are together as they have most features to overlap, just that the comments could be nested and the posts needs to exist before the comment does. The comment entity has an intra-entity connection to itself as displayed in the ER diagram, so one can keep commenting to a parent comment infinitely.

Notification:

From most social media platforms, Notifications come in various forms but the most common social-media notifications and the ones within our scope here are

•Message Notification.

•Post/Comment Notification.

•Feed Notification.

During the lifecycle of a user's connection to the socket server i.e the socket_id of the user being active, all notifications written above are triggered based on the infrastructural demand on the ER Diagram above, and the the code currently available for the platform on the repo GitHub repo It's important to note that the notification fields contain post and comment fields because both can draw notifications. I would also add that adding a user's username with the '@' keyword in a post or comment can also cause notification to the specific user.

On cases where the user goes offline or loses connection to the socket server, all notifications listed above stops working, messages sent within this period are stored with a chat_id, if they were no prior chat document between both users, a chat_id is instigated by the other user creating the chat, and the messages stored accordingly. When the message recipient comes back online and gets access back to the socket server, the post/comment notification comes back active and all prior stored post and comment documents are retrieved as notifications, message notifications also follow similar script of recollecting messages within the nullity of the socket_id and sends as notification, but the feed notification is redundant until a threshold amount of new posts have been created by accounts the user follows.

SOFT ENTITIES:

The soft entities do not necessarily contain chunk of data saved on the database. It is just a piece of logic that enables the population of other data entities, this alludes to the reason why the entities have no fields with keys on it on the ER Diagram.

Followership: This is the logic box that dictates who you follow and who follows you, it goes on to tell how you get notifications as it's sandwiched into the code that performs the user feed, and also the algorithm responsible for rendering timely feed notifications and responses etc. It's pivotal to a smooth running of the app, but only called during run time.

Post_Feed: Same thing applies here,It's pivotal to a smooth running of the app, but only called during run time.

It randomizes your feed to only include that of those users you follow and refreshes your feed upon the introduction of newer posts or comments by people you follow too. These heightens user experience on the platform.

It's important to note that there are more entities that I could have added to best explain some concepts, but these where the basic ideas that were represented on the server.

INTER & INTRA ENTITY CONNECTIONS :

Comment-Comment Intra entity relationship

User-post inter entity relationship

Most software applications settle mostly for inter-entity connections and disregard intra-entity connections because of the implementational complexity that comes with it. Intra-entity connections are very vital to the easiness and interactive comfort of users on both reading from the software and writing to the software, it gives a easy navigation and provides contextual understanding to contents displayed on the application.

To properly explain this concepts the comment-comment intra-entity connection and user-post inter-entity connection is highlighted here. From the ER Diagram above, there is a cursor recurse from the comment entity back into the comment entity. This is so because, you can write a comment to a comment, and keep that cycle infinitely, that is the main reason why the comment entity has an array of parent comments and another array for child comments, every comment sent to another comment gets its Id sent to the child_comment array of the comment that precedes it and the Id of the comment that precedes it sent to parent_comment array of the succeeding comment, this helps in contextual exposition of the posts/comments so users can follow the message right to the very end with a wholesome view on other perspectives on the main post/comments as the case maybe.

In the case of the User-post inter-entity connection, there is no convolution of entity, it's strictly a one-many relationship. And this is the case most conventional software applications.

The concept of intra-entity connections and entity convolution is capitulated in other instances of software applications like in group Chats and forwarding messages.

User Security :

user authorization lifecycle.

The security of a user on the software application is non-negotiable and it's imperative it is fundamentally critical to the final design of the software application.

The situation here as it is in most software applications even makes it more fragile as there are two entries into the user's account, via the http server or ws server.

From the user authentication lifecycle diagram, after the API responsible for a user's signing in is triggered, it is further splitted and appropriate server(http or ws) where they work conjuctively, it is important to note there is an "and" operation (logic context) binding operations both on the ws server and http server, as when one fails to pull through, the API call is assumed dicey and a 404 error is triggered. Both parameters passed into the functions in the corresponding scripts by their servers needs to have been parsed first and infact valid.

The images below shows the middle-ware used for user authentication on the http server and that for the ws server for socket access respectively.

middleware for user authentication on http server

authentication for access into ws server

Other concepts of software design and architecture includes Model translation ( this would be covered alongside other coding concepts in the next sequel) and software maintenance, this is beyond the scope as it mostly comes in a phase for advancement of the application, this is to build a software application on the fly.