system design system design notes arpit

How to Approach System Design?

• SD is extremely practical and there is a structured way to tackle the situations.
• Take Baby Steps, no matter what!

1. Understand the problem statement

   • Without having a through understanding of the problem at hand. we would easily digress
   • Always ask the constrains and core features so we don't digress from it.

2. Break problem down into the components

   • Eg. Design Facebook - Auth, Notification, Feed - Components / Features
   • Do not create components for the sake of it
   • Create components which you know are must

3. Dissect each component

   • Eg. Feed might have generator, aggregator, webserver ![[Excalidraw/Drawing 2026-05-16 22.47.35.excalidraw.md#^frame=Mvz77Wnc|Feed Generator]]

4. For Each subcompoenent look into

   1. Database and Caching
   2. Scaling & Fault Tolerance
   3. Async Processing (Delegation)
   4. Communication (How each subcomponent will talk with each other like TCP, UDP, HTTP etc.)

5. Add More subcomponent if needed

   1. Understand the scope
   2. Decide how other component will talk to this new one
   3. Decide on 4 above factors for this new component ![[Excalidraw/Drawing 2026-05-16 22.47.35.excalidraw.md#^clippedframe=yByuS1he|Feed Generator Deepdive]]

How do you know that you have build a good system?

• Every system is infinitely buildable hence when to stop the evolution is important.

1. You broker system into components.
2. Each component has a clear set of responsibilities and they are mutually exclusive.
   1. In Feed the web-server -> servers over the HTTP.
   2. Feed Generator -> Pulls data from multiple services and puts into the db.
   3. Feed Aggregator -> combines candidate items fetched from generators, filter out redundant, ranks and create a final consumable feed
3. For each componenet you've slight technical details figured out
   1. Database and Caching
   2. Scaling and Fault tolerance
   3. Async Processing ( Delegation)
   4. Communication
4. Each component (in isolation) is
   1. Scalable - horizontally
   2. Fault tolerant - plan for recovery(to a stable state) in case of failure
   3. Available - Component functions even when some component fails

Relational Database

• History of Relational Databases
  • Everything revolutionary starts with financial applications.
    • Like computers first did accounting which uses ledgers which stored data as rows and columns
  • Databases were developed to support accounting.
  • Hence it's key properties were
    1. Data Consistency
    2. Data Durability
    3. Data integrity
    4. Constraints
    5. All in one place
• Because of these reasons, relation databases provides Transcations, Transactions makes our system correct no matter which operation we performe.
• Hence relation database provides ACID property
  • A - Atomicity
  • C - Consistency
  • I - Isolation
  • D - Durability

Atomicity

• All systems within a transaction takes effect or none
• Eg. Publish post and increase total post count
  • Start Transaction
    • Inset into posts
    • Update stats set total_posts = total_post + 1
  • Commit

Consistency

• Data will never go incorrect, no matter what
• Constraints, Cascades, triggers
• Eg.
  • Foreign key checks do not allow you to delete parent if child exists - Foreign Key constraints
  • If parent is deleted all childs should be deleted - Cascades
  • On update you want to update some column or call functions - Triggers

Durability

• When transaction commit, the changes outlives the outage.

Isolation

• When multiple transactions are executing parallely, the isolation level determines how much changes of one transaction are visible to other
• In most cases no need to change the isolation level, when we start the mysql server we defaults to the repeatable reads.
• There 4 standard isolation levels

1. Repeatable Reads
2. Read Committed
3. Read Uncommitted
4. Serializable

We pick the relational databases for relations and acid.