Back to all posts

System Design for Beginners Day-1

bhupesh kumar•

Hey there, tech enthusiasts! Today I'm sharing comprehensive notes on system design fundamentals based on Arpit Bhavani's excellent teachings. This is perfect for beginners looking to understand how modern systems are built.

What is System Design?

System Design is the art of structuring systems by:

  • Deciding architecture
  • Deciding components
  • Deciding protocols

These decisions are always informed by user needs, and ultimately product development aims to "solve the problem" for users.

Why is System Design So Popular?

It's simple - every "tech" product is a "system" that has been designed. Companies are continuously building products and often look for design skills in candidates. Understanding system design is crucial for anyone working in tech.

Why Understanding System Design is Important

Here's why system design matters:

  • This is what people actually do at work
  • Everything is practical, not theoretical
  • You can see it from Day 1 of joining the company
  • Once you grow in your career, you will spend 80% of time doing this
  • System design is more rational for literally everyone in tech

Side Effects of System Design

Learning system design has some interesting side effects:

  • It will make everything less intimidating
  • You solve real problems, not something made up
  • It helps you break down problem statements
  • It rewires your brain to think in a structured way:
    • Considering all possible cases
    • Delivering a great user experience

What Will We Do When Designing a System?

  • Break down problem statement into smaller sub-problems
  • Decide on key components and responsibilities
  • Decide on boundaries of each component
  • Touch upon key challenges in scaling
  • Make our architecture fault-tolerant and scalable

How to Approach System Design?

System Design is extremely practical with a structured approach. Take baby steps:

  1. Understand the problem statement thoroughly - without this, we're bound to digress
  2. Break it down into components (essential step)
  3. Start with components you know are must-haves
  4. Consider common schemas like Auth, Notification, Feed, Gamification

Component Breakdown Example

For example, a "Feed" might have:

  • Generation
  • Aggregation
  • Customization

For each component, you should look into:

  1. Database and caching
  2. Scaling & fault tolerance
  3. Async processing (background work)
  4. Communication

Then repeat this process for each sub-component one by one.

How Do You Know You've Built a Good System?

Every system is "infinitely" buildable, and knowing when to stop evolution is important. Signs of a good system:

1. Your system breaks into components with clear boundaries

2. Every component has a clear set of responsibilities:

  • Feed Webscraper → Scrapes feed from HTTP
  • Feed Generation → Pulls data from multiple sources and puts them in DB
  • Feed Aggregation → Combines readable runs jobs by generation, joins w/ relevance, creates final consumable feed

3. For each component, you've figured out technical details:

  • Database and caching
  • Scaling & fault tolerance
  • Async processing (background)
  • Communication

4. Each component (in isolation) is:

  • Scalable → horizontally scalable, ready for large amounts of data
  • Fault tolerant → plan for recovery in case of failure, backup to a stable state
  • Available → component functions even when some components "fail"

This structured, detailed approach is how engineers build every single system.

Relational Databases

Databases are the most critical component of any system:

  • They make or break a system
  • Data is stored & represented in rows and columns

History of Relational Databases

Computing, Internet, Blockchain - everything "revolutionary" starts with Financial Applications. Computers first did "accounting" → ledgers → Rows & Columns. Databases were designed to support accounting needs.

Key Database Properties (ACID):

  1. Atomicity
  2. Consistency
  3. Isolation
  4. Durability

Atomicity

All statements within a transaction are treated as one unit. Example: Posting and incrementing total_posts happens together or not at all.

Consistency

Data will respect all constraints, no matter what (constraints, cascades, triggers). Example: Foreign key checks prevent deletion of parent if child exists.

Durability

When transaction commits, the changes endure/persist in the database.

Isolation

When multiple transactions are executing parallelly, the isolation level determines how much changes of one transaction are visible to others.

That's it for Day 1! Stay tuned for more system design concepts in the upcoming posts.