---

Introduction

Imagine you are designing different enterprise applications.

Banking System

Requirements

• Money Transfer
• Account Balance
• Loan Processing
• Transactions

Every transaction must be 100% accurate.

---

Social Media Platform

Requirements

• User Posts
• Comments
• Likes
• Images
• Videos

Millions of users generate billions of records every day.

---

E-Commerce Platform

Requirements

• Product Catalog
• Orders
• Shopping Cart
• Reviews
• Recommendations

Some data requires strict consistency while other data prioritizes scalability.

Can one database solve all these problems?

No.

Choosing the right database is one of the most important decisions in System Design.

---

Learning Objectives

After completing this article, you will understand:

• What is SQL?
• What is NoSQL?
• SQL vs NoSQL
• ACID vs BASE
• Vertical vs Horizontal Scaling
• Data Modeling
• CAP Theorem
• Replication
• Sharding
• Real-Time Examples
• Best Practices

---

Database Categories

flowchart TD

DB[Database]

DB --> SQL[SQL Database]

DB --> NOSQL[NoSQL Database]

NOSQL --> DOC[Document]

NOSQL --> KV[Key Value]

NOSQL --> COL[Column Family]

NOSQL --> GRAPH[Graph]

---

What is SQL?

SQL stands for

Structured Query Language

SQL databases store data in tables.

Example

Customer

-------------------------

CustomerId

Name

Email

Phone

Popular SQL Databases

• PostgreSQL
• MySQL
• Oracle
• Microsoft SQL Server
• MariaDB
• Amazon Aurora

---

SQL Architecture

flowchart LR
    CLIENT["Client"]
    LB["Load Balancer"]
    API["Spring Boot API"]
    SQL[("PostgreSQL / MySQL")]

    CLIENT --> LB
    LB --> API
    API --> SQL

SQL databases enforce relationships using:

• Primary Keys
• Foreign Keys
• Constraints

---

SQL Example

Customers Table

CustomerId	Name
1001	John
1002	David

Orders Table

OrderId	CustomerId
501	1001
502	1002

Relationship

flowchart LR

Customer

-->

Orders

---

SQL Characteristics

• Fixed Schema
• Strong Consistency
• ACID Transactions
• Joins
• Relationships
• Structured Data

---

What is NoSQL?

NoSQL means

Not Only SQL

It stores data differently.

Examples

• JSON Documents
• Key Value
• Graph
• Wide Column

---

NoSQL Architecture

flowchart LR
    CLIENT["Client"]
    LB["Load Balancer"]
    API["Spring Boot API"]
    MONGO[("MongoDB Cluster")]

    CLIENT --> LB
    LB --> API
    API --> MONGO

No joins are required.

Documents contain nested data.

---

MongoDB Example

{
  "customerId":1001,
  "name":"John",
  "orders":[
      {
         "id":501,
         "amount":100
      }
  ]
}

Everything is stored together.

---

Types of NoSQL Databases

flowchart TD
    NOSQL["NoSQL Databases"]
    DOC["Document Database"]
    MONGO["MongoDB"]
    KV["Key-Value Database"]
    REDIS["Redis"]
    COL["Column-Family Database"]
    CASS["Cassandra"]
    GRAPH["Graph Database"]
    NEO["Neo4j"]

    NOSQL --> DOC
    DOC --> MONGO

    NOSQL --> KV
    KV --> REDIS

    NOSQL --> COL
    COL --> CASS

    NOSQL --> GRAPH
    GRAPH --> NEO

---

SQL vs NoSQL

Feature	SQL	NoSQL
Schema	Fixed	Flexible
Data Model	Tables	Documents / Key Value
Relationships	Strong	Limited
Transactions	ACID	BASE / Limited ACID
Joins	Yes	Usually No
Scalability	Vertical	Horizontal
Consistency	Strong	Eventual (depends on DB)
Best For	Banking	Social Media

---

ACID Properties

SQL databases provide ACID.

A

Atomicity

C

Consistency

I

Isolation

D

Durability

Perfect for

• Banking
• Payments
• Trading
• Healthcare

---

