home system design system-design-interview-preparation

Interview Q&A System Design 17 questions

System design Interview Preparation

A. System Design Fundamentals System Design is the process of designing the architecture, components, databases, APIs, communication mechanisms, and infrastructure required to build a scalable, reliable, secure, and…

Start practicing

By javainterviewprep July 27, 2026 78 min read

A. System Design Fundamentals

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Capacity estimation helps determine the infrastructure required to support the expected workload.

Typical estimates include:

Daily Active Users (DAU)
Peak Concurrent Users
Requests Per Second (RPS)
Storage
Network Bandwidth
Cache Size

Example:

Suppose:

10 million daily users
Each user sends 10 requests/day

Total Requests:

10M × 10 = 100M requests/day

Average RPS:

100M / 86400 ≈ 1157 RPS

Peak traffic is often assumed to be 3–5 times the average, so the system should be designed for approximately 3500–6000 RPS.

Interview Tip

Always mention that systems are designed for peak load, not average load.

Storage estimation is based on:

Number of users
Data generated per user
Retention period
Replication factor

Example:

10 million users

Each uploads:

2 MB/day

Daily Storage:

10M × 2 MB = 20 TB/day

One Year:

20 × 365 = 7300 TB
≈ 7.3 PB

With 3 replicas:

7.3 × 3 = 21.9 PB

Interview Tip

Always consider:

Replication
Metadata
Future growth
Backups

Throughput is the amount of work a system can process in a given period of time.

It is commonly measured as:

Requests per second (RPS)
Transactions per second (TPS)
Messages per second

Example:

If a payment system processes:

5,000 requests every second

Its throughput is:

5,000 RPS

Higher throughput means the system can handle more workload.

Interview Tip

Think of throughput as capacity.

Latency is the time taken for a request to travel through the system and receive a response.

Usually measured in:

Milliseconds (ms)

Example:

User clicks Login

↓

Server processes request

↓

Returns response in 120 ms

Latency = 120 ms

Lower latency provides a better user experience.

Interview Tip

Throughput = How much

Latency = How fast

Performance	Scalability
Measures how fast the system responds.	Measures how well the system handles increased load.
Focuses on speed.	Focuses on growth.
Improved by optimization.	Improved by adding resources or redesigning the system.

Example:

A website responds in 100 ms.

Its performance is good.

If it crashes when users increase from 10,000 to 1 million, scalability is poor.

Interview Tip

Performance is about speed; scalability is about handling growth.

Horizontal Scaling	Vertical Scaling
Add more servers.	Increase CPU/RAM of one server.
Better fault tolerance.	Single point of failure.
Nearly unlimited scaling.	Limited by hardware capacity.
Preferred in cloud environments.	Easier to implement initially.

Example:

Vertical:

8 GB RAM → 64 GB RAM

Horizontal:

1 Server → 10 Servers

Interview Tip

Modern distributed systems usually prefer horizontal scaling because it offers better scalability and resilience.

High Availability	Fault Tolerance
Minimizes downtime.	Continues operating even during failures.
Some brief interruption may occur.	No service interruption is expected.
Uses redundancy and failover.	Uses redundant components running simultaneously.

Example:

High Availability: A standby database takes over within a few seconds.
Fault Tolerance: Multiple systems run in parallel so a failure does not interrupt service.

Interview Tip

High Availability aims for minimal downtime, while Fault Tolerance aims for continuous operation despite failures.

Strong Consistency	Eventual Consistency
Reads always return the latest committed data.	Reads may temporarily return stale data.
Higher consistency guarantees.	Better availability and scalability.
Higher latency.	Lower latency.
Suitable for banking and payments.	Suitable for social media and DNS.

Interview Tip

Choose Strong Consistency when correctness is critical. Choose Eventual Consistency when availability and scalability are more important.

B. Load Balancing

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Hardware Load Balancer	Software Load Balancer
Dedicated physical appliance	Runs as software on servers or cloud
Expensive	Cost-effective
High performance	Easily scalable
Difficult to upgrade	Easy to configure and update
Used in traditional data centers	Common in cloud and microservices

Examples:

Hardware:

F5 BIG-IP
Citrix ADC

Software:

Nginx
HAProxy
Envoy
Traefik

Interview Tip: Modern cloud-native applications mostly use software load balancers.

Layer 4 (Transport Layer)	Layer 7 (Application Layer)
Operates on TCP/UDP	Operates on HTTP/HTTPS
Routes based on IP and Port	Routes based on URL, Hostname, Headers, Cookies
Faster	More intelligent routing
Cannot inspect HTTP content	Can inspect request content
Lower latency	More flexible

Example:

Layer 4:

Routes traffic based on IP:Port.

Layer 7:

