Learners Store

What Is Sharding in System Design?

As applications grow, data grows.
And when data grows too much, a single database can’t handle it efficiently.

This is where sharding comes in.

The Problem: One Database, Too Much Load

Imagine you have:

Millions of users
Billions of records
Thousands of requests per second

If all data lives in one database:

Queries become slow
CPU and memory max out
Scaling becomes expensive
One failure can bring everything down

👉 Vertical scaling (adding more RAM/CPU) has limits.

The Solution: Sharding

Sharding means:

Splitting a large database into smaller, independent pieces called shards and storing them across multiple servers.

Each shard holds only a portion of the data.

Real-World Analogy: Supermarket Billing Counters

Imagine a supermarket with:

One billing counter
Hundreds of customers

❌ Chaos.

Now introduce multiple counters:

Counter 1 → Customers A–D
Counter 2 → Customers E–J
Counter 3 → Customers K–Z

✔ Faster checkout
✔ Less load per counter
✔ Easy to add new counters

👉 That’s sharding.

How Sharding Works (Conceptually)

Instead of:

			
Single Database
└── All Users Data

We have:

			
Shard 1 → User IDs 1–1,000,000
Shard 2 → User IDs 1,000,001–2,000,000
Shard 3 → User IDs 2,000,001–3,000,000

Each shard is:

Independent
Handles only its own data
Can scale separately

Shard Key (Most Important Concept)

A shard key decides:

Which data goes to which shard

Common shard keys:

User ID
Customer ID
Region
Date

Example:

userId % 3

userId	Shard
1	Shard 1
2	Shard 2
3	Shard 3
4	Shard 1

Types of Sharding

1️⃣ Horizontal Sharding (Most Common)

Split rows across shards.

			
Users 1–1000 → Shard A
Users 1001–2000 → Shard B

✔ Used in most real systems

2️⃣ Vertical Sharding

Split columns.

			
User Profile → Shard A
User Orders → Shard B

✔ Useful when some data is accessed more frequently

3️⃣ Directory-Based Sharding

A lookup table tells:

“Which shard has this data?”

✔ Flexible
❌ Extra lookup cost

Real-World Use Cases

Company	How They Use Sharding
Facebook	User-based sharding
Instagram	Media & user shards
Amazon	Customer & order shards
Netflix	Regional sharding
Banking Apps	Account number shards

Challenges in Sharding

Sharding is powerful, but not free.

❌ Cross-Shard Queries

Joining data across shards is expensive

❌ Re-sharding

Changing shard strategy later is painful

❌ Uneven Load

Bad shard key = hotspot shard

Sharding vs Replication (Very Important)

Sharding	Replication
Splits data	Copies data
Improves write scalability	Improves read availability
Each shard has different data	All replicas have same data

👉 Large systems often use both together.

When Should You Use Sharding?

Use sharding when:

Data size is huge
Write traffic is high
Single DB can’t scale vertically
Latency is increasing

❌ Don’t shard too early — it adds complexity.

Simple Rule to Remember

Replication is for availability.
Sharding is for scalability.

Final Thoughts

Sharding is not a database feature —
it’s a system design decision.

Understanding sharding means:

You think about scale
You think about failure
You think like a backend engineer

Webpack Module Federation

Modern web applications are getting bigger, faster, and more complex.
Teams want to work independently, deploy features separately, and still make everything feel like one app.

That’s exactly where Webpack Module Federation comes in.

Let’s break it down step by step — no heavy jargon, I promise 😊

What Is Module Federation?

Module Federation is a Webpack feature that allows one JavaScript application to use code from another application at runtime.

👉 In simple words:

One app can load and use components, utilities, or modules from another app — without rebuilding the whole project.

Why Was Module Federation Introduced?

Before Module Federation, we had two main problems:

❌ Problem 1: Huge Bundles

All code was bundled together
Any small change required rebuilding the entire app

❌ Problem 2: Team Dependency

Multiple teams working in one repo caused conflicts
Deployment had to be coordinated

The Solution: Micro Frontends

Micro Frontends mean:

Break a big frontend into small independent apps
Each app can be built and deployed separately

But… how do these apps share code?

➡️ That’s where Module Federation shines.

Real-World Analogy

Think of Module Federation like a food court 🍔🍕🍜

Each stall (app) cooks its own food
You don’t cook everything in one kitchen
Customers (users) can order from multiple stalls in one place

Here:

Food stall = Independent app
Food = Components / logic
Food court = Host application