Banking Example

Money Transfer

flowchart LR
    A["Account A"]
    T["Transfer Service"]
    L["Ledger"]
    B["Account B"]

    A --> T
    T --> L
    L --> B

If credit fails,

debit must roll back.

SQL handles this automatically.

---

BASE Model

Many NoSQL systems emphasize:

Basically Available

↓

Soft State

↓

Eventually Consistent

Better for large-scale distributed systems.

---

Social Media Example

User posts a photo.

Some users may see it immediately,

others a few milliseconds later.

This temporary inconsistency is acceptable.

---

Vertical Scaling

SQL databases often scale vertically.

flowchart TD
    DB["Database"]
    CPU["More CPU"]
    MEM["More Memory"]
    SERVER["Larger Server"]

    DB --> CPU
    CPU --> MEM
    MEM --> SERVER

Limit

One machine eventually reaches its maximum capacity.

---

Horizontal Scaling

NoSQL databases commonly scale horizontally.

flowchart TD
    CLIENT["Client"]
    ROUTER["Shard Router"]

    SHARD1["Shard 1"]
    SHARD2["Shard 2"]
    SHARD3["Shard 3"]
    SHARD4["Shard 4"]

    CLIENT --> ROUTER

    ROUTER --> SHARD1
    ROUTER --> SHARD2
    ROUTER --> SHARD3
    ROUTER --> SHARD4

Simply add more servers.

---

Sharding

flowchart TD
    CLIENT["Application"]
    ROUTER["Shard Router"]

    DB1["Shard 1"]
    DB2["Shard 2"]
    DB3["Shard 3"]

    CLIENT --> ROUTER
    ROUTER --> DB1
    ROUTER --> DB2
    ROUTER --> DB3

Data is distributed across multiple nodes.

Used by

• MongoDB
• Cassandra
• DynamoDB

---

Replication

flowchart LR
    APP["Application"]
    PRIMARY["Primary Database"]

    REPLICA1["Read Replica 1"]
    REPLICA2["Read Replica 2"]
    REPLICA3["Read Replica 3"]

    APP --> PRIMARY

    PRIMARY --> REPLICA1
    PRIMARY --> REPLICA2
    PRIMARY --> REPLICA3

Benefits

• High Availability
• Disaster Recovery
• Read Scaling

---

CAP Theorem

Distributed databases balance:

Consistency

Availability

Partition Tolerance

Only two can be fully prioritized during a network partition.

---

SQL Use Cases

Use SQL for

• Banking
• Payments
• HR Systems
• ERP
• Accounting
• Airline Booking
• Insurance

---

NoSQL Use Cases

Use NoSQL for

• Social Media
• Product Catalog
• Chat Applications
• IoT
• Gaming
• Recommendation Engines
• Real-Time Analytics

---

Amazon Example

Amazon uses multiple databases.

flowchart LR
    CLIENT["Customer"]

    API["API Gateway"]

    ORDER["Order Service"]
    PRODUCT["Product Service"]
    CACHE["Cache Layer"]

    AURORA[("Aurora")]
    DYNAMO[("DynamoDB")]
    REDIS[("Redis")]

    CLIENT --> API

    API --> ORDER
    API --> PRODUCT

    ORDER --> AURORA
    PRODUCT --> DYNAMO

    ORDER --> CACHE
    PRODUCT --> CACHE

    CACHE --> REDIS

One database does not solve every problem.

---

Netflix Example

Netflix combines

• Cassandra
• MySQL
• Redis
• Elasticsearch

Each service uses the database that best fits its workload.

---

Uber Example

Uber uses

• MySQL
• Cassandra
• Redis

Driver locations,

trip history,

pricing,

and user profiles use different storage technologies.

---

Banking Architecture

flowchart LR
    CUSTOMER["Customer"]
    APP["Spring Boot API"]
    CORE["Core Banking Service"]
    ORACLE[("Oracle Database")]
    LEDGER["General Ledger"]

    CUSTOMER --> APP
    APP --> CORE
    CORE --> ORACLE
    CORE --> LEDGER

Strong consistency is essential.

---

