Horizontal vs vertical partitioning in HLD - Design Approaches Compared

Design: Database Partitioning Strategies

Design and compare horizontal and vertical partitioning strategies for a relational database system. Out of scope: physical hardware setup, specific cloud provider configurations.

Functional Requirements

FR1: Store large datasets efficiently

FR2: Improve query performance by reducing data scanned

FR3: Support scalable data growth

FR4: Maintain data consistency and integrity

Non-Functional Requirements

NFR1: Handle up to 100 million records

NFR2: Query latency p99 under 200ms

NFR3: Availability target 99.9%

NFR4: Support read and write operations with minimal downtime

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Database tables and schemas

Partitioning keys or criteria

Query routing and optimization

Data replication and consistency mechanisms

Design Patterns

Horizontal partitioning (sharding)

Vertical partitioning (column-based splitting)

Composite partitioning (combining horizontal and vertical)

Caching layers to reduce database load

Reference Architecture

Client
  |
  v
Query Router
  |
  +---------------------+
  |                     |
Horizontal Partitions  Vertical Partitions
(Table shards by rows) (Tables split by columns)
  |                     |
Database Nodes         Database Nodes

Components

Query Router

Custom middleware or database proxy

Direct queries to appropriate partitions based on partitioning strategy

Horizontal Partitions

Relational database shards

Split data by rows using a partition key (e.g., user ID ranges) to distribute load

Vertical Partitions

Relational database tables

Split data by columns grouping related columns together to optimize column-specific queries

Database Nodes

SQL databases (e.g., PostgreSQL, MySQL)

Store partitioned data and handle queries

Request Flow

1. Client sends query to Query Router

2. Query Router analyzes query type and routing rules

3. For horizontal partitioning, router directs query to shard(s) containing relevant rows

4. For vertical partitioning, router directs query to tables containing requested columns

5. Database nodes execute query on their partitioned data

6. Results are aggregated if needed and returned to client

Database Schema

Entities: - User (id, name, email, address, phone, preferences) Horizontal Partitioning: - User table split into multiple shards by id ranges (e.g., User_1_1000000, User_1000001_2000000) Vertical Partitioning: - User_Basic (id, name, email) - User_Contact (id, address, phone) - User_Preferences (id, preferences) Relationships: - Each vertical partition shares the primary key 'id' to join data when needed

Scaling Discussion

Bottlenecks

Query Router becomes a single point of failure or bottleneck

Uneven data distribution causing hotspots in horizontal partitions

Complex joins across vertical partitions increasing query latency

Data consistency challenges when updating multiple partitions

Solutions

Implement load balancing and failover for Query Router

Use consistent hashing or range partitioning with monitoring to balance shards

Denormalize data or use caching to reduce cross-partition joins

Use distributed transactions or eventual consistency models with conflict resolution

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying data access patterns, 20 minutes designing partitioning strategies with diagrams, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing key points.

Explain difference between horizontal and vertical partitioning clearly

Discuss when to use each based on query patterns and data shape

Highlight impact on performance, scalability, and complexity

Mention real-world examples like sharding in large web apps

Address consistency and operational challenges