Key Concepts (Very Important)

1️⃣ Host Application

The main app
Loads modules from other apps

2️⃣ Remote Application

The app that exposes components
Other apps can consume them

3️⃣ Shared Dependencies

Common libraries like react, react-dom
Prevents loading the same library multiple times

Basic Example (Simple & Clear)

Scenario

App1 (Host) wants to use a Button from App2 (Remote)

🔹 App2 (Remote) – Expose a Component

			
// webpack.config.js (App2)
new ModuleFederationPlugin({
  name: "app2",
  filename: "remoteEntry.js",
  exposes: {
    "./Button": "./src/Button",
  },
});

		

👉 This means:

App2 is saying:
“Hey! I’m sharing my Button component.”

🔹 App1 (Host) – Consume the Remote Component

			
// webpack.config.js (App1)
new ModuleFederationPlugin({
  name: "app1",
  remotes: {
    app2: "app2@http://localhost:3002/remoteEntry.js",
  },
});

		

Now in your React code:

const RemoteButton = React.lazy(() => import("app2/Button"));

🎉 Boom! App1 is using App2’s component at runtime.

How Is This Different from NPM Packages?

NPM Packages	Module Federation
Installed at build time	Loaded at runtime
Needs rebuild for updates	No rebuild needed
Version conflicts possible	Shared dependencies
Static	Dynamic

Why Module Federation Is Powerful

✅ Independent deployments
✅ Faster builds
✅ Better team scalability
✅ True micro frontend architecture
✅ Runtime code sharing

Things to Be Careful About

Version mismatch of shared libraries
Network dependency (remote app must be available)
Slightly complex setup initially

💡 Tip: Always share React as a singleton.

When Should You Use Module Federation?

Use it when:

Your app is large
Multiple teams work independently
You want micro frontends
You want faster deployments

Avoid it if:

Small app
Single developer
Simple requirements

Final Thoughts

Webpack Module Federation is not magic — it’s a smart way to share code between apps without tight coupling.

Think of it as:

“Importing code from another app… but at runtime.”

Once you understand the concept, it feels natural and extremely powerful 💪

ReactDOM vs createRoot: Why Did React Change the Way We Render Apps?

If you’ve worked with React for a while, you probably remember this familiar line of code:

ReactDOM.render(<App />, document.getElementById("root"));

But starting from React 18, you’ll see a new approach:

			
import { createRoot } from "react-dom/client";
const root = createRoot(document.getElementById("root"));
root.render(<App />);

So the obvious question is:

👉 Why did React introduce createRoot and move away from ReactDOM.render?
Let’s break it down simply.

What is ReactDOM.render()?

ReactDOM.render() was the traditional way to render a React application into the DOM.

Example (Before React 18)

			
import ReactDOM from "react-dom";
import App from "./App";
ReactDOM.render(<App />, document.getElementById("root"));

How it worked

React rendered the entire UI synchronously
Updates happened immediately
Simple and easy, but limited for performance optimizations

What is createRoot()?

createRoot() is the new rendering API introduced in React 18.

Example (React 18 and above)

			
import { createRoot } from "react-dom/client";
import App from "./App";
const root = createRoot(document.getElementById("root"));
root.render(<App />);

How it works

Enables Concurrent Rendering
React can pause, resume, or abandon renders
Makes apps smoother and more responsive

Why Did React Introduce createRoot()?

The change was made to support modern React features.

Key reasons:

1. Concurrent Rendering

React can:

Work on multiple UI updates at the same time
Prioritize important updates (like user input)
Delay less important renders

This was not possible with ReactDOM.render().

2. Better Performance

With createRoot:

Large UI updates don’t block the main thread
The app feels more responsive
Smooth animations and transitions

3. Foundation for New Features

Many React 18 features only work with createRoot:

startTransition
Automatic batching
Streaming server-side rendering
Suspense improvements

What Happens If You Still Use ReactDOM.render()?

It still works, but:
Runs React in legacy mode
You won’t get React 18 performance benefits
You may see warnings in future versions

👉 React recommends migrating to createRoot.

Key Differences at a Glance

Feature	ReactDOM.render	createRoot
Introduced in	React 16	React 18
Rendering type	Synchronous	Concurrent
Performance	Good	Better
Supports new features	❌ No	✅ Yes
Future-proof	❌	✅

Should You Migrate?

✅ Yes, if:

You’re using React 18
You want better performance
You plan to use new React features

