Day 34: Data Sharing: Horizontal Scaling: Intuition: When one database isn’t enough, split your data across many.

Welcome back, fellow architects and engineers!

Today, we peel back another layer of complexity in building hyperscale systems. We've talked about handling transient failures with Circuit Breakers (Day 20), but what happens when your single database simply can't keep up with the sheer volume of data or the relentless torrent of 100 million requests per second?

The answer isn't "buy a bigger server." At a certain point, vertical scaling (more RAM, faster CPU) hits a wall. The real game-changer for extreme scale is horizontal scaling, and when it comes to data, that means sharding.

The Unseen Bottleneck: Your Database

Imagine a bustling marketplace. Initially, one counter serves all customers. As the marketplace grows, you add more staff to that same counter. This is vertical scaling. Eventually, the counter itself becomes the bottleneck – too many people trying to access the same physical space.

Data sharding is like opening multiple, independent counters, each responsible for a specific subset of customers or products. Now, instead of one giant queue, you have several smaller, manageable queues, each with its own staff and resources. This dramatically increases the total throughput.

Core Concept: Data Sharding (Horizontal Scaling)

Data Sharding is a database partitioning technique that splits a large database into smaller, faster, more manageable parts called "data shards." Each shard is a completely independent database instance, running on its own server, with its own storage and processing resources.

Why is this critical for 100M RPS?

• Scalability: Distributes the load across multiple servers, allowing you to add more servers (shards) as your data or traffic grows. A single database instance can only scale so far.

• Performance: Queries hit smaller datasets, leading to faster response times. Contention is reduced.

• Availability: If one shard goes down, only a subset of your data or users is affected, not the entire system.

• Cost Efficiency: You can use commodity hardware for individual shards instead of expensive, monolithic super-servers.

Component Architecture: Sharding in the Ecosystem

How does this fit into our Spring Boot microservices landscape? Your application service doesn't directly know about all the shards. Instead, there's usually a Sharding Proxy or a Sharding Logic embedded within your service or a dedicated routing layer.

Think of it like this:

1. Client: Makes a request to your Inventory Service.

2. Inventory Service (with Sharding Logic): Receives the request. It extracts a crucial piece of information, the Sharding Key (e.g., tenantId, userId, productId).

3. Sharding Logic: Uses the Sharding Key and a predefined Sharding Strategy to determine which specific database shard holds the data for that key.

4. Database Shards: The request is routed to the correct shard, which processes it independently.

This means your application code needs to be "shard-aware" at the point of data access, or you need a smart proxy in front of your databases.

Control Flow, Data Flow, and State Changes

Let's trace a request to add a new inventory item for a tenant:

• Control Flow:

1. POST /tenants/{tenantId}/items arrives at InventoryController.

2. InventoryController calls InventoryService.

3. InventoryService extracts tenantId (our sharding key).

4. InventoryService invokes ShardingStrategy.getShard(tenantId).

5. ShardingStrategy returns the identifier of the target shard (e.g., shard-001).

6. InventoryService then directs the database operation to shard-001.

7. shard-001 performs the insert.

• Data Flow:

1. Item data (name, quantity, price) from client.

2. Flows through InventoryService.

3. Routed to shard-001.

4. Persisted in shard-001.

• State Changes:

• The overall system state changes from "item not present" to "item present in shard-001 for tenant X."

• Crucially, the sharding map (which tenant maps to which shard) is a critical piece of state that must be consistent and available.

Designing a Sharding Strategy for Multi-Tenant Inventory