E-Commerce Architecture

flowchart LR
    CUSTOMER["Customer"]

    API["Spring Boot API"]

    ORDER["Aurora"]
    CACHE["Redis"]
    CATALOG["DynamoDB"]
    SEARCH["OpenSearch"]

    CUSTOMER --> API

    API --> ORDER
    API --> CACHE
    API --> CATALOG
    API --> SEARCH

Each component serves a specialized purpose.

---

Spring Boot Integration

flowchart LR
    REACT["React UI"]
    API["Spring Boot REST API"]

    JPA["Spring Data JPA"]
    CACHE["Redis Cache"]
    NOSQL["MongoDB"]
    SQL["PostgreSQL"]

    REACT --> API

    API --> JPA
    JPA --> SQL

    API --> CACHE
    API --> NOSQL

Spring Boot can integrate with multiple databases within the same application.

---

Advantages of SQL

• Strong consistency
• ACID transactions
• Powerful joins
• Mature ecosystem
• Excellent reporting
• Standardized SQL language

---

Advantages of NoSQL

• Flexible schema
• Horizontal scalability
• High throughput
• Easy handling of unstructured data
• Better for distributed systems

---

Disadvantages of SQL

• Vertical scaling limitations
• Schema changes can be expensive
• Complex joins at very large scale
• More difficult horizontal partitioning

---

Disadvantages of NoSQL

• Limited joins
• Eventual consistency in many systems
• Data duplication
• Different query languages
• Not ideal for every transactional workload

---

Monitoring

Monitor

• Query Latency
• Slow Queries
• Connection Pool
• Replication Lag
• Cache Hit Ratio
• Storage Usage
• CPU
• Memory
• Lock Contention

Tools

• Datadog
• Prometheus
• Grafana
• CloudWatch

---

Common Mistakes

❌ Using MongoDB for financial ledgers

❌ Using Oracle for billions of rapidly changing IoT events without considering scalability

❌ Selecting one database for every microservice

❌ Ignoring future scaling requirements

❌ Poor indexing

❌ No replication strategy

---

Best Practices

• Choose the database based on business requirements.
• Use SQL for transactional systems.
• Use NoSQL for high-scale distributed workloads.
• Combine SQL and NoSQL when appropriate (Polyglot Persistence).
• Design indexes carefully.
• Enable replication for high availability.
• Use sharding for very large datasets.
• Monitor database performance continuously.

---

Common Interview Questions

What is the difference between SQL and NoSQL?

SQL databases use structured tables with fixed schemas and strong ACID guarantees, while NoSQL databases use flexible data models such as documents, key-value pairs, columns, or graphs and are designed for scalability and distributed workloads.

---

When should SQL be used?

SQL is best for applications requiring strong consistency and transactions, such as banking, payment processing, ERP, healthcare, and accounting systems.

---

When should NoSQL be used?

NoSQL is well suited for applications with massive scale, flexible schemas, and high write throughput, such as social media, IoT, gaming, recommendation engines, and product catalogs.

---

Can SQL and NoSQL be used together?

Yes. Modern architectures often use Polyglot Persistence, where each microservice chooses the most suitable database. For example, an application might use PostgreSQL for orders, Redis for caching, MongoDB for product catalogs, and OpenSearch for search.

---

Which is better: SQL or NoSQL?

Neither is universally better. The correct choice depends on the application's consistency requirements, scalability needs, data model, and access patterns.

---

Summary

SQL and NoSQL databases are designed for different types of workloads. SQL excels in transactional systems requiring strong consistency, while NoSQL shines in highly scalable, distributed applications with flexible data models.

In this article, we covered:

• SQL fundamentals
• NoSQL fundamentals
• ACID vs BASE
• Vertical vs Horizontal Scaling
• Sharding
• Replication
• CAP Theorem
• Banking, Amazon, Netflix, and Uber examples
• Spring Boot integration
• Monitoring
• Best practices

Modern enterprise architectures rarely rely on a single database technology. Instead, they adopt Polyglot Persistence, selecting the right database for each service based on business requirements, performance goals, and scalability needs.

---