Migration is simple and usually requires changing just a few lines.

Final Thoughts

The shift from ReactDOM.render() to createRoot() is not just a syntax change —
it’s a major architectural upgrade in how React handles rendering.

Even though the old way still works, createRoot is the future of React.

Small change in code, big improvement in performance.

IndentationError: unexpected indent – Python

If you are learning Python, you may have seen this error:

IndentationError: unexpected indent

Unlike many other languages, indentation is part of Python syntax.
This error appears when Python finds spaces or tabs where it does not expect them.

Let’s understand this in the simplest way.

What Does This Error Mean?

Python found extra spaces or tabs at the beginning of a line where they are not allowed.

In Python, indentation must follow strict rules.
You cannot add random spaces like in Java or JavaScript.

❌ Example 1 – Extra Space at the Start

 print("Hello World")

Output

IndentationError: unexpected indent

✅ Fix

Remove the extra space:

print("Hello World")

❌ Example 2 – Indent Without a Block

			
name = "Alice"
    print(name)

Python does not expect indentation after a normal statement.

✅ Fix

			
name = "Alice"
print(name)

❌ Example 3 – Mixing Tabs and Spaces

			
def show():
	print("Hello")   # tab
    print("World")   # spaces

Mixing tabs + spaces confuses Python.

✅ Fix

Use only spaces (recommended):

			
def show():
    print("Hello")
    print("World")

❌ Example 4 – Wrong Indentation Level

			
if True:
print("Hi")

Code inside if must be indented.

✅ Fix

			
if True:
    print("Hi")

🧠 Why Python Is Strict About Indentation

In Python, indentation:

Defines code blocks
Replaces { } used in other languages
Makes code more readable

So Python treats wrong indentation as a syntax error.

✅ Simple Rules to Avoid This Error

Do not add spaces at the beginning randomly
Indent only after:
- if, for, while, def, class, try
Use either spaces OR tabs — never both
Recommended: use 4 spaces per indent

🛠 Best Practice in VS Code / Editors

Enable: Convert tabs to spaces
Set indentation to 4 spaces
Turn on: Show whitespace

🎯 Interview One-Liner

IndentationError: unexpected indent occurs when Python finds indentation at a place where it is not syntactically allowed.

✨ Final Thought

Python is basically saying:

“I didn’t ask for indentation here!”

Fix the spaces → error gone 🚀

SyntaxError: unterminated string literal – Python

If you are learning Python, one of the first errors you may see is:

SyntaxError: unterminated string literal

This error looks scary, but the reason is very simple:

Python found the start of a string but could not find where it ends.

Let’s understand this with easy examples.

❌ Why This Error Happens

In Python, strings must start and end with the same quote:

'single quotes'
"double quotes"

If Python cannot find the closing quote, it throws:

👉 SyntaxError: unterminated string literal

🧪 Example 1 – Missing Closing Quote

message = "Hello World

Output

SyntaxError: unterminated string literal

✅ Fix

message = "Hello World"

🧪 Example 2 – Mixed Quotes

text = "Python is fun'

Started with double quote "
Ended with single quote '

Python gets confused → error.

✅ Fix

Use the same quotes:

text = "Python is fun"

text = 'Python is fun'

🧪 Example 3 – Multiline String Mistake

			
info = "This is line one
This is line two"

Normal quotes cannot span multiple lines.

✅ Fix 1 – Use Triple Quotes

			
info = """This is line one
This is line two"""

✅ Fix 2 – Use newline character

info = "This is line one\nThis is line two"

🧪 Example 4 – Quote Inside String

msg = "It's a nice day"

This works because outer quotes are double quotes.

But this fails:

msg = 'It's a nice day'

✅ Fix

Use escape character:

msg = 'It\'s a nice day'

or switch quotes:

msg = "It's a nice day"

🧠 Simple Rules to Avoid This Error

Always close strings with the same quote you opened.
For multiline text → use triple quotes.
If your text contains quotes → use:
- opposite quotes, or
- escape character \.

✅ Quick Checklist

Mistake	Solution
Missing quote	Add closing quote
Mixed quotes	Use same quote type
Multiline string	Use `""" """`
Quote inside text	Escape or change quote

🎯 Interview One-Liner

“SyntaxError: unterminated string literal occurs when Python cannot find the closing quote of a string.”

✨ Final Thought

This error is not about logic —
it’s just Python saying:

“Hey, you started a string… but never told me where it ends!”

Fix the quotes → error gone 🚀