Live Blogpost Architecture Design

Architecture Design for Live Blog Post Abstract The following RFC demonstrates an architecture design for a real time blog post where users can sign up, login, post, comment and vote posts and comments. Parameters such as Scalability, Performance, Durability, Availability & Fault Tolerance were taken under consideration  Functional Requirements A user can: Sign up, Login, […]

Architecture Design for Live Blog Post

Abstract

The following RFC demonstrates an architecture design for a real time blog post where users can sign up, login, post, comment and vote posts and comments. Parameters such as Scalability, Performance, Durability, Availability & Fault Tolerance were taken under consideration 

Functional Requirements

A user can:

  1. Sign up, Login, Post, Vote, Comment
  2. A user should be able to create a new post that contains: 
  3. Title, Topic tags, Body
  4. A user should be able to comment on any existing post
  5. Comments are ordered chronologically as a flat list
  6. User can delete their own post or comment
  7. Logged In user can upvote/downvote an existing post/comment
  8. Comments should be presented as top most popular posts in the last 24 hrs on homepage

Non Functional Requirements

Scalability(millions of users daily)

  1. Viral posts world events- traffic spikes
  1. Performance (less than 5000ms response time 99p)
  1. Fault tolerance/high availability 99.9%
  1. Availability +partition tolerance (Ap over ConsistencyP)
  1. Durability (comments, votes posts should not disappear)

Identify Entities

Entities in system – users, posts, images, comments, votes

Mapping entities to URIs

Considerations

Other Cnsiderations
  • Batch Processing to update posts comments and votes in the last 24hrs
  • Ranking service will sort by popularity 
  • When user gets into the website we’ll call Ranking Service to see the latest and first most popular
  • If user wants the  next 20 then ranking we recall Ranking

APIs and Data Diagram - Functional Considerations

Diagram including Non-Functional Considerations

Addressing Issues

  • Scalability (millions of users daily) -Load Balancing, Database Sharding, APIGW
  • Performance (less than 5000ms response time 99p) – CDN, Caching, DB Indexing
  • Fault tolerance/high availability 99.9% – Database replication, Redundancy,Message Broker, 
  • Availability +Partition Tolerance (AP over CP) – choosing/configuring AP databases
  • Durability (comments, votes posts should not disappear) – Replication and Backups