/api/* → API Server
/images/* → Image Server

Interview Tip: Layer 4 is faster, while Layer 7 provides smarter routing capabilities.

Round Robin distributes incoming requests sequentially across all available servers.

Example:

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A

Advantages:

Simple
Fair distribution
Easy to implement

Limitations:

Assumes all servers have equal capacity.
Does not consider current server load.

Weighted Round Robin assigns a weight to each server based on its capacity.

Servers with higher capacity receive more requests.

Example:

Server A (Weight 3)
Server B (Weight 1)

Distribution:

A A A B
A A A B

Advantages:

Better utilization
Supports servers with different hardware configurations

Used when some servers are more powerful than others.

Least Connection sends new requests to the server with the fewest active connections.

Example:

Server A → 150 connections
Server B → 40 connections
Server C → 80 connections

New request → Server B

Advantages:

Suitable for long-running requests
Better load distribution than Round Robin

Commonly used for:

Chat applications
Video streaming
WebSocket services

Least Response Time routes traffic to the server responding the fastest while also considering the number of active connections.

It continuously monitors server response times.

Example:

Server A → 20 ms
Server B → 50 ms
Server C → 12 ms

New request → Server C

Advantages:

Better user experience
Adapts to server performance dynamically

IP Hashing uses the client’s IP address to determine which backend server should handle the request.

The same client IP is consistently routed to the same server.

Example:

User A → Server 1
User B → Server 3
User A → Server 1

Advantages:

Session consistency
Simple implementation

Limitations:

Uneven traffic distribution if many users share the same IP.

Health Checks are periodic tests performed by the Load Balancer to verify whether backend servers are healthy and capable of serving requests.

Types:

Active Health Checks
Load Balancer periodically sends requests (HTTP/TCP).
Passive Health Checks
Detect failures based on real client traffic.

Example:

GET /health

Response:
200 OK → Healthy
500 Error → Unhealthy

Unhealthy servers are automatically removed from traffic until they recover.

Active-Active	Active-Passive
All servers handle traffic	Only one server handles traffic
Better resource utilization	Standby server remains idle
Higher throughput	Simpler architecture
Faster failover	Slight delay during failover

Example:

Active-Active:

LB
↓
Server A
Server B
Server C

Active-Passive:

Primary Server → Active
Secondary Server → Standby

Interview Tip: Active-Active is preferred in cloud-native architectures for better scalability and availability.

Nginx	HAProxy
Web server + Reverse Proxy + Load Balancer	Dedicated Load Balancer
Supports static content serving	Does not serve static files
Good for web applications	Optimized for high-performance load balancing
Easy configuration	Advanced traffic management
Supports Layer 7	Supports Layer 4 and Layer 7

Use Nginx when:

Serving web content
Reverse proxy
SSL termination

Use HAProxy when:

High traffic
Enterprise load balancing
Low latency routing

ELB (Classic)	ALB	NLB
Legacy load balancer	Application Load Balancer	Network Load Balancer
Layer 4 & Layer 7	Layer 7	Layer 4
Basic routing	Content-based routing	Ultra-low latency
Suitable for older applications	Microservices and containers	High-performance TCP/UDP workloads

ALB Features:

Path-based routing
Host-based routing
HTTP/HTTPS support
WebSocket support

NLB Features:

TCP/UDP support
Millions of requests per second
Static IP support
Very low latency

Interview Tip: For modern Spring Boot microservices, Application Load Balancer (ALB) is usually the preferred choice.

A Load Balancer continuously performs health checks on backend servers to determine whether they are healthy.

Common health check methods include:

HTTP/HTTPS endpoint checks (e.g., /health)
TCP connection checks
ICMP (Ping) checks (less common)
Passive monitoring of failed client requests

Typical process:

The Load Balancer sends periodic health check requests.
If the server responds successfully (e.g., HTTP 200), it remains in the pool.
If the server repeatedly fails (e.g., timeout or HTTP 500), it is marked unhealthy.
The Load Balancer stops routing traffic to that server.
Once the server starts passing health checks again, it is automatically added back to the pool.

Example:

LB → GET /health

Server A → 200 OK ✅
Server B → Timeout ❌

Traffic is routed only to Server A until Server B recovers.

Interview Tip: In Spring Boot applications, health checks are commonly implemented using Spring Boot Actuator (/actuator/health), which integrates seamlessly with load balancers and orchestration platforms like Kubernetes.

C. Caching

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Redis	Memcached
Supports multiple data structures (String, Hash, List, Set, Sorted Set, Stream)	Supports only Key-Value pairs
Supports Persistence (RDB, AOF)	No Persistence
Supports Replication and Clustering	Limited clustering support
Supports Pub/Sub and Transactions	Not Supported
More feature-rich	Lightweight and simple
Slightly higher memory usage	Lower memory usage

Use Redis when:

Distributed caching
Session storage
Rate limiting
Leaderboards
Real-time applications
Persistence is required

Use Memcached when:

Simple key-value caching
Extremely fast temporary cache
No persistence is required

Interview Tip: Redis is the preferred caching solution in modern microservices.

Local Cache	Distributed Cache
Stored inside application memory	Stored on dedicated cache servers
Very fast (no network call)	Slight network latency
Not shared between application instances	Shared by all application instances
Suitable for single server applications	Suitable for distributed systems
Lost when application restarts	Survives application restarts (if persistence enabled)

Examples

Local Cache:

Caffeine
Guava Cache

Distributed Cache:

Redis
Memcached

Interview Tip: Microservices typically use Distributed Cache because multiple service instances need access to the same cached data.

Cache Aside (Lazy Loading) is the most commonly used caching strategy.

Workflow

Application checks the cache.
If data exists (Cache Hit), return it.
If data is missing (Cache Miss), fetch it from the database.
Store the result in the cache.
Return the data to the client.

Client
   ↓
Application
   ↓
Cache
   ↓
Miss
   ↓
Database
   ↓
Update Cache
   ↓
Return Data

Advantages

Easy to implement.
Cache stores only frequently used data.
Reduces unnecessary memory usage.

Interview Tip: This is the most widely used caching pattern in Spring Boot applications.

In Read Through Cache, the application always requests data from the cache.

If the data is missing, the cache itself fetches the data from the database, stores it, and returns it.

Application
      ↓
Cache
      ↓
Database

Advantages

Simpler application code.
Cache automatically manages data loading.

Disadvantages

Cache implementation becomes more complex.

In Write Through Cache, every write operation updates both the cache and the database synchronously.

Application
      ↓
Cache
      ↓
Database

Advantages

Cache always contains the latest data.
Strong consistency between cache and database.

Disadvantages

Higher write latency because both cache and database must be updated.

Use Cases

Banking
Inventory Management
User Profiles

Write Behind (Write Back) Cache writes data to the cache immediately and updates the database asynchronously after a short delay.

Application
      ↓
Cache
      ↓
Async Write
      ↓
Database

Advantages

Very fast write performance.
Reduces database load.
Suitable for write-heavy applications.

Disadvantages

Risk of data loss if the cache crashes before writing to the database.

Use Cases

Logging systems
Analytics
IoT applications

LRU removes the data that has not been accessed for the longest period.

Example:

Cache Capacity = 3

A B C

Access A

A C B

Insert D

Remove B

Advantages

Works well when recently used data is likely to be accessed again.

Use Cases

Web applications
Product catalogs
User sessions

LFU removes the item that has been accessed the fewest number of times.

Example:

A → 50 accesses

B → 5 accesses

C → 100 accesses

Insert D

Remove B

Advantages

Keeps frequently accessed data in memory.

Use Cases

Recommendation systems
News portals
Search engines

FIFO removes the oldest cached item regardless of how frequently or recently it has been accessed.

Example:

Insert:

A B C

Insert D

Remove A

Advantages

Simple implementation.
Low overhead.

Disadvantages

Frequently accessed data may be removed unnecessarily.

Cache Expiration defines how long cached data remains valid before it is automatically removed.

TTL stands for Time To Live.

Example:

User Profile

TTL = 30 minutes

After 30 minutes

Cache Entry Expires

Advantages

Prevents stale data.
Frees cache memory automatically.

Cache Invalidation

Cache Invalidation is the process of removing or updating cached data when the original data changes.

Methods:

TTL-based expiration
Manual deletion
Event-driven invalidation
Version-based invalidation

Example:

Product Price Updated

↓

Delete Cache

↓

Next Request

↓

Fetch Updated Price

Interview Tip: There are only two hard things in computer science: Cache Invalidation and Naming Things.

A Cache Stampede occurs when many requests simultaneously try to access data after a cache entry expires.

All requests miss the cache and hit the database at the same time.

1000 Requests

↓

Cache Expired

↓

1000 Database Queries

↓

Database Overloaded

Solutions

Distributed locking
Cache warming
Randomized TTL
Background refresh

Cache Penetration occurs when repeated requests are made for data that does not exist.

Since the data isn’t found in either the cache or the database, every request reaches the database.

Example:

Invalid Product ID

↓

Cache Miss

↓

Database

↓

Not Found

↓

Repeated Again

Solutions

Cache null values
Bloom Filters
Input validation

Cache Breakdown

Cache Breakdown (also called Hot Key Expiration) occurs when a highly popular cache entry expires.

Thousands of requests for that single key immediately hit the database.

Example:

Popular Product

↓

Cache Expires

↓

Thousands of Requests

↓

Database Overloaded

Solutions

Never expire hot keys
Distributed locking
Background cache refresh
Logical expiration

Hot Keys in Redis

A Hot Key is a cache key that receives an exceptionally high number of requests compared to other keys.

Example:

Flash Sale Product

↓

Millions of Requests

↓

Same Redis Key

Problems:

Redis CPU spikes
Uneven load distribution
Increased latency

Solutions:

Replicate hot data
Local caching
Key sharding
CDN
Load balancing

Redis is primarily an in-memory database, but it supports persistence to avoid data loss.

Two persistence mechanisms are available:

RDB (Redis Database Backup)

Creates snapshots at configured intervals.
Faster recovery.
Lower runtime overhead.
Possible data loss between snapshots.

AOF (Append Only File)

Logs every write operation.
Better durability.
Minimal data loss.
Larger file size and slightly slower performance.

RDB	AOF
Snapshot-based	Log-based
Faster recovery	Better durability
Lower disk usage	Higher disk usage
Possible data loss	Minimal data loss

Interview Tip: Many production systems enable both RDB and AOF to balance recovery speed and durability.

Redis Replication copies data from a Primary (Master) node to one or more Replica (Slave) nodes.

Primary Redis

      ↓

Replica 1

Replica 2

Replica 3

Advantages

High Availability
Read Scaling
Backup
Disaster Recovery

Writes are performed on the Primary, while read requests can be distributed across Replicas.

Redis Cluster distributes data across multiple Redis nodes using sharding.

Each node stores only a portion of the data instead of the entire dataset.

Cluster

Node 1

Node 2

Node 3

↓

Data Split Across Nodes

Advantages

Horizontal Scalability
High Availability
Automatic Failover
Handles very large datasets

Redis Cluster uses 16,384 hash slots to distribute keys evenly across nodes.

Interview Tip: For enterprise-scale applications, Redis Cluster is preferred over a single Redis instance because it provides both scalability and fault tolerance.

D. Database Design

SQL vs NoSQL

SQL	NoSQL
Relational Database	Non-Relational Database
Structured schema	Flexible schema
Tables with rows and columns	Documents, Key-Value, Graph, Column-family
Supports ACID	Usually follows BASE
Vertical scaling	Horizontal scaling
Best for complex queries and joins	Best for large-scale distributed systems

Examples

SQL:

MySQL
PostgreSQL
Oracle
SQL Server

NoSQL:

MongoDB
Cassandra
Redis
DynamoDB

Interview Tip: Use SQL when consistency is critical and NoSQL when scalability and flexibility are priorities.

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Normalization is the process of organizing data to reduce redundancy and improve data integrity.

Common Normal Forms:

1NF (Eliminate repeating groups)
2NF (Remove partial dependency)
3NF (Remove transitive dependency)
BCNF (Stronger version of 3NF)

Advantages

Reduces duplicate data.
Improves consistency.
Saves storage space.
Simplifies updates.

Interview Tip: OLTP systems usually use normalized databases.

Denormalization

Denormalization is the process of combining tables to reduce joins and improve read performance.

Advantages

Faster read queries.
Fewer joins.
Better reporting performance.

Disadvantages

Data redundancy.
Higher storage usage.
More complex updates.

Use Cases

Reporting Systems
Data Warehouses
Analytics Platforms

Interview Tip: Normalize for write-heavy systems and denormalize for read-heavy systems.

Primary Key

A Primary Key uniquely identifies each row in a table.

Properties:

Unique
Cannot be NULL
One Primary Key per table

Example

Employee
------------
Employee_ID (PK)
Name
Salary

Interview Tip: Every table should have a Primary Key.

Composite Key

A Composite Key consists of two or more columns that together uniquely identify a record.

Example

Student_ID + Course_ID

Neither column alone is unique, but together they uniquely identify an enrollment.

Use Cases

Order Items
Student Enrollments
Many-to-Many relationships

Foreign Key

A Foreign Key establishes a relationship between two tables.

It references the Primary Key of another table.

Example

Customer
------------
Customer_ID (PK)

Orders
------------
Order_ID (PK)
Customer_ID (FK)

Advantages

Maintains referential integrity.
Prevents invalid references.
Ensures data consistency.

Indexing

An Index is a data structure that improves the speed of data retrieval.

Without an index:

Full Table Scan

With an index:

Direct lookup

Advantages

Faster SELECT queries.
Faster sorting.
Faster searching.

Disadvantages

Increased storage.
Slower INSERT, UPDATE, DELETE operations.

Interview Tip: Index frequently searched columns but avoid excessive indexing.

Clustered Index

A Clustered Index determines the physical order of data in the table.

Properties:

Only one Clustered Index per table.
Data is physically sorted according to the index.

Advantages

Very fast range queries.
Efficient sequential access.

Example

Employee_ID
1
2
3
4
5

A Non-Clustered Index stores a separate index structure that points to the actual table rows.

Properties:

Multiple Non-Clustered Indexes are allowed.
Data is stored separately from the table.

Advantages

Faster searches on non-primary columns.
Multiple indexes can exist on different columns.

Covering Index

A Covering Index contains all the columns required by a query.

Since all required data exists in the index, the database does not need to access the table.

Example

Query:

SELECT Name, Salary
FROM Employee
WHERE Employee_ID = 10;

If the index includes Employee_ID, Name, and Salary, the query is satisfied entirely from the index.

Advantages

Faster query execution.
Reduced disk I/O.

Query Optimization

Query Optimization is the process of improving SQL queries to reduce execution time and resource usage.

Common techniques:

Create appropriate indexes.
Avoid SELECT *.
Use WHERE clauses effectively.
Optimize joins.
Use EXPLAIN plans.
Avoid unnecessary subqueries.
Retrieve only required columns.

Interview Tip: Slow queries are often caused by missing indexes or poor query design.

Database Locking

Database Locking prevents multiple transactions from modifying the same data simultaneously.

Types:

Shared Lock (Read)
Exclusive Lock (Write)

Advantages

Prevents data corruption.
Maintains consistency.

Disadvantages

Can reduce concurrency.
May lead to deadlocks.

Optimistic Locking

Optimistic Locking assumes conflicts are rare.

Instead of locking rows, it uses a version number or timestamp to detect concurrent updates.

Workflow:

Pessimistic Locking locks the row before updating it, preventing other transactions from modifying the same data.

Advantages

Prevents concurrent update conflicts.
Ensures strict consistency.

Disadvantages

Lower concurrency.
Longer wait times.
Possibility of deadlocks.

Use Cases

Banking
Payment Processing
Stock Trading

Deadlocks

A Deadlock occurs when two or more transactions wait indefinitely for each other to release locks.

Example

Transaction A locks Table X
Transaction B locks Table Y

A waits for Y
B waits for X

Deadlock

Prevention

Acquire locks in a consistent order.
Keep transactions short.
Use lock timeouts.
Detect and terminate one transaction.

Interview Tip: Most databases automatically detect deadlocks and roll back one of the transactions.

Isolation Levels

Isolation Levels define how transactions interact with each other.

Isolation Level	Dirty Read	Non-Repeatable Read	Phantom Read
Read Uncommitted	Yes	Yes	Yes
Read Committed	No	Yes	Yes
Repeatable Read	No	No	Yes
Serializable	No	No	No

Interview Tip: The higher the isolation level, the better the consistency but the lower the concurrency.

E. Database Scaling

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

In Master-Slave Replication, one database acts as the Master (Primary), while one or more databases act as Slaves (Replicas).

All write operations go to the Master.
Read operations can be distributed to Slave databases.
Changes made on the Master are replicated to the Slaves.

Application
       │
   Write Requests
       │
    Master DB
    /    |    \\
Slave1 Slave2 Slave3
(Read Only)

Advantages

Improves read performance.
Simple architecture.
High availability.

Disadvantages

Master becomes a write bottleneck.
Replication lag may occur.

In Master-Master Replication, two or more databases can handle both read and write operations.

Each Master replicates its changes to the other Masters.

Master A  ⇄  Master B

Advantages

High Availability.
No single write server.
Better fault tolerance.

Disadvantages

Conflict resolution becomes difficult.
More complex architecture.

Use Cases

Multi-region applications.
Global systems.

Interview Tip: Master-Master replication requires conflict resolution strategies when the same data is updated simultaneously.

Read Replicas

Read Replicas are copies of the Primary database used only for handling read queries.

Workflow:

Writes → Primary Database.
Reads → Replica Databases.

Application

Writes → Primary DB

Reads  → Replica 1
       → Replica 2
       → Replica 3

Advantages

Reduces load on the Primary database.
Improves read scalability.
Supports high traffic.

Interview Tip: Read Replicas are commonly used in read-heavy applications like e-commerce and news websites.

Database Sharding

Sharding is the process of splitting a large database into smaller independent databases called Shards.

Each shard stores only a portion of the data.

Example:

Shard 1 → Customer ID 1–1M

Shard 2 → Customer ID 1M–2M

Shard 3 → Customer ID 2M–3M

Advantages

Horizontal scalability.
Faster queries.
Better write performance.
Reduced storage per server.

Disadvantages

Complex joins.
Difficult transactions.
More operational complexity.

Interview Tip: Sharding increases both read and write scalability.

Horizontal Partitioning divides a table into multiple partitions based on rows.

Each partition contains the same columns but different rows.

Example:

Users

1–1,000,000

↓

Server A

1,000,001–2,000,000

↓

Server B

Advantages

Better scalability.
Faster queries.
Easier distribution across servers.

Interview Tip: Database Sharding is a form of Horizontal Partitioning.

Vertical Partitioning divides a table based on columns instead of rows.

Example:

Employee

Basic Details

↓

Employee_ID
Name
Email

Salary Details

↓

Employee_ID
Salary
Bonus

Advantages

Faster queries.
Reduced I/O.
Better security.

Use Cases

Frequently accessed columns.
Large tables with many columns.

Consistent Hashing

Consistent Hashing is a technique used to distribute data evenly across multiple servers while minimizing data movement when servers are added or removed.

Instead of rehashing all keys, only a small portion of the data is redistributed.

Advantages

Better scalability.
Minimal data movement.
Balanced distribution.

Use Cases

Redis Cluster
Cassandra
Distributed Caching
CDN

Interview Tip: Consistent Hashing avoids massive data redistribution when scaling the system.

Auto Increment IDs do not work well in sharded databases because multiple shards may generate the same ID.

Example:

Shard A

Next ID → 100

Shard B

Next ID → 100

Duplicate IDs

Solutions

UUID
Snowflake IDs
Hi-Lo Algorithm
Database Sequences
Shard-specific ID ranges

Interview Tip: Most large distributed systems avoid Auto Increment IDs and use globally unique ID generators like Snowflake.

Cross-Shard Joins

A Cross-Shard Join occurs when data required for a query exists in different shards.

Example:

Orders → Shard A

Customers → Shard B

Joining this data requires communication between multiple shards.

Problems

High latency.
Complex query execution.
Increased network overhead.

Solutions

Denormalization.
Application-level joins.
Data duplication.
Carefully designed shard keys.

Interview Tip: Cross-shard joins should be minimized because they reduce the benefits of sharding.

A Global Transaction is a transaction that spans multiple databases or multiple shards.

Example:

Transfer Money

↓

Database A

↓

Database B

Challenges:

Maintaining consistency.
Handling failures.
Coordinating commits.

Common solutions:

Two-Phase Commit (2PC)
Saga Pattern
Event-Driven Architecture

Interview Tip: Modern microservices often prefer the Saga Pattern over Two-Phase Commit because it provides better scalability and avoids long-running locks.

Database Failover

Database Failover is the automatic process of switching from a failed Primary database to a healthy Replica database.

Workflow:

Primary Database

↓

Failure

↓

Replica Promoted

↓

Application Continues

Advantages

High Availability.
Reduced downtime.
Automatic recovery.

Interview Tip: Cloud databases such as Amazon RDS support automatic failover.

Split Brain

Split Brain occurs when two database nodes both believe they are the Primary due to a network partition.

Example:

Network Failure

↓

Primary A

Primary B

(Both accept writes)

This results in conflicting data.

Solutions

Quorum-based consensus.
Leader Election.
Distributed Coordination (ZooKeeper, etcd).
Fencing Tokens.

Interview Tip: Split Brain is a common challenge in distributed systems and must be prevented using consensus algorithms.

A Multi-region Database stores and replicates data across multiple geographic regions.

Example:

India Region

↓

Europe Region

↓

US Region

Advantages

Lower latency for global users.
Disaster recovery.
High Availability.
Business continuity.

Challenges

Replication lag.
Data consistency.
Conflict resolution.
Increased operational complexity.

Examples

Google Spanner
Amazon Aurora Global Database
CockroachDB

Interview Tip: Multi-region databases improve global availability and reduce latency but require careful consideration of consistency and replication strategies.

F. Messaging Systems

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

A Message Queue (MQ) is a communication mechanism that enables applications or services to exchange messages asynchronously.

Instead of communicating directly, the producer sends messages to a queue, and the consumer processes them later.

Why do we use Message Queues?

Asynchronous communication.
Decouple services.
Improve scalability.
Handle traffic spikes.
Increase reliability.
Retry failed messages.
Better fault tolerance.
Improve system performance.

Example

In an e-commerce application, after placing an order:

Order Service → Saves Order
Sends message to Kafka/RabbitMQ
Inventory Service updates stock
Payment Service processes payment
Notification Service sends email

All these happen asynchronously.

Interview Tip: Message Queues make microservices loosely coupled and highly scalable.

Kafka vs RabbitMQ

Kafka	RabbitMQ
Distributed Event Streaming Platform	Traditional Message Broker
High Throughput	Lower Throughput
Stores messages on disk	Removes messages after consumption (by default)
Pull-based consumption	Push-based delivery
Best for Event Streaming	Best for Task Queues
Excellent scalability	Easier routing capabilities

Use Kafka when:

Event Streaming
Log Processing
Big Data
Analytics
High Throughput Systems

Use RabbitMQ when:

Background Jobs
Email Queues
Payment Processing
Task Scheduling

Interview Tip: Kafka is optimized for high-volume event streaming, whereas RabbitMQ is optimized for reliable message delivery and complex routing.

Kafka Architecture

Kafka follows a distributed architecture consisting of:

Producer
Broker
Topic
Partition
Consumer
Consumer Group
ZooKeeper (older versions) / KRaft (newer versions)

Producer

↓

Kafka Broker

↓

Topic

↓

Partition

↓

Consumer Group

Advantages

High Throughput.
Fault Tolerance.
Horizontal Scalability.
Durable Storage.

Kafka Topics

A Topic is a logical category where Kafka stores messages.

Producers publish messages to Topics, and Consumers subscribe to Topics.

Example:

Topics

OrderCreated

PaymentCompleted

UserRegistered

A Topic can have multiple partitions for scalability.

Interview Tip: Topics are logical containers; the actual data is stored inside partitions.

Kafka Partitions

A Partition is a physical subdivision of a Topic.

Messages are distributed across partitions to improve scalability and parallel processing.

Example:

Order Topic

Partition 0

Partition 1

Partition 2

Advantages

Parallel processing.
Higher throughput.
Horizontal scalability.

Interview Tip: Ordering is guaranteed only within a single partition.

Kafka Replication

Kafka Replication creates multiple copies of each partition across different brokers.

One replica acts as the Leader, while others are Followers.

Partition 0

Leader

↓

Follower

↓

Follower

If the Leader fails, one of the Followers is automatically promoted.

Advantages

High Availability.
Fault Tolerance.
Data Durability.

Consumer Groups

A Consumer Group is a collection of consumers working together to consume messages from a Topic.

Each partition is assigned to only one consumer within a group.

Topic

Partition 0 → Consumer A

Partition 1 → Consumer B

Partition 2 → Consumer C

Advantages

Parallel processing.
Load balancing.
Horizontal scalability.

Interview Tip: The maximum parallelism equals the number of partitions.

Acknowledgements (ACKs) determine when Kafka considers a message successfully written.

acks = 0

Producer doesn’t wait for acknowledgment.
Fastest.
Possible message loss.

acks = 1

Waits for Leader acknowledgment.
Good performance.
Some risk if Leader fails before replication.

acks = all (-1)

Waits for all in-sync replicas.
Highest reliability.
Slightly higher latency.

Interview Tip: Production systems usually use acks=all for maximum durability.

Kafka Offset

An Offset is a unique sequential number assigned to each message within a partition.

Consumers track offsets to know which messages have already been processed.

Example:

Partition 0

Offset

0

1

2

3

4

Advantages

Resume processing after failures.
Replay old messages.
Reliable message consumption.

A Dead Letter Queue stores messages that cannot be processed successfully after multiple retry attempts.

Workflow:

Message

↓

Processing Failed

↓

Retry

↓

Still Failed

↓

Dead Letter Queue

Advantages

Prevents message loss.
Allows later analysis.
Prevents blocking the main queue.

Retry Queue

A Retry Queue temporarily stores failed messages before retrying them.

Workflow:

Processing Failed

↓

Retry Queue

↓

Retry Later

↓

Success

Advantages

Handles temporary failures.
Reduces immediate system load.
Improves reliability.

Ordering Guarantee

Kafka guarantees message ordering only within a single partition.

Messages written to the same partition are consumed in the exact order they were produced.

Example:

Partition 1

Order Created

↓

Payment

↓

Invoice

↓

Shipment

If messages are distributed across multiple partitions, global ordering is not guaranteed.

Interview Tip: To maintain ordering, ensure related messages are sent to the same partition using the same key.

An Idempotent Producer ensures that duplicate messages are not written to Kafka, even if retries occur.

Kafka assigns sequence numbers to messages and ignores duplicates.

Advantages

Prevents duplicate events.
Improves reliability.
Supports Exactly Once Processing.

Interview Tip: Enable idempotence using:

enable.idempotence=true

Message Deduplication is the process of detecting and removing duplicate messages before processing.

Common approaches:

Unique Message IDs.
Database Constraints.
Idempotent Consumers.
Redis Cache.
Transaction IDs.

Use Cases

Payment Systems.
Order Processing.
Financial Transactions.

Event Streaming

Event Streaming is the continuous flow of events from producers to consumers in real time.

Unlike traditional messaging, events remain stored and can be replayed.

Examples:

User Click Events.
Payment Events.
Order Events.
Sensor Data.

Advantages

Real-time processing.
Replay capability.
High throughput.
Scalable architecture.

Interview Tip: Apache Kafka is one of the most widely used event streaming platforms.

Event Sourcing

Event Sourcing is a design pattern where the application’s state is derived by storing every change as an immutable event instead of storing only the latest state.

Example:

Instead of storing:

Account Balance = ₹10,000

Store events:

Account Created

↓

₹5,000 Deposited

↓

₹2,000 Withdrawn

↓

₹7,000 Deposited

The current balance is calculated by replaying these events.

Advantages

Complete audit history.
Easy debugging.
Event replay.
Supports CQRS.

Disadvantages

Increased storage.
More complex implementation.

Interview Tip: Event Sourcing is commonly used with Kafka and CQRS in large-scale distributed systems where maintaining a complete history of changes is important.

G. Microservices Design

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Monolith	Microservices
Entire application is a single unit	Application is divided into independent services
Single codebase	Multiple codebases
Single deployment	Independent deployments
Easier to develop initially	Easier to scale and maintain
Technology stack is fixed	Different services can use different technologies
Failure may affect the entire application	Failure is isolated to one service

Examples

Monolith:

Small business applications
Internal tools

Microservices:

Amazon
Netflix
Uber
Flipkart

Interview Tip: Monolith is simpler to start, while Microservices are better for large, scalable applications.

Microservices divide a large application into small, independently deployable services.

Advantages

Independent deployment.
Better scalability.
Fault isolation.
Faster development.
Technology flexibility.
Smaller codebase.
Easier maintenance.
Better team ownership.

Example

E-commerce Application:

User Service
Product Service
Order Service
Payment Service
Inventory Service
Notification Service

Each service can be developed, deployed, and scaled independently.

Interview Tip: Microservices improve scalability and maintainability but introduce challenges like distributed communication, monitoring, and data consistency.

Service Discovery

Service Discovery is a mechanism that allows microservices to automatically discover the network location of other services.

Instead of hardcoding IP addresses, services register themselves with a Service Registry.

Order Service

↓

Service Registry

↓

Product Service

Advantages

Dynamic service registration.
Automatic discovery.
Better scalability.
No hardcoded URLs.

Examples

Eureka
Consul
Kubernetes Service Discovery

Eureka

Eureka is Netflix’s Service Registry used for Service Discovery in Spring Cloud.

Workflow:

Service starts.

User Service

↓

Eureka Server

↓

Order Service

Advantages

Dynamic discovery.
Health monitoring.
Load balancing support.
High availability.

Interview Tip: Although Eureka is still widely used in Spring projects, Kubernetes environments often rely on built-in Service Discovery instead.

API Gateway

An API Gateway acts as the single entry point for all client requests.

Responsibilities:

Request routing.
Authentication.
Authorization.
Rate limiting.
SSL termination.
Logging.
Request aggregation.

Client

↓

API Gateway

↓

User Service

Order Service

Payment Service

Advantages

Simplifies client communication.
Improves security.
Centralizes cross-cutting concerns.

Spring Cloud Gateway is the modern API Gateway solution provided by Spring Cloud.

Features:

Dynamic routing.
Authentication.
JWT validation.
Rate limiting.
Request filtering.
Load balancing.
Circuit Breaker integration.

Advantages

Reactive and high performance.
Easy Spring Boot integration.
Cloud-native architecture.

Interview Tip: Spring Cloud Gateway has replaced Netflix Zuul in modern Spring Boot applications.

Config Server

Spring Cloud Config Server centralizes configuration for multiple microservices.

Instead of storing configuration in every service, configurations are maintained in one central location.

Git Repository

↓

Config Server

↓

User Service

↓

Order Service

↓

Payment Service

Advantages

Centralized configuration.
Easy updates.
Environment-specific configuration.
Version control.

Centralized Configuration means storing application configuration in a common location rather than inside each microservice.

Configuration includes:

Database URLs.
API Keys.
Feature Flags.
External Service URLs.
Environment Properties.

Benefits

Easy management.
Consistent configuration.
Reduced duplication.
Faster deployments.

Examples

Spring Cloud Config
Consul
AWS Parameter Store

Feign Client

Feign Client is a declarative HTTP client provided by Spring Cloud.

Instead of writing REST calls manually, developers define Java interfaces.

Example:

@FeignClient(name = "product-service")
public interface ProductClient {
    @GetMapping("/products/{id}")
    Product getProduct(Long id);
}

Advantages

Less boilerplate code.
Easy integration.
Load balancing support.
Circuit Breaker integration.

Interview Tip: Feign Client simplifies inter-service communication in Spring Boot microservices.

Circuit Breaker

A Circuit Breaker prevents repeated calls to a failing service.

States:

Closed → Requests flow normally.
Open → Requests fail immediately.
Half Open → Limited requests are allowed to test recovery.

Service Failure

↓

Circuit Opens

↓

Requests Blocked

↓

Recovery Test

↓

Circuit Closes

Advantages

Prevents cascading failures.
Improves resilience.
Faster failure recovery.

Examples

Resilience4j
Hystrix (deprecated)

Retry Pattern

The Retry Pattern automatically retries failed requests before reporting failure.

Example:

Request

↓

Failure

↓

Retry 1

↓

Retry 2

↓

Success

Advantages

Handles temporary failures.
Improves reliability.

Best Practices

Use exponential backoff.
Set retry limits.
Avoid infinite retries.

Bulkhead Pattern

The Bulkhead Pattern isolates system resources so that the failure of one component does not affect others.

Example:

Thread Pool A

↓

Payment Service

Thread Pool B

↓

Notification Service

If the Payment Service becomes overloaded, the Notification Service continues functioning normally.

Advantages

Fault isolation.
Improved stability.
Prevents resource exhaustion.

Rate Limiting

Rate Limiting restricts the number of requests a client can make within a specified time period.

Example:

100 Requests

Per Minute

Per User

Advantages

Prevents abuse.
Protects backend services.
Improves availability.
Mitigates DDoS attacks.

Algorithms

Token Bucket.
Leaky Bucket.
Fixed Window.
Sliding Window.

Service Mesh

A Service Mesh is a dedicated infrastructure layer that manages communication between microservices.

It provides:

Traffic management.
Security.
Load balancing.
Observability.
Retry.
Circuit Breaking.
Mutual TLS (mTLS).

Examples

Istio
Linkerd
Consul Connect

Interview Tip: Service Mesh handles networking concerns without changing application code.

Sidecar Pattern

The Sidecar Pattern deploys a helper container alongside each microservice.

The Sidecar handles infrastructure responsibilities such as:

Logging.
Monitoring.
Security.
Service Discovery.
Proxying.

Pod

├── Application Container

└── Sidecar Container

Examples

Envoy Proxy
Fluentd

Advantages

Separation of concerns.
Reusable infrastructure.
Easier maintenance.

Blue-Green Deployment maintains two identical production environments.

Blue → Current production.
Green → New version.

Traffic is switched to Green only after successful validation.

Users

↓

Load Balancer

↓

Blue (Current)

Green (New)

↓

Switch Traffic

Advantages

Zero downtime.
Easy rollback.
Safer deployments.

Canary Deployment

Canary Deployment releases a new version to a small percentage of users before rolling it out to everyone.

Example:

5% Users → Version 2

95% Users → Version 1

↓

Monitor

↓

100% Rollout

Advantages

Reduced deployment risk.
Real user testing.
Easy rollback.

Rolling Updates

Rolling Updates replace old application instances with new ones gradually.

Example:

Server 1 → Updated

↓

Server 2 → Updated

↓

Server 3 → Updated

Only a few instances are updated at a time, ensuring the application remains available throughout the deployment.

Advantages

Zero or minimal downtime.
Controlled deployment.
No additional infrastructure required.

Interview Tip: Kubernetes uses Rolling Updates as the default deployment strategy because it maintains service availability while gradually replacing application instances.

H. Distributed Transactions

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Two-Phase Commit (2PC) is a distributed transaction protocol that ensures all participating services either commit or roll back together.

It consists of two phases:

Phase 1: Prepare Phase

The Coordinator asks all participants if they are ready to commit.
Each participant replies:
YES (Ready)
NO (Cannot Commit)

Phase 2: Commit Phase

If every participant replies YES → Commit transaction.
If any participant replies NO → Rollback transaction.

Coordinator

↓

Prepare

↓

Service A   Service B   Service C

↓

All YES

↓

Commit

OR

One NO

↓

Rollback

Advantages

Strong consistency.
ACID compliance.

Disadvantages

Blocking protocol.
Coordinator becomes a single point of failure.
Poor scalability.
Long-running locks.

Interview Tip: 2PC is rarely used in modern microservices because it blocks resources and reduces scalability.

The Saga Pattern is a distributed transaction pattern where a large transaction is broken into multiple smaller local transactions.

Each service performs its own transaction independently.

If one service fails, previously completed transactions are undone using Compensation Transactions.

Example:

Create Order

↓

Reserve Inventory

↓

Process Payment

↓

Send Notification

If Payment fails:

Cancel Inventory

↓

Cancel Order

Advantages

High scalability.
No distributed locking.
Better performance.
Suitable for microservices.

Disadvantages

More complex implementation.
Compensation logic required.

Interview Tip: Saga Pattern is the preferred approach for distributed transactions in modern microservices.

Choreography Saga

In Choreography Saga, there is no central coordinator.

Each service publishes events after completing its transaction, and other services react to those events.

Example:

Order Created

↓

Inventory Reserved

↓

Payment Completed

↓

Notification Sent

Each service listens for events and decides its next action.

Advantages

Loosely coupled.
No central coordinator.
Highly scalable.

Disadvantages

Difficult to track workflows.
Complex debugging.
Event chains become harder to manage.

Interview Tip: Choreography is suitable for smaller workflows with fewer participating services.

Orchestration Saga

In Orchestration Saga, a central Saga Orchestrator controls the entire workflow.

Instead of services communicating directly, the orchestrator tells each service what to do.

Example:

Saga Orchestrator

↓

Order Service

↓

Inventory Service

↓

Payment Service

↓

Notification Service

If a failure occurs, the orchestrator triggers compensation steps.

Advantages

Centralized workflow.
Easier monitoring.
Easier debugging.
Better control.

Disadvantages

Orchestrator becomes an additional component.
Slightly tighter coupling.

Interview Tip: Large enterprise applications generally prefer Orchestration Saga because workflows are easier to manage.

A Compensation Transaction is an operation that reverses the effect of a previously completed transaction.

Unlike database rollback, compensation executes a new business operation.

Example:

Order Created

↓

Payment Failed

↓

Cancel Order

↓

Release Inventory

Examples:

Refund Payment.
Cancel Order.
Release Reserved Inventory.
Reverse Loyalty Points.

Interview Tip: Compensation does not undo database changes; it performs another business action to restore consistency.

Idempotency means performing the same operation multiple times produces the same final result.

Example:

Suppose a payment request is retried due to a timeout.

Without idempotency:

₹500 Paid

↓

Retry

↓

₹500 Paid Again

Duplicate payment occurs.

With idempotency:

₹500 Paid

↓

Retry

↓

Ignored

↓

Still ₹500

Common implementations:

Idempotency Key.
Unique Transaction ID.
Database Unique Constraints.
Redis Cache.

Interview Tip: Idempotency is essential in distributed systems because retries are common.

Eventual Consistency means all services may not be immediately consistent, but they will become consistent after some time.

Example:

Order Created

↓

Inventory Updated

↓

Payment Completed

↓

Notification Sent

For a short period, different services may have different data.

Eventually, every service reaches the same state.

Advantages

Better scalability.
High availability.
Better performance.

Interview Tip: Eventual Consistency is one of the core principles behind microservices and distributed systems.

Application

↓

Business Table

+

Outbox Table

↓

Commit

↓

Background Publisher

↓

Kafka

Advantages

Prevents lost events.
Ensures reliable messaging.
Avoids dual-write problems.

Interview Tip: The Outbox Pattern is widely used with Kafka in Spring Boot microservices.

CDC (Change Data Capture) captures database changes and publishes them as events.

Instead of the application publishing events, a CDC tool monitors the database transaction log.

Workflow:

Database

↓

Transaction Log

↓

CDC Tool (Debezium)

↓

Kafka

↓

Consumers

Advantages

No application code changes.
Reliable event publishing.
Keeps services synchronized.

Examples

Debezium.
Oracle GoldenGate.
SQL Server CDC.

Interview Tip: CDC is commonly combined with the Outbox Pattern for highly reliable event-driven architectures.

Transactional Messaging ensures that a business transaction and the corresponding message are handled reliably.

Problem without Transactional Messaging:

Save Order

↓

Database Commit

↓

Kafka Publish Failed

The database contains the order, but other services never receive the event.

Using Transactional Messaging (typically with the Outbox Pattern):

Save Order

+

Save Outbox Event

↓

Single Database Transaction

↓

Background Publisher

↓

Kafka

This guarantees that every committed transaction eventually results in a published event.

Advantages

Reliable messaging.
No lost events.
Better consistency.
Suitable for event-driven microservices.

Interview Tip: In modern Spring Boot microservices, Outbox Pattern + Kafka + CDC (Debezium) is considered one of the most robust solutions for implementing transactional messaging without relying on Two-Phase Commit.

I. API Design

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

REST (Representational State Transfer) is an architectural style used to design scalable and loosely coupled web APIs.

REST follows these principles:

Client-Server Architecture.
Stateless Communication.
Uniform Interface.
Resource-Based URLs.
Representation using JSON/XML.
Cacheable Responses.
Layered Architecture.

Example:

GET /users/101

POST /orders

PUT /products/10

DELETE /cart/5

Advantages

Simple.
Scalable.
Platform Independent.
Lightweight.

Interview Tip: REST is an architectural style, not a protocol.

REST vs SOAP

REST	SOAP
Architectural Style	Protocol
Uses HTTP	Supports HTTP, SMTP, TCP, etc.
Usually JSON	XML only
Lightweight	Heavyweight
Faster	Slower
Easy to develop	More complex
Widely used for web APIs	Common in enterprise systems

Use REST when:

Building web/mobile applications.
Microservices.
Public APIs.

Use SOAP when:

Enterprise applications.
Banking.
Legacy systems requiring strict security.

Interview Tip: REST is the preferred choice for modern microservices because it is lightweight and easier to consume.

REST vs GraphQL

REST	GraphQL
Multiple endpoints	Single endpoint
Fixed response structure	Client chooses required fields
May over-fetch data	Fetches only requested data
Easy caching	More complex caching
Simple implementation	Flexible queries

Example

REST:

GET /users/101

GraphQL:

{
  user(id:101){
    name
    email
  }
}

Use GraphQL when:

Mobile applications.
Complex frontend requirements.
Multiple related resources.

Interview Tip: GraphQL reduces over-fetching and under-fetching but adds server-side complexity.

REST vs gRPC

REST	gRPC
HTTP/1.1	HTTP/2
JSON	Protocol Buffers (Binary)
Human readable	Compact binary format
Slower	Faster
Public APIs	Internal microservice communication

Advantages of gRPC

Low latency.
High performance.
Streaming support.
Strong contract using Protocol Buffers.

Interview Tip: REST is preferred for external APIs, while gRPC is commonly used for high-performance communication between internal microservices.

API Versioning allows changes to an API without breaking existing clients.

Common approaches:

URI Versioning

/api/v1/users

/api/v2/users

Header Versioning

API-Version: 2

Query Parameter

/users?version=2

Advantages

Backward compatibility.
Smooth migration.
Supports multiple client versions.

Interview Tip: URI versioning (/v1, /v2) is the most commonly used approach.

Pagination divides large datasets into smaller pages instead of returning all records at once.

Example:

GET /products?page=2&size=20

Advantages

Faster response.
Reduced memory usage.
Better user experience.
Lower database load.

Types

Offset Pagination.
Cursor Pagination.
Keyset Pagination.

Interview Tip: Cursor-based pagination performs better for very large datasets.

Filtering allows clients to retrieve only the records that match specific conditions.

Example:

GET /products?category=Laptop

GET /employees?department=IT

Advantages

Smaller responses.
Better performance.
Flexible querying.

Interview Tip: Filtering should always be performed at the database level whenever possible.

Sorting arranges API results in a specific order.

Example:

GET /products?sort=price

Descending:

GET /products?sort=price,desc

Advantages

Better user experience.
Efficient data presentation.

Interview Tip: Sorting should be backed by proper database indexes for better performance.

HATEOAS (Hypermedia As The Engine Of Application State) is a REST principle where API responses include links to related actions.

Example:

{
  "orderId":101,
  "status":"Created",
  "links":[
      {"rel":"cancel","href":"/orders/101/cancel"},
      {"rel":"payment","href":"/payments/101"}
  ]
}

Advantages

Self-discoverable APIs.
Better navigation.
Reduced client hardcoding.

Interview Tip: HATEOAS is part of REST but is not implemented in most modern REST APIs due to added complexity.

An API is Idempotent if executing the same request multiple times produces the same final result.

Examples:

GET → Idempotent
PUT → Idempotent
DELETE → Idempotent
POST → Usually not Idempotent

Example:

PUT /users/10

Calling it multiple times with the same data keeps the resource unchanged.

Advantages

Safe retries.
Prevents duplicate updates.
Improves reliability.

Interview Tip: Idempotency is critical for payment APIs and distributed systems.

PUT vs PATCH

PUT	PATCH
Updates the entire resource	Updates only specified fields
Full replacement	Partial update
Usually Idempotent	Usually Idempotent
Sends complete object	Sends modified fields only

Example:

PUT

{
"name":"John",
"age":30,
"city":"Delhi"
}

PATCH

{
"city":"Mumbai"
}

Interview Tip: Use PUT for full updates and PATCH for partial updates.

API Rate Limiting restricts the number of requests a client can make within a specified time period.

Example:

100 Requests

Per Minute

Per User

Advantages

Prevents abuse.
Protects backend services.
Improves availability.
Prevents DDoS attacks.

Common Algorithms

Token Bucket.
Leaky Bucket.
Fixed Window.
Sliding Window.

Interview Tip: Redis is commonly used to implement distributed API rate limiting.

Request Validation ensures that incoming API requests contain valid and complete data before processing.

Validation includes:

Required fields.
Data types.
Length checks.
Email format.
Numeric ranges.
Business rules.

Example:

{
"name":"",
"email":"abc"
}

Response:

400 Bad Request

Advantages

Prevents invalid data.
Improves security.
Reduces application errors.

Interview Tip: In Spring Boot, request validation is commonly implemented using @Valid and Bean Validation annotations.

An API Gateway acts as the single entry point for all client requests in a microservices architecture.

Responsibilities include:

Request routing.
Authentication.
Authorization.
Rate limiting.
SSL termination.
Request logging.
Load balancing.

Client

↓

API Gateway

↓

User Service

Order Service

Payment Service

Advantages

Simplifies client communication.
Centralizes security.
Improves scalability.
Reduces client complexity.

Examples

Spring Cloud Gateway.
Kong.
AWS API Gateway.
NGINX.

Interview Tip: API Gateway is one of the core components of a microservices architecture.

OpenAPI is a specification for documenting REST APIs.

Swagger is a popular tool that implements the OpenAPI Specification and provides interactive API documentation.

Features

API documentation.
Interactive API testing.
Request and response examples.
Automatic client SDK generation.
Contract-first API development.

Example:

GET /users/{id}

Request Parameters

Response

HTTP Status Codes

Example Payload

Advantages

Better collaboration.
Easy API testing.
Improved documentation.
Faster development.

Interview Tip: In Spring Boot, springdoc-openapi is commonly used to generate Swagger UI automatically, making it easier for developers and testers to explore and validate REST APIs.

J. Security

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Authentication and Authorization are two fundamental security concepts, but they serve different purposes.

Authentication verifies who the user is.
Authorization determines what the authenticated user is allowed to do.

Authentication	Authorization
Verifies identity	Verifies permissions
Happens first	Happens after authentication
Example: Login	Example: Access control
Uses Username/Password, OTP, JWT	Uses Roles and Permissions

Example

A banking application:

User logs in using username and password → Authentication
User can access only their own account → Authorization

Interview Tip: Authentication answers “Who are you?”, while Authorization answers “What are you allowed to do?”

OAuth2 is an authorization framework that allows third-party applications to access user resources without sharing the user’s password.

Instead of sharing credentials, OAuth2 uses Access Tokens.

Example:

User

↓

Google Login

↓

Authorization Server

↓

Access Token

↓

Application

Common Grant Types

Authorization Code (Most Secure)
Client Credentials
Refresh Token
Device Authorization

Advantages

No password sharing.
Secure delegated access.
Widely supported.
Token-based authentication.

Examples

Interview Tip: OAuth2 is for authorization, not authentication. Authentication is commonly achieved using OpenID Connect (OIDC) built on top of OAuth2.

JWT is a compact, signed token used for stateless authentication.

After successful login, the server generates a JWT and returns it to the client. The client sends the token with every request.

Structure:

Header.Payload.Signature

Example Request:

Authorization: Bearer

Advantages

Stateless authentication.
No server-side session storage.
Easy to scale.
Fast verification.

Disadvantages

Cannot be revoked easily.
Larger than session IDs.
Expiration must be managed carefully.

Interview Tip: Never store sensitive information like passwords inside a JWT payload because it is only Base64 encoded, not encrypted.

A Refresh Token is a long-lived token used to generate a new Access Token after the current Access Token expires.

Workflow:

Login

↓

Access Token (15 Minutes)

+

Refresh Token (7 Days)

↓

Access Token Expires

↓

Use Refresh Token

↓

New Access Token

Advantages

Better security.
Improved user experience.
Reduces frequent logins.

Interview Tip: Store Refresh Tokens securely (preferably in HttpOnly cookies) and rotate them whenever possible.

API Key Authentication authenticates clients using a unique API Key.

Example:

GET /products

x-api-key: abc123xyz

Advantages

Simple implementation.
Suitable for server-to-server communication.
Easy to manage.

Disadvantages

No user identity.
Cannot provide fine-grained authorization.
If leaked, it can be misused.

Use Cases

Public APIs.
Internal services.
Third-party integrations.

Interview Tip: API Keys identify the calling application, not the end user.

Mutual TLS (mTLS) is an extension of TLS where both the client and the server authenticate each other using digital certificates.

Normal HTTPS:

Server is authenticated.

Mutual TLS:

Server is authenticated.
Client is also authenticated.

Client Certificate

⇄

Server Certificate

Advantages

Strong authentication.
Prevents unauthorized clients.
Highly secure communication.

Use Cases

Banking.
Healthcare.
Internal microservices.

Interview Tip: mTLS is commonly used for secure communication between internal microservices.

HTTPS is HTTP secured using TLS (formerly SSL).

It provides:

Encryption.
Authentication.
Data Integrity.

Without HTTPS, attackers can read or modify network traffic.

Example:

Browser

⇄ HTTPS ⇄

Server

Advantages

Protects sensitive data.
Prevents man-in-the-middle attacks.
Builds user trust.

Interview Tip: Always use HTTPS in production, especially for authentication and payment APIs.

Client Hello

↓

Server Hello

↓

Certificate Exchange

↓

Key Exchange

↓

Secure Communication

Advantages

Secure key exchange.
Server authentication.
Confidential communication.

Interview Tip: Modern systems use TLS, while SSL is deprecated.

Encryption in Transit protects data while it travels across a network.

Example:

Client

⇄ TLS ⇄

Server

Advantages

Prevents packet sniffing.
Protects sensitive information.
Ensures secure communication.

Examples

HTTPS.
TLS.
mTLS.

Interview Tip: HTTPS is the most common implementation of encryption in transit.

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls whether one origin can access resources from another origin.

Example:

Frontend:

https://app.example.com

Backend:

https://api.example.com

The backend must explicitly allow the frontend origin.

Common Headers

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers

Interview Tip: CORS is enforced by browsers, not by backend servers.

SQL Injection is an attack where malicious SQL code is injected into application queries.

Unsafe Query:

SELECT * FROM users WHERE username='admin' AND password='password';

An attacker may manipulate the input to bypass authentication or retrieve unauthorized data.

Prevention

Prepared Statements.
Parameterized Queries.
ORM Frameworks (JPA/Hibernate).
Input Validation.
Least Privilege Database Accounts.

Interview Tip: Prepared Statements are the most effective defense against SQL Injection.

XSS allows attackers to inject malicious JavaScript into web pages viewed by other users.

Example:

Instead of a normal comment:

Hello Everyone

An attacker submits malicious JavaScript that executes in other users’ browsers.

Types

Stored XSS.
Reflected XSS.
DOM-based XSS.

Prevention

Output Encoding.
Input Validation.
Content Security Policy (CSP).
Sanitizing user input.

Interview Tip: XSS targets users’ browsers, whereas SQL Injection targets the database.

API Rate Limiting restricts how many requests a client can make within a specified time.

Example:

100 Requests

Per Minute

Per User

Advantages

Prevents abuse.
Protects backend services.
Improves availability.
Controls resource usage.

Common Algorithms

Token Bucket.
Leaky Bucket.
Fixed Window.
Sliding Window.

Implementation

Redis.
API Gateway.
Spring Cloud Gateway.
NGINX.

Interview Tip: API Rate Limiting is one of the first lines of defense against brute-force attacks and API abuse.

A Distributed Denial of Service (DDoS) attack floods a server with massive amounts of traffic from multiple compromised systems, making the application unavailable to legitimate users.

Example:

Thousands of Attackers

↓

Target Server

↓

Server Overloaded

Protection Techniques

Rate Limiting.
Web Application Firewall (WAF).
Content Delivery Network (CDN).
Load Balancers.
Auto Scaling.
Traffic Filtering.
Bot Detection.

Popular Solutions

Cloudflare.
AWS Shield.
Azure DDoS Protection.
Google Cloud Armor.

Interview Tip: DDoS protection is usually implemented as a combination of CDN, WAF, Load Balancer, Rate Limiting, and Auto Scaling rather than relying on a single solution.

K. High Availability

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

In an Active-Active Architecture, multiple servers are active simultaneously and share incoming traffic.

A Load Balancer distributes requests among all active servers.

             Load Balancer
                  │
      ┌───────────┴───────────┐
      │                       │
 Active Server A       Active Server B

If one server fails, traffic is automatically routed to the remaining active servers.

Advantages

High availability.
Better performance.
Improved scalability.
No idle resources.

Disadvantages

More complex synchronization.
Data consistency challenges.

Use Cases

Banking Applications.
E-commerce Platforms.
Streaming Services.

Interview Tip: Active-Active provides both high availability and load balancing.

In an Active-Passive Architecture, one server actively handles all requests while another server remains on standby.

If the active server fails, the passive server takes over.

           Load Balancer
                │
        Active Server
                │
        (Failure Detected)
                │
        Passive Server

Advantages

Simple implementation.
Easy failover.
High availability.

Disadvantages

Passive server remains unused during normal operations.
Lower resource utilization.

Use Cases

Banking Systems.
ERP Applications.
Critical Enterprise Systems.

Interview Tip: Active-Passive is easier to manage but utilizes infrastructure less efficiently than Active-Active.

Failover is the automatic process of switching from a failed component to a healthy standby component.

Example:

Primary Server

↓

Failure

↓

Secondary Server Takes Over

Failover can be:

Automatic.
Manual.

Advantages

Reduces downtime.
Improves availability.
Supports business continuity.

Interview Tip: Automatic failover is commonly used in cloud platforms such as AWS RDS and Kubernetes.

Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss after a disaster.

Example:

If backups occur every 15 minutes, the maximum data loss can be 15 minutes.

Backup ───── 15 Minutes ───── Disaster

Maximum Data Loss = 15 Minutes

Lower RPO means:

Less data loss.
More frequent replication or backups.
Higher implementation cost.

Interview Tip: RPO answers the question: “How much data can we afford to lose?”

Recovery Time Objective (RTO) defines the maximum acceptable time required to restore a system after a failure.

Example:

If the business requires the application to be restored within 30 minutes, then the RTO is 30 minutes.

Failure ───── Recovery (30 Minutes)

Maximum Downtime = 30 Minutes

Lower RTO requires

Faster failover.
Automated recovery.
Redundant infrastructure.

Interview Tip: RTO answers the question: “How quickly must the application recover?”

A Multi Availability Zone deployment places application instances or databases across multiple Availability Zones within the same region.

If one Availability Zone becomes unavailable, traffic is redirected to another healthy zone.

Region

├── AZ-1 (Application + Database)

└── AZ-2 (Application + Replica Database)

Advantages

High availability.
Automatic failover.
Protection against Availability Zone failures.
Low latency within the same region.

Examples

Amazon RDS Multi-AZ.
Kubernetes clusters across multiple AZs.

Interview Tip: Multi-AZ protects against Availability Zone failures, but not complete regional outages.

A Multi-Region Deployment runs applications in multiple geographic regions.

Example:

India Region

↓

Europe Region

↓

US Region

Traffic is routed to the nearest healthy region.

Advantages

Global availability.
Lower latency.
Disaster recovery.
Business continuity.

Challenges

Data replication.
Eventual consistency.
Higher operational cost.

Interview Tip: Multi-Region protects against complete regional failures, unlike Multi-AZ deployments.

A Heartbeat Mechanism is a periodic signal sent between servers to verify that they are alive and functioning correctly.

If heartbeat messages stop, the system assumes the server has failed.

Primary Server

⇄ Heartbeat ⇄

Secondary Server

Advantages

Quick failure detection.
Automatic failover.
Improved system reliability.

Examples

Kubernetes Node Health Monitoring.
Database Clusters.
Distributed Systems.

Interview Tip: Heartbeats are commonly used by cluster managers to detect node failures quickly.

Health Checks verify whether an application or service is healthy and ready to receive requests.

Types

Liveness Check

Determines whether the application is running.

Readiness Check

Determines whether the application is ready to serve traffic.

Example:

GET /actuator/health

Possible Response:

{
  "status": "UP"
}

Advantages

Detects unhealthy instances.
Prevents routing traffic to failed services.
Enables automatic recovery.

Interview Tip: In Kubernetes, failed liveness checks restart containers, while failed readiness checks stop traffic until the application becomes healthy.

Auto Scaling automatically increases or decreases the number of application instances based on workload.

Scaling Out (Horizontal Scaling)

Add more application instances during high traffic.

Scaling In

Remove unnecessary instances during low traffic.

High Traffic

↓

Auto Scaling

↓

2 Servers → 6 Servers

↓

Traffic Decreases

↓

6 Servers → 2 Servers

Advantages

Better availability.
Handles traffic spikes.
Cost optimization.
Improved performance.

Examples

AWS Auto Scaling Groups.
Kubernetes Horizontal Pod Autoscaler (HPA).
Azure Virtual Machine Scale Sets.

Interview Tip: Auto Scaling improves availability and performance by dynamically adjusting resources, but it is most effective when combined with Load Balancers and Health Checks.

L. Logging & Monitoring

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Centralized Logging is the process of collecting logs from multiple applications and servers into a single centralized system for storage, searching, and analysis.

Instead of logging into each server individually, all logs are available in one place.

Application 1 ─┐
Application 2 ─┼──► Central Log Server
Application 3 ─┘

Advantages

Easier troubleshooting.
Faster root cause analysis.
Centralized log management.
Better security auditing.
Simplified monitoring.

Popular Tools

ELK Stack
Loki
Splunk
Graylog

Interview Tip: In a microservices architecture, centralized logging is essential because logs are distributed across multiple services and servers.

ELK is a popular centralized logging solution consisting of three components:

Component	Purpose
Elasticsearch	Stores and indexes logs
Logstash	Collects and processes logs
Kibana	Visualizes and searches logs

Workflow:

Applications

↓

Logstash

↓

Elasticsearch

↓

Kibana Dashboard

Advantages

Powerful search.
Real-time analytics.
Dashboard visualization.
Scalable log storage.

Disadvantages

Higher memory usage.
More operational overhead.

Interview Tip: ELK is ideal for organizations requiring advanced log searching and analytics.

Loki is a lightweight log aggregation system developed by Grafana Labs.

Unlike Elasticsearch, Loki indexes only metadata (labels) rather than the full log content.

Workflow:

Applications

↓

Promtail

↓

Loki

↓

Grafana

Advantages

Lower storage cost.
Faster setup.
Integrates seamlessly with Grafana.
Kubernetes-friendly.

Use Cases

Cloud-native applications.
Kubernetes clusters.
Microservices.

Interview Tip: Loki is often preferred over ELK in Kubernetes environments because it consumes significantly fewer resources.

Prometheus is an open-source monitoring and metrics collection system.

It periodically scrapes metrics exposed by applications and stores them as time-series data.

Workflow:

Application

↓

/metrics Endpoint

↓

Prometheus

↓

Grafana

What does Prometheus monitor?

CPU Usage.
Memory Usage.
Request Count.
Response Time.
Error Rate.
JVM Metrics.

Advantages

Time-series database.
Powerful querying (PromQL).
Alert integration.
Excellent Kubernetes support.

Interview Tip: Prometheus collects metrics, not logs.

Grafana is a visualization platform used to create dashboards for monitoring applications.

It connects to data sources such as:

Prometheus.
Loki.
Elasticsearch.
MySQL.
PostgreSQL.

Example Dashboard:

CPU Usage

Memory Usage

API Response Time

Error Rate

Request Count

Advantages

Interactive dashboards.
Real-time monitoring.
Alerting support.
Multiple data source integration.

Interview Tip: Grafana visualizes data, while Prometheus collects it.

Distributed Tracing tracks a request as it flows across multiple microservices.

Without tracing, it is difficult to identify where delays or failures occur.

Example:

Client

↓

API Gateway

↓

Order Service

↓

Payment Service

↓

Inventory Service

↓

Notification Service

Each step records timing information.

Advantages

End-to-end request visibility.
Easier debugging.
Performance analysis.
Root cause identification.

Interview Tip: Distributed tracing is one of the most important observability features in microservices.

OpenTelemetry (OTel) is an open-source observability framework used to collect:

Logs.
Metrics.
Traces.

It provides a vendor-neutral standard for instrumenting applications.

Workflow:

Application

↓

OpenTelemetry SDK

↓

Collector

↓

Jaeger / Prometheus / Grafana / Zipkin

Advantages

Standardized instrumentation.
Supports multiple backends.
Vendor independent.
Automatic instrumentation.

Interview Tip: OpenTelemetry has become the industry standard for observability in modern cloud-native applications.

Zipkin is an open-source distributed tracing system.

It collects trace data and visualizes request flow across services.

Example:

Client

↓

Order Service (20 ms)

↓

Payment Service (80 ms)

↓

Inventory Service (15 ms)

Advantages

Request tracing.
Latency analysis.
Easy debugging.
Simple setup.

Interview Tip: Zipkin helps identify which service is slowing down an end-to-end request.

Jaeger is an open-source distributed tracing platform originally developed by Uber.

It is widely used with Kubernetes and OpenTelemetry.

Features:

End-to-end tracing.
Dependency graphs.
Performance analysis.
Root cause analysis.

Workflow:

Application

↓

OpenTelemetry

↓

Jaeger

↓

Trace Visualization

Advantages

Highly scalable.
Cloud-native.
Rich UI.
Kubernetes integration.

Interview Tip: Jaeger is generally preferred over Zipkin for large-scale cloud-native microservices.

A Correlation ID is a unique identifier attached to a request and propagated across all microservices.

It allows developers to trace a single request through the entire system.

Example:

Correlation ID

ABC-12345

↓

API Gateway

↓

Order Service

↓

Payment Service

↓

Notification Service

All services log the same Correlation ID.

Advantages

Easier debugging.
End-to-end request tracking.
Faster root cause analysis.

Interview Tip: Always include the Correlation ID in application logs to simplify troubleshooting.

Health Checks verify whether an application is running correctly and ready to receive requests.

Types

Liveness Check

Determines whether the application is alive.

Readiness Check

Determines whether the application is ready to serve traffic.

Example:

GET /actuator/health

Response:

{
  "status": "UP"
}

Advantages

Detects unhealthy services.
Enables automatic recovery.
Prevents routing traffic to failed instances.

Interview Tip: In Spring Boot, Health Checks are commonly implemented using Spring Boot Actuator.

Metrics are numerical measurements collected over time to monitor application performance and health.

Common Metrics:

CPU Usage.
Memory Usage.
JVM Heap Usage.
API Response Time.
Request Count.
Error Rate.
Database Connections.
Thread Count.

Example:

Requests/sec : 1200

Average Response Time : 120 ms

Error Rate : 0.2%

Advantages

Performance monitoring.
Capacity planning.
Early issue detection.
Trend analysis.

Interview Tip: Logs explain what happened, while Metrics indicate how healthy the system is.

Alerts notify engineers when application metrics exceed predefined thresholds.

Examples:

CPU Usage > 90%
Memory Usage > 85%
Error Rate > 5%
Response Time > 2 seconds
Disk Usage > 80%

Workflow:

Application

↓

Prometheus

↓

AlertManager

↓

Email / Slack / PagerDuty

Advantages

Early problem detection.
Faster incident response.
Reduced downtime.
Improved reliability.

Interview Tip: Effective alerts should focus on user-impacting issues and avoid excessive notifications (alert fatigue).

M. CDN & Storage

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

A Content Delivery Network (CDN) is a globally distributed network of servers that caches and delivers static content (images, videos, CSS, JavaScript, PDFs, etc.) from the server closest to the user.

Instead of every request going to the origin server, users receive content from the nearest CDN edge server.

User (India)

↓

Nearest CDN Edge Server

↓

Origin Server (Only if cache miss)

Advantages

Faster content delivery.
Lower latency.
Reduced server load.
Better user experience.
Improved availability.

Examples

Cloudflare
Amazon CloudFront
Akamai
Google Cloud CDN

Interview Tip: A CDN is primarily used to improve content delivery speed and reduce the load on the origin server.

A CDN is used to improve application performance by serving content from locations closer to users.

Without CDN:

User (India)

↓

US Server

With CDN:

User (India)

↓

Mumbai CDN Edge Server

Benefits

Lower latency.
Faster page loading.
Reduced bandwidth usage.
High availability.
DDoS protection.
Better scalability.

Common Content Served

Images.
Videos.
CSS.
JavaScript.
Fonts.
PDF Files.

Interview Tip: CDNs are ideal for static content. Dynamic content is usually served directly by the application server unless CDN acceleration is specifically configured.

CDN Caching stores frequently requested content on edge servers.

When another user requests the same content, it is served directly from the CDN instead of the origin server.

Workflow:

First Request

↓

Origin Server

↓

CDN Cache

↓

Next Request

↓

Served From CDN

Advantages

Faster response time.
Reduced origin server traffic.
Lower bandwidth costs.
Better scalability.

Cache Control Headers

Cache-Control
Expires
ETag
Last-Modified

Interview Tip: Proper cache expiration policies are important to prevent users from receiving stale content.

Edge Servers are geographically distributed CDN servers located close to end users.

They cache and serve static content without contacting the origin server for every request.

Example:

India User

↓

Mumbai Edge Server

↓

Origin Server (Only if Required)

Advantages

Reduced latency.
Faster downloads.
Lower network congestion.
Better user experience.

Interview Tip: The closer the Edge Server is to the user, the lower the network latency.

Object Storage stores data as objects instead of files or database records.

Each object contains:

Data.
Metadata.
Unique Identifier.

Object

├── Data

├── Metadata

└── Object ID

Advantages

Massive scalability.
High durability.
Metadata support.
Easy cloud integration.

Examples

Amazon S3.
Azure Blob Storage.
Google Cloud Storage.
MinIO.

Interview Tip: Modern cloud applications primarily use Object Storage instead of traditional file systems for storing media and backups.

Amazon S3 (Simple Storage Service) is AWS’s highly durable and scalable Object Storage service.

Features:

Unlimited storage.
99.999999999% (11 nines) durability.
Versioning.
Lifecycle Management.
Encryption.
Cross-region replication.

Example:

Application

↓

Upload Image

↓

Amazon S3

↓

CDN (CloudFront)

↓

User

Common Use Cases

Image Storage.
Video Storage.
Static Website Hosting.
Backup.
Log Storage.

Interview Tip: S3 stores files as objects inside buckets, not in folders like a traditional file system.

File Storage	Object Storage
Stores data as files and folders	Stores data as objects
Hierarchical directory structure	Flat namespace
Supports file locking	No traditional file locking
Better for shared file systems	Better for cloud-native applications
Limited scalability	Virtually unlimited scalability
Examples: NFS, EFS	Examples: S3, Azure Blob Storage

Use File Storage when:

Shared file systems.
Legacy enterprise applications.

Use Object Storage when:

Images.
Videos.
Documents.
Backups.
Cloud applications.

Interview Tip: Object Storage is the preferred choice for modern cloud-native applications due to its scalability and durability.

A Signed URL is a secure URL that grants temporary access to a private resource.

Instead of making the file public, the server generates a URL containing a digital signature.

Example:

https://cdn.example.com/file.pdf?signature=XYZ123

Advantages

Secure access.
Temporary authorization.
No public file exposure.

Use Cases

Private documents.
Paid content.
Secure downloads.
Premium videos.

Interview Tip: Signed URLs allow secure file sharing without requiring users to authenticate for every download.

A Pre-Signed URL is a special type of Signed URL generated by cloud storage services like Amazon S3.

It allows temporary access to upload or download an object without exposing AWS credentials.

Workflow:

Client

↓

Application Server

↓

Generate Pre-Signed URL

↓

Client Uploads Directly to S3

Advantages

Secure uploads.
Reduced application server load.
Temporary access.
No credential exposure.

Use Cases

Profile Picture Uploads.
Video Uploads.
Document Uploads.

Interview Tip: Pre-Signed URLs are commonly used to allow clients to upload files directly to S3, bypassing the application server and improving scalability.

Media Delivery is the process of efficiently delivering images, videos, audio, and other large files to end users.

A typical architecture is:

User

↓

CDN

↓

Object Storage (S3)

↓

Application

Best Practices

Store media in Object Storage.
Deliver through a CDN.
Compress images and videos.
Use adaptive streaming for videos.
Cache static media.
Generate thumbnails for images.

Advantages

Faster content delivery.
Reduced bandwidth costs.
Improved scalability.
Better user experience.

Interview Tip: In production systems, media files are typically stored in Amazon S3, served through CloudFront (CDN), and secured using Pre-Signed URLs for private access.

N. Scalability

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Designing for 1 Million Users focuses on building a scalable architecture while keeping the system relatively simple.

A typical architecture includes:

Users

↓

Load Balancer

↓

Multiple Application Servers

↓

Redis Cache

↓

Primary Database

↓

Read Replicas

Key Design Considerations

Stateless application servers.
Load Balancer for traffic distribution.
Redis for caching frequently accessed data.
Read Replicas for read-heavy workloads.
CDN for static content.
Background processing using message queues.
Monitoring and logging.

Example

An online shopping application with 1 million users can scale effectively using multiple application instances, Redis, and database read replicas.

Interview Tip: For 1 million users, focus on horizontal scaling, caching, and database optimization before introducing advanced distributed architectures.

At 100 Million Users, a single database or server is no longer sufficient. The system must be distributed.

Typical Architecture:

Users

↓

CDN

↓

Load Balancer

↓

API Gateway

↓

Microservices

↓

Redis

↓

Kafka

↓

Sharded Databases

↓

Object Storage

Additional Components

Multiple Load Balancers.
CDN for global content delivery.
Microservices architecture.
Kafka for asynchronous communication.
Database Sharding.
Multi-region deployment.
Auto Scaling.
Distributed tracing and monitoring.

Challenges

Database bottlenecks.
Distributed transactions.
Eventual consistency.
Network latency.
Service discovery.

Interview Tip: Interviewers are looking for distributed architecture, not bigger servers. Explain how every layer scales independently.

A Stateless Service does not store client session data in its local memory.

Every request contains all the information required for processing.

Example:

GET /orders

Authorization: Bearer

The server can process the request without relying on previous requests.

Advantages

Easy horizontal scaling.
Better fault tolerance.
Easy load balancing.
No session replication.

Examples

REST APIs.
Spring Boot Microservices.
Kubernetes deployments.

Interview Tip: Stateless services are one of the fundamental principles of cloud-native applications.

Session Management stores user-specific information across multiple requests.

Common Approaches:

1. In-Memory Session

Stored inside the application server.

Problem

Fails when requests reach another server.

2. Sticky Sessions

The Load Balancer always routes the user to the same server.

Problem

Poor scalability and fault tolerance.

3. Distributed Session Store

Store sessions in Redis.

Application

↓

Redis Session Store

4. JWT (Preferred)

Store session information inside JWT.

No server-side session storage required.

Interview Tip: Modern microservices usually prefer JWT-based stateless authentication over server-side sessions.

Horizontal Scaling means increasing system capacity by adding more servers instead of upgrading existing hardware.

Example:

Before

1 Server

↓

After

Load Balancer

↓

Server 1

Server 2

Server 3

Advantages

Better availability.
Improved scalability.
Fault tolerance.
Easy cloud deployment.

Disadvantages

Distributed data management.
More operational complexity.

Interview Tip: Most cloud-native applications are designed for horizontal scaling because it provides better scalability and resilience than vertical scaling.

Auto Scaling automatically adjusts the number of application instances based on workload.

Example:

High Traffic

↓

Auto Scaling

↓

2 Instances

↓

8 Instances

↓

Traffic Drops

↓

2 Instances

Scaling decisions are usually based on:

CPU Utilization.
Memory Usage.
Request Count.
Queue Length.
Response Time.

Advantages

Cost optimization.
Handles traffic spikes.
Improves availability.
Reduces manual intervention.

Examples

AWS Auto Scaling.
Kubernetes Horizontal Pod Autoscaler (HPA).

Interview Tip: Auto Scaling is effective only when applications are stateless.

Queue-Based Architecture uses a Message Queue to decouple producers from consumers.

Instead of processing everything synchronously, requests are queued for asynchronous processing.

Example:

Order Service

↓

Kafka / RabbitMQ

↓

Inventory Service

↓

Notification Service

Advantages

Loose coupling.
Better scalability.
Handles traffic spikes.
Improved reliability.

Use Cases

Email notifications.
Payment processing.
Image processing.
Order processing.

Interview Tip: Queues help absorb sudden traffic spikes without overwhelming downstream services.

Backpressure is a mechanism that prevents producers from sending data faster than consumers can process it.

Without Backpressure:

Producer

↓↓↓↓↓↓↓↓

Consumer

(Overloaded)

With Backpressure:

Producer

↓

Controlled Rate

↓

Consumer

Techniques

Slow down producers.
Limit queue size.
Reject excess requests.
Apply rate limiting.

Advantages

Prevents system overload.
Improves stability.
Avoids OutOfMemory errors.

Interview Tip: Kafka, Reactive Streams, and Project Reactor support backpressure mechanisms to prevent consumer overload.

Bulk Processing processes multiple records together in a single operation instead of handling one record at a time.

Example:

Instead of:

Insert 1 Record

↓

Insert 1 Record

↓

Insert 1 Record

Use:

Insert 10,000 Records Together

Advantages

Higher throughput.
Reduced database calls.
Better performance.
Lower network overhead.

Examples

Bulk database inserts.
Bulk email sending.
Bulk file imports.

Interview Tip: Bulk Processing improves performance by reducing the overhead of repeated operations.

Batch Processing executes a group of jobs at scheduled intervals instead of processing them immediately.

Example:

Transactions

↓

Stored Throughout the Day

↓

Night Batch Job

↓

Generate Reports

Examples

Payroll processing.
Bank statement generation.
Invoice generation.
Data warehouse ETL jobs.

Advantages

Efficient resource utilization.
Suitable for large datasets.
Can run during off-peak hours.

Interview Tip: Batch Processing is suitable when real-time processing is not required.

Asynchronous Processing allows a client request to return immediately while the actual work is performed in the background.

Example:

User uploads a video.

Instead of waiting for video processing:

Upload Video

↓

Return Success Response

↓

Kafka Queue

↓

Video Processing

↓

Notification Sent

Advantages

Faster API responses.
Better user experience.
Improved scalability.
Non-blocking operations.

Common Technologies

Kafka.
RabbitMQ.
Spring Boot @Async.
CompletableFuture.
Message Queues.

Interview Tip: In production systems, long-running tasks such as email sending, report generation, payment reconciliation, and media processing should be handled asynchronously rather than blocking the user’s request.

O. Design Patterns in Distributed Systems

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

The Circuit Breaker Pattern prevents repeated calls to a failing service, avoiding cascading failures across the system.

Instead of continuously sending requests to an unhealthy service, the Circuit Breaker temporarily blocks requests until the service recovers.

Circuit Breaker States

Closed

Requests flow normally.
Failures are monitored.

Open

Requests are blocked immediately.
Fast failure response.

Half-Open

Limited requests are allowed.
If successful, the circuit closes.
Otherwise, it opens again.

Service Failure

↓

Circuit Opens

↓

Requests Blocked

↓

Recovery Test

↓

Circuit Closes

Advantages

Prevents cascading failures.
Improves system stability.
Faster failure detection.
Better user experience.

Examples

Resilience4j
Hystrix (Deprecated)

Interview Tip: Circuit Breaker protects the caller from repeatedly invoking a failing service.

The Retry Pattern automatically retries failed requests before declaring them as failures.

It is useful for handling temporary issues such as network timeouts or brief service outages.

Example:

Request

↓

Failure

↓

Retry 1

↓

Retry 2

↓

Success

Best Practices

Use exponential backoff.
Add random jitter.
Limit retry attempts.
Retry only transient failures.

Advantages

Improves reliability.
Handles temporary failures.
Reduces manual intervention.

Interview Tip: Retry should be combined with a Circuit Breaker. Retrying a permanently failing service can make the situation worse.

The Bulkhead Pattern isolates system resources so that failure in one component does not affect other components.

Different services use separate thread pools, connection pools, or resource limits.

Example:

Thread Pool A

↓

Payment Service

Thread Pool B

↓

Notification Service

If the Payment Service becomes overloaded, the Notification Service continues working normally.

Advantages

Fault isolation.
Prevents resource exhaustion.
Improves application stability.

Interview Tip: Bulkhead limits the impact of failures by isolating resources between services.

The Sidecar Pattern deploys a helper container alongside the main application container.

The Sidecar handles infrastructure concerns without changing application code.

Responsibilities:

Logging.
Monitoring.
Security.
Service Discovery.
Proxying.

Pod

├── Application Container

└── Sidecar Container

Examples

Envoy Proxy.
Fluentd.

Advantages

Separation of concerns.
Reusable infrastructure.
Easier maintenance.

Interview Tip: Service Mesh implementations such as Istio use Sidecar proxies extensively.

The Ambassador Pattern places a proxy container between the application and external services.

Instead of the application communicating directly with external systems, all communication goes through the Ambassador.

Application

↓

Ambassador Proxy

↓

External Service

Responsibilities:

Load balancing.
Retry.
Circuit Breaking.
TLS termination.
Service discovery.

Advantages

Simplifies application code.
Centralizes communication logic.
Improves resilience.

Interview Tip: Unlike the Sidecar Pattern, which provides general infrastructure support, the Ambassador Pattern focuses specifically on outbound communication with external services.

CQRS separates operations into two models:

Command Model → Handles Create, Update, Delete.
Query Model → Handles Read operations.

Commands

↓

Write Database

Queries

↓

Read Database

Advantages

Independent scaling.
Faster reads.
Better performance.
Optimized data models.

Disadvantages

Increased complexity.
Eventual consistency.

Use Cases

Banking.
E-commerce.
Event-driven systems.

Interview Tip: CQRS is most beneficial when read traffic is much higher than write traffic.

Event Sourcing stores every change as an immutable event instead of storing only the latest state.

Example:

Instead of storing:

Balance = ₹10,000

Store events:

Account Created

↓

₹5,000 Deposited

↓

₹2,000 Withdrawn

↓

₹7,000 Deposited

The current state is reconstructed by replaying all events.

Advantages

Complete audit history.
Easy debugging.
Event replay.
Supports CQRS.

Disadvantages

Complex implementation.
Increased storage.

Interview Tip: Event Sourcing is commonly combined with CQRS and Kafka in event-driven architectures.

Saga Pattern manages distributed transactions by breaking a large transaction into multiple local transactions.

If one step fails, Compensation Transactions undo the completed steps.

Example:

Create Order

↓

Reserve Inventory

↓

Process Payment

↓

Send Notification

If Payment fails:

Release Inventory

↓

Cancel Order

Advantages

High scalability.
No distributed locks.
Better fault tolerance.

Disadvantages

Compensation logic required.
More complex workflows.

Interview Tip: Saga is the preferred alternative to Two-Phase Commit (2PC) in microservices.

Application

↓

Business Table

+

Outbox Table

↓

Commit

↓

Kafka Publisher

Advantages

Reliable event publishing.
Prevents lost messages.
Maintains consistency.

Interview Tip: Outbox Pattern is widely used with Kafka and Debezium in production microservices.

The Strangler Pattern is a migration strategy used to gradually replace a monolithic application with microservices.

Instead of rewriting the entire application, new functionality is developed as microservices while existing features continue running in the monolith.

Client

↓

API Gateway

├── Monolith

└── New Microservice

Over time, more functionality is moved until the monolith is completely removed.

Advantages

Low migration risk.
Incremental modernization.
Minimal downtime.
Easier rollback.

Interview Tip: The Strangler Pattern is the safest approach for migrating large legacy systems to microservices.

Leader Election is a distributed system pattern where one node is elected as the leader to coordinate shared tasks.

Only the leader performs critical operations such as scheduling or coordination.

Example:

Node A (Leader)

Node B (Follower)

Node C (Follower)

If the leader fails, another node is elected automatically.

Advantages

Prevents duplicate execution.
Ensures coordination.
Improves consistency.

Examples

Apache ZooKeeper.
etcd.
Kubernetes Control Plane.
Apache Kafka Controller.

Interview Tip: Leader Election prevents multiple nodes from performing the same critical task simultaneously.

Consistent Hashing distributes data evenly across multiple servers while minimizing data movement when servers are added or removed.

Unlike traditional hashing, only a small portion of data is redistributed during scaling.

Example:

Hash Ring

↓

Server A

↓

Server B

↓

Server C

If a new server is added, only nearby keys are reassigned instead of rehashing the entire dataset.

Advantages

Minimal data movement.
Better load distribution.
Easy horizontal scaling.
High availability.

Use Cases

Redis Cluster.
Cassandra.
DynamoDB.
Distributed Caches.

Interview Tip: Consistent Hashing is widely used in distributed databases and caching systems because it scales efficiently without requiring complete data redistribution.

P. Frequently Asked System Design Problems

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

Q. Production Scenario Questions

Interview questions

Expand a question to read the answer. Tick when you’re prepared (progress saved on this device).

To support 1 million concurrent users, every layer of the architecture must scale independently.

Architecture

CDN

↓

Load Balancer

↓

Stateless Application Servers

↓

Redis Cache

↓

Kafka

↓

Sharded Database

↓

Object Storage

Scaling Techniques

Stateless services.
Horizontal Scaling.
Auto Scaling.
Redis Caching.
Read Replicas.
Database Sharding.
CDN.
Asynchronous Processing.
Queue-based architecture.

Interview Tip: Don’t answer “buy a bigger server.” Explain how the application, cache, database, and messaging layers scale independently.

Duplicate payments can occur due to retries, network failures, or users clicking the payment button multiple times.

Solutions

Idempotency Key.
Unique Transaction ID.
Database Unique Constraint.
Distributed Lock.
Payment Status Check.
Retry only for safe operations.

Example:

Client

↓

Idempotency Key

↓

Payment Service

↓

Already Processed?

↓

Return Existing Response

Interview Tip: Every payment API should support Idempotency Keys.

Notifications should never block the main business flow.

Architecture

Application

↓

Kafka

↓

Notification Service

↓

Email / SMS / Push

Features

Retry Queue.
Dead Letter Queue.
Multiple Notification Channels.
Idempotent Consumers.
Monitoring.

Interview Tip: Notification systems should be asynchronous and resilient to temporary failures.

In distributed systems, all application instances must share rate limit information.

Implementation

Redis Distributed Counter.
Token Bucket Algorithm.
Sliding Window.
API Gateway Integration.

Example:

Client

↓

API Gateway

↓

Redis Counter

↓

Allow / Reject

Interview Tip: Redis is commonly used because of its atomic operations and high performance.

A resilient order pipeline should continue processing even when individual services fail.

Architecture

Client

↓

Order Service

↓

Kafka

↓

Inventory Service

↓

Payment Service

↓

Shipping Service

↓

Notification Service

Design Patterns Used

Saga Pattern.
Outbox Pattern.
Retry Pattern.
Dead Letter Queue.
Circuit Breaker.
Idempotent Consumers.
Monitoring and Alerts.

Failure Handling

Retry temporary failures.
Execute compensation transactions for business failures.
Send permanently failed messages to the Dead Letter Queue (DLQ).

Interview Tip: A production-grade order processing pipeline is typically event-driven, uses Kafka for reliable asynchronous communication, Saga for distributed transactions, Outbox for reliable event publishing, and Circuit Breakers to isolate downstream failures.”,”role”,”assistant

System design Interview Preparation

A. System Design Fundamentals

B. Load Balancing

C. Caching

D. Database Design

E. Database Scaling

F. Messaging Systems

G. Microservices Design

H. Distributed Transactions

I. API Design

J. Security

K. High Availability

L. Logging & Monitoring

M. CDN & Storage

N. Scalability

O. Design Patterns in Distributed Systems

P. Frequently Asked System Design Problems

Q. Production Scenario Questions

Create your account

Reset password

Choose a new password