Backend First Principles - Complete Interview Preparation Guide

Join Our Community for Updates

Stay up-to-date with the latest news, discussions, and updates! Join our WhatsApp group to connect with the community.

Introduction

This comprehensive guide is designed to help you understand backend engineering from first principles. Rather than memorizing code, we'll focus on understanding why things work the way they do. This approach will help you confidently answer any backend interview question by building from fundamental concepts.

What is Backend Development?
Client-Server Architecture
HTTP Protocol Deep Dive
REST API Principles
Database Fundamentals
Authentication & Authorization
Caching Strategies
Message Queues & Async Processing
System Design Fundamentals
Scaling Principles
Security Best Practices
Common Interview Questions

What is Backend Development?

First Principles Understanding

Q: What is backend development at its core?

Answer from First Principles:

Backend development is about managing data, business logic, and resources that the client (frontend) needs but shouldn't handle directly. Think of it as the "brain" of your application.

Why do we need a backend?

Security: Sensitive operations (payment processing, user authentication) shouldn't happen on the client (which users can manipulate)
Centralized Data: Multiple clients need to access the same data
Business Logic: Complex computations that are too heavy for client devices
Resource Management: Handling connections to databases, external APIs, file systems

Interview Question: "Why can't we just use frontend for everything?"

Comprehensive Answer:

Security: Frontend code is visible to users. They can modify it, bypass validations, or steal sensitive keys
Performance: Mobile devices have limited processing power
Consistency: Business logic in one place ensures all clients behave the same way
Data Persistence: We need a central place to store and manage data
Scalability: Backend can be scaled independently based on load

Client-Server Architecture

First Principles Understanding

Q: How does client-server communication work?

Answer from First Principles:

Think of it like a restaurant:

Client (Customer): Requests food (data)
Server (Waiter): Takes the request, communicates with the kitchen
Backend/Database (Kitchen): Prepares the food (processes and retrieves data)

The Request-Response Cycle:

Client sends a REQUEST (HTTP request)
Server RECEIVES the request
Server PROCESSES (validates, checks permissions, queries database)
Server RESPONDS with data or error
Client RENDERS the response

Interview Questions on Client-Server

Q: What happens when you type a URL in a browser and press Enter?

Detailed Answer:

DNS Lookup: Browser asks DNS servers "What's the IP address of this domain?"
TCP Connection: Browser establishes a TCP connection with the server (3-way handshake)
HTTP Request: Browser sends GET request with headers
Server Processing: Server receives, processes the request
Server Response: Server sends back HTML/JSON with status code
Rendering: Browser parses and renders the content
Additional Requests: Browser makes more requests for CSS, JS, images

Q: What is the difference between TCP and UDP?

First Principles Answer:

TCP (Transmission Control Protocol):

Like registered mail - guarantees delivery
Establishes connection before sending data (handshake)
Ensures packets arrive in order
Resends lost packets
Use when: Accuracy matters (HTTP, file transfers, emails)

UDP (User Datagram Protocol):

Like dropping a letter in a mailbox - best effort
No connection establishment
Doesn't guarantee delivery or order
Faster because no overhead
Use when: Speed matters more than accuracy (live streaming, gaming, DNS)

HTTP Protocol Deep Dive

First Principles Understanding

Q: What is HTTP?

Answer from First Principles:

HTTP (Hypertext Transfer Protocol) is a contract between client and server about how they'll talk to each other. It's a set of rules.

Key Concepts:

HTTP Methods (Verbs)

Q: Why do we have different HTTP methods?

Answer:

Each method has a semantic meaning - it tells the server what kind of operation you want:

GET: "Give me this resource" (Read)
- Idempotent: Calling it multiple times has the same effect
- No body (data in URL)
- Cacheable
POST: "Create a new resource" (Create)
- Not idempotent: Calling 5 times creates 5 resources
- Data in body
- Not cacheable
PUT: "Replace this entire resource" (Update/Replace)
- Idempotent: Replacing 5 times = same as replacing once
- Sends complete resource
PATCH: "Partially update this resource" (Partial Update)
- Only sends changed fields
- More efficient than PUT
DELETE: "Remove this resource" (Delete)
- Idempotent: Deleting 5 times = same as deleting once

HTTP Status Codes

Q: Why do we need status codes? Why not just send success/failure?

First Principles Answer:

Status codes give context about what happened. They help clients make intelligent decisions.

Categories (First Digit Matters):

1xx - Informational: "I'm working on it"

100 Continue: Keep sending data

2xx - Success: "It worked!"

200 OK: Request succeeded
201 Created: New resource created
204 No Content: Success but no data to return

3xx - Redirection: "Look somewhere else"

301 Moved Permanently: Resource moved forever (update bookmarks)
302 Found: Temporary redirect
304 Not Modified: Use cached version

4xx - Client Errors: "You messed up"

400 Bad Request: Your request is malformed
401 Unauthorized: You need to authenticate
403 Forbidden: I know who you are, but you don't have permission
404 Not Found: This resource doesn't exist
429 Too Many Requests: You're rate limited

5xx - Server Errors: "I messed up"

500 Internal Server Error: Something broke on my end
502 Bad Gateway: The server I called had an error
503 Service Unavailable: I'm overloaded or down for maintenance

Interview Question: "What's the difference between 401 and 403?"

Answer:

401 Unauthorized: "I don't know who you are. Please authenticate (login)."
- Response: Send credentials
403 Forbidden: "I know who you are, but you don't have permission to access this."
- Response: Even with credentials, you can't access this

HTTP Headers

Q: What are headers and why do we need them?

Answer from First Principles:

Headers are metadata about the request/response. They're like the envelope of a letter - they contain information about the letter itself.

Common Headers and Their Purpose:

Request Headers:

Content-Type: application/json  // What format is my data in?
Authorization: Bearer token123   // Here's proof I'm authenticated
Accept: application/json         // What formats can I handle?
User-Agent: Mozilla/5.0         // What browser/client am I?
Cookie: session=abc123          // Here's my session data

Response Headers:

Content-Type: application/json   // Format of my response
Cache-Control: max-age=3600     // You can cache this for 1 hour
Set-Cookie: session=xyz789      // Save this cookie
Access-Control-Allow-Origin: *  // CORS: Who can call this API

REST API Principles

First Principles Understanding

Q: What is REST?

Answer from First Principles:

REST (Representational State Transfer) is an architectural style - a set of principles for designing APIs. It's not a protocol or standard.

Core Principles:

1. Resource-Based

Everything is a resource (noun), identified by a URI.

Good REST Design:

GET    /users           // Get all users
GET    /users/123       // Get user 123
POST   /users           // Create a user
PUT    /users/123       // Update user 123
DELETE /users/123       // Delete user 123

Bad Design (Not RESTful):

GET    /getAllUsers
POST   /createUser
POST   /updateUser
POST   /deleteUser

Why is the good design better?

Uses HTTP methods for their intended purpose
URLs represent resources, not actions
Consistent and predictable

2. Stateless

Q: What does stateless mean?

Answer:

Each request must contain all information needed to process it. The server doesn't remember previous requests.

Why?

Scalability: Any server can handle any request (no "sticky sessions")
Reliability: If a server crashes, nothing is lost
Simplicity: Each request is independent

How do we maintain user sessions then?

Use tokens (JWT) sent with each request
Server validates token but doesn't store session state

3. Cacheable

Q: Why is caching important in REST?

Answer:

Caching reduces:

Server load
Network traffic
Response time

Implementation:

GET requests should be cacheable
Use proper Cache-Control headers
Use ETags for conditional requests

4. Uniform Interface

Q: What does uniform interface mean?

Answer:

All APIs follow the same conventions:

Standard HTTP methods
Predictable URL structure
Consistent response formats
Self-descriptive messages

Interview Question: "Design a RESTful API for a blog system"

Answer:

Resources: Users, Posts, Comments

User Management:
GET    /users              // List all users
GET    /users/{id}         // Get specific user
POST   /users              // Create user
PUT    /users/{id}         // Update user
DELETE /users/{id}         // Delete user

Posts:
GET    /posts              // List all posts
GET    /posts/{id}         // Get specific post
POST   /posts              // Create post
PUT    /posts/{id}         // Update post
DELETE /posts/{id}         // Delete post

Comments (nested resource):
GET    /posts/{id}/comments       // Get all comments on a post
POST   /posts/{id}/comments       // Add comment to post
PUT    /comments/{id}             // Update a comment
DELETE /comments/{id}             // Delete a comment

Query Parameters for Filtering:
GET /posts?author=123&category=tech&sort=date&limit=10

Key Design Decisions:

Comments are nested under posts (they belong to posts)
Use plural nouns (users, posts, not user, post)
Use IDs in URL path for specific resources
Use query params for filtering, sorting, pagination

Database Fundamentals

First Principles Understanding

Q: What is a database and why do we need it?

Answer from First Principles:

A database is a structured way to store and retrieve data. We need it because:

Persistence: Data survives server restarts
Concurrency: Multiple users can access data simultaneously
Consistency: Data follows rules (constraints)
Querying: Efficient data retrieval

SQL vs NoSQL

Q: When should you use SQL vs NoSQL?

First Principles Answer:

SQL (Relational Databases):

Use when:

Data has clear relationships (users have posts, posts have comments)
You need ACID guarantees (banking, e-commerce)
Schema is stable and well-defined
Complex queries with JOINs are common

Core Concepts:

Tables: Structured data (rows and columns)
Schema: Predefined structure
Relationships: Foreign keys, JOINs
ACID: Atomicity, Consistency, Isolation, Durability

Examples: PostgreSQL, MySQL, SQLite

NoSQL (Non-Relational Databases):

Use when:

Schema is flexible or evolving
Horizontal scaling is needed
Simple queries (key-value lookups)
High write throughput required

Types:

Document Stores (MongoDB): Store JSON-like documents
Key-Value Stores (Redis): Simple key → value mapping
Column Stores (Cassandra): Optimize for write-heavy workloads
Graph Databases (Neo4j): Store relationships efficiently

ACID Properties

Q: Explain ACID properties and why they matter

Answer from First Principles:

A - Atomicity: "All or nothing"

Example: Bank transfer
- Deduct $100 from Account A
- Add $100 to Account B

If step 2 fails, step 1 must be rolled back.
Either BOTH happen or NEITHER happens.

C - Consistency: "Rules are always followed"

Example: Account balance can't be negative
If any transaction would violate this rule, it's rejected.
Database goes from one valid state to another valid state.

I - Isolation: "Transactions don't interfere"

Example: Two people booking the last seat
Transaction 1: Check seat available → Book it
Transaction 2: Check seat available → Book it

Isolation ensures only ONE succeeds.

D - Durability: "Completed transactions survive crashes"

Example: Transfer completed
Even if server crashes immediately after, the transfer is saved.

Interview Question: "Explain a scenario where lack of isolation causes problems"

Answer: The Lost Update Problem

Scenario: Bank account with $1000, two simultaneous withdrawals of $100

Without Isolation:
Time    Transaction 1          Transaction 2
t1      Read balance: $1000    
t2                            Read balance: $1000
t3      Deduct $100 = $900
t4                            Deduct $100 = $900
t5      Write $900
t6                            Write $900

Result: Balance is $900 (should be $800!)
One withdrawal was "lost"

With Isolation (using locks):
Time    Transaction 1          Transaction 2
t1      Lock account
t2      Read balance: $1000    Waiting for lock...
t3      Deduct $100 = $900
t4      Write $900
t5      Release lock
t6                            Acquire lock
t7                            Read balance: $900
t8                            Deduct $100 = $800
t9                            Write $800

Result: Correct balance of $800

Database Indexing

Q: What are indexes and why do we need them?

Answer from First Principles:

An index is like a book's index - it helps you find information quickly without reading the entire book.

Without Index:

Find user with email "john@example.com"
- Must scan EVERY row in the users table
- Time: O(n) - linear time
- Slow for large tables

With Index:

- Database maintains a separate data structure (B-Tree usually)
- Can jump directly to the row
- Time: O(log n) - logarithmic time
- Much faster!

Trade-offs:

Pro: Faster reads
Con: Slower writes (index must be updated)
Con: Takes extra disk space

Interview Question: "Should we index every column?"

Answer:

No! Index only columns you frequently:

Query in WHERE clauses
Use in JOIN conditions
Sort by (ORDER BY)
Use for unique constraints

Don't index:

Columns with low cardinality (e.g., boolean fields)
Columns that change frequently
Tables with few rows

Database Normalization

Q: What is normalization and why does it matter?

Answer from First Principles:

Normalization is organizing data to reduce redundancy. It's about storing each piece of information in only one place.

Example of Non-Normalized Data:

Orders Table:
OrderID | CustomerName | CustomerEmail       | Product   | Price
1       | John Doe     | john@example.com    | Laptop    | 1000
2       | John Doe     | john@example.com    | Mouse     | 25
3       | Jane Smith   | jane@example.com    | Keyboard  | 75

Problems:

Customer info repeated (redundancy)
If John changes email, must update multiple rows
Wastes storage space

Normalized (2 tables):

Customers Table:
CustomerID | Name       | Email
1          | John Doe   | john@example.com
2          | Jane Smith | jane@example.com

Orders Table:
OrderID | CustomerID | Product   | Price
1       | 1          | Laptop    | 1000
2       | 1          | Mouse     | 25
3       | 2          | Keyboard  | 75

Benefits:

Customer info stored once
Updating email is single query
Less storage
Data consistency

Normal Forms (Simple Explanation):

1NF (First Normal Form): Each column has atomic values (no lists) 2NF: 1NF + No partial dependencies 3NF: 2NF + No transitive dependencies

Interview Tip: Most production databases are in 3NF. Going beyond (4NF, 5NF) is rare.

Authentication & Authorization

First Principles Understanding

Q: What's the difference between Authentication and Authorization?

Answer from First Principles:

Authentication: "Who are you?" (Identity verification)

Proving you are who you claim to be
Examples: Login with username/password, biometrics, 2FA

Authorization: "What can you do?" (Permission checking)

What resources/actions you're allowed to access
Examples: Admin can delete posts, regular users cannot

Analogy:

Authentication: Showing your ID to enter an office building
Authorization: Having a keycard that only opens certain doors

Session-Based Authentication

Q: How does session-based authentication work?

Answer from First Principles:

1. User Login:
   Client sends: username + password
   Server validates credentials
   Server creates session in database
   Server returns session ID in cookie

2. Subsequent Requests:
   Client automatically sends cookie with session ID
   Server looks up session in database
   Server knows who the user is

3. Logout:
   Server deletes session from database

Pros:

Simple to implement
Can revoke sessions immediately

Cons:

Server must store all sessions (memory/database)
Doesn't scale well (stateful)
CSRF attacks possible

Token-Based Authentication (JWT)

Q: How does JWT authentication work?

Answer from First Principles:

JWT (JSON Web Token) is a self-contained token that includes user information.

Structure: header.payload.signature

Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "userId": 123, "email": "user@example.com", "exp": 1234567890 }
Signature: HMAC(header + payload, secret)

Flow:

1. User Login:
   Client sends: username + password
   Server validates credentials
   Server creates JWT with user info
   Server signs JWT with secret key
   Server returns JWT to client

2. Subsequent Requests:
   Client sends: JWT in Authorization header
   Server verifies signature
   Server extracts user info from token (no database lookup!)

3. Logout:
   Client deletes token

Pros:

Stateless: Server doesn't store tokens
Scalable: Any server can validate any token
Cross-domain: Works across different domains

Cons:

Can't revoke immediately (token valid until expiry)
Token size (sent with every request)

Interview Question: "How do you handle JWT expiration?"

Answer:

Use two tokens:

Access Token: Short-lived (15 minutes)
- Sent with each API request
- Contains user identity
Refresh Token: Long-lived (7 days)
- Stored securely
- Used to get new access token
- Can be revoked (stored in database)

Flow:

1. Login: Get both tokens
2. API requests: Use access token
3. Access token expires: Use refresh token to get new access token
4. Refresh token expires: User must login again

OAuth 2.0

Q: What is OAuth and when do you use it?

Answer from First Principles:

OAuth is a delegation protocol - it allows apps to access resources on your behalf WITHOUT sharing your password.

Use Case: "Login with Google"

Why not just share your Google password?

Insecure (app has full access to your account)
Can't revoke access without changing password
Password changes break the app

OAuth Flow (Simplified):

1. Your app redirects user to Google
2. User authenticates with Google (enters password there)
3. Google asks: "Allow MyApp to access your profile?"
4. User approves
5. Google gives your app an access token
6. Your app uses token to access user's Google profile
7. User can revoke access anytime from Google settings

Key Benefit: Your app never sees the user's Google password!

Caching Strategies

First Principles Understanding

Q: What is caching and why do we need it?

Answer from First Principles:

Caching is storing frequently accessed data in a faster location to avoid expensive operations.

Analogy:

Database = Library (slow to access)
Cache = Bookshelf in your room (fast access)

Why Cache?

Speed: Memory (RAM) is 1000x faster than disk
Reduce Load: Fewer database queries
Cost: Database operations are expensive

Where to Cache?

1. Client-Side Caching:

Browser caches:
- Static files (CSS, JS, images)
- API responses
- Controlled by Cache-Control headers

2. Server-Side Caching:

- In-memory cache (Redis)
- Application-level cache
- Database query results

3. CDN Caching:

- Caches content geographically closer to users
- Great for static assets

Caching Strategies

Q: Explain different caching strategies

1. Cache-Aside (Lazy Loading):

Read:
1. Check cache
2. If found (cache hit): return cached data
3. If not found (cache miss):
   - Fetch from database
   - Store in cache
   - Return data

Write:
1. Write to database
2. Invalidate cache entry

When to use: Read-heavy workloads

2. Write-Through:

Write:
1. Write to cache
2. Write to database
3. Return success

Read:
1. Always from cache (data always present)

When to use: Data consistency is critical

3. Write-Behind (Write-Back):

Write:
1. Write to cache immediately
2. Asynchronously write to database later
3. Return success

Read:
1. From cache

When to use: Write-heavy workloads, can tolerate small data loss

Interview Question: "What's the problem with caching?"

Answer: Cache Invalidation

"There are only two hard things in Computer Science: cache invalidation and naming things." - Phil Karlton

Problems:

Stale Data: Cache has old data, database has new data
Cache Stampede: Cache expires, many requests hit database simultaneously
Memory Limits: What to remove when cache is full?

Solutions:

For Stale Data:

Set TTL (Time To Live)
Invalidate on updates
Use versioning

For Cache Stampede:

Request coalescing (only one request fetches data)
Probabilistic early expiration

For Memory Limits:

LRU (Least Recently Used) eviction
LFU (Least Frequently Used) eviction

Cache Eviction Policies

Q: How does LRU cache work?

Answer from First Principles:

LRU (Least Recently Used) removes the least recently accessed item when cache is full.

Data Structure: HashMap + Doubly Linked List

HashMap: Quick lookup (O(1))
Doubly Linked List: Track access order

Most recent ← → ... ← → Least recent

When accessing an item:
1. Move it to front (most recent)

When adding new item (cache full):
1. Remove last item (least recent)
2. Add new item to front

Time Complexity: O(1) for get and put operations

Message Queues & Async Processing

First Principles Understanding

Q: What are message queues and why do we need them?

Answer from First Principles:

A message queue is a communication pattern where sender and receiver don't communicate directly.

Without Queue (Synchronous):

User clicks "Send Email" →
  API processes request →
    Sends email (takes 3 seconds) →
      Returns response to user

User waits 3 seconds! 😞

With Queue (Asynchronous):

User clicks "Send Email" →
  API adds job to queue →
    Returns immediately: "Email queued"

Separate worker process:
  Picks up job from queue →
    Sends email →
    Updates status

User waits 100ms! 😊

Benefits:

Decoupling: Sender and receiver don't need to know about each other
Reliability: If receiver is down, messages are stored
Scalability: Add more workers to process faster
Load Leveling: Handle traffic spikes without overwhelming system

Common Use Cases

1. Email/SMS Notifications:

Don't make user wait while email sends
Queue it and process in background

2. Image Processing:

User uploads profile picture
Queue processing job (resize, compress, generate thumbnails)
Return immediately

3. Data Processing:

Generate monthly reports
Process analytics
Export data

4. Order Processing:

Place order → Queue
Worker processes: inventory check, payment, shipping

Popular Message Queue Systems

1. RabbitMQ:

Full-featured message broker
Supports multiple protocols
Complex routing

2. Redis (Pub/Sub or Lists):

Simple queue implementation
Very fast (in-memory)
Limited features

3. Apache Kafka:

High throughput
Distributed log
Good for event streaming

4. AWS SQS:

Managed service
Serverless
Easy to use

Queue Patterns

Q: Explain different messaging patterns

1. Point-to-Point (Queue):

One sender → Queue → One receiver
Each message consumed by exactly one worker
Use: Task distribution

2. Publish-Subscribe (Pub/Sub):

One sender → Topic → Multiple subscribers
Each message received by all subscribers
Use: Event notifications

3. Request-Reply:

Client sends request with reply queue
Server processes and sends response to reply queue
Use: RPC-style communication

Interview Question: "How do you handle failed message processing?"

Answer: Dead Letter Queue (DLQ)

1. Worker tries to process message
2. Processing fails
3. Message is re-queued (with retry count)
4. After N retries, move to Dead Letter Queue
5. Monitor DLQ for issues
6. Manual investigation/reprocessing

Important Considerations:

Idempotency: Same message processed twice shouldn't cause issues
Ordering: Queues may not guarantee order
At-least-once vs. Exactly-once: Delivery guarantees

System Design Fundamentals

First Principles Understanding

Q: What is system design?

Answer from First Principles:

System design is about making trade-offs to build a system that meets requirements under constraints.

It's NOT about:

Finding the "perfect" solution (doesn't exist)
Memorizing architectures

It IS about:

Understanding trade-offs
Asking clarifying questions
Reasoning from principles

CAP Theorem

Q: Explain CAP Theorem

Answer from First Principles:

CAP Theorem states you can only guarantee 2 out of 3 in a distributed system:

C - Consistency: All nodes see the same data at the same time A - Availability: Every request gets a response (success or failure) P - Partition Tolerance: System works despite network failures

Why can't we have all 3?

Scenario: Network partition (nodes can't communicate)

Option 1: Choose Consistency + Partition Tolerance (CP)
- Stop serving requests to avoid inconsistency
- Sacrifice availability
- Example: Banking systems

Option 2: Choose Availability + Partition Tolerance (AP)
- Serve requests even if data might be stale
- Sacrifice consistency
- Example: Social media feeds

Interview Question: "Is CAP theorem still relevant?"

Answer:

It's a useful mental model but reality is more nuanced:

Networks fail rarely in modern datacenters
Most systems tune consistency levels (eventual consistency)
Consider PACELC instead: If Partition, choose A or C; Else, choose Latency or Consistency

Load Balancing

Q: What is load balancing and why do we need it?

Answer from First Principles:

Load balancing distributes incoming requests across multiple servers.

Why?

Single server has limited capacity
Prevents overload
Provides redundancy

Load Balancing Algorithms:

1. Round Robin:

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1 (cycle repeats)

Pros: Simple, fair distribution
Cons: Doesn't consider server load

2. Least Connections:

Send request to server with fewest active connections

Pros: Better for long-lived connections
Cons: More complex

3. Weighted Round Robin:

More powerful servers get more requests

Server 1 (powerful): Weight 3
Server 2: Weight 1

Requests: S1, S1, S1, S2, S1, S1, S1, S2...

4. IP Hash:

Hash client IP to determine server
Same client always goes to same server

Pros: Useful for session persistence
Cons: Uneven distribution

Types of Load Balancers:

L4 (Transport Layer):

Operates on TCP/UDP
Fast (doesn't inspect packets)
Can't make routing decisions based on content

L7 (Application Layer):

Operates on HTTP
Can route based on URL, headers, cookies
Slower but more flexible

Database Replication

Q: How do database replicas work?

Answer from First Principles:

Replication means copying data across multiple database servers.

Primary-Replica (Master-Slave):

                Primary (Master)
                    ↓
        +-----------+----------+
        ↓           ↓          ↓
    Replica 1   Replica 2   Replica 3

Writes → Primary
Reads → Any replica

Benefits:

Read Scaling: Distribute read load across replicas
Backup: If primary fails, promote a replica
Geographic Distribution: Place replicas near users

Replication Types:

1. Synchronous:

Write to primary
Wait for replica to acknowledge
Then return success

Pros: Strong consistency
Cons: Slow (network latency)

2. Asynchronous:

Write to primary
Return success immediately
Replicas update eventually

Pros: Fast
Cons: Replicas might have stale data (replication lag)

Interview Question: "What happens if primary database fails?"

Answer: Failover

1. Detection: Monitoring detects primary is down
2. Promotion: Elect a replica as new primary
3. Reconfiguration: Update application to point to new primary
4. Recovery: Old primary rejoins as replica when fixed

Challenges:
- Split-brain: Two nodes think they're primary
- Data loss: If async replication, some writes might be lost
- Downtime: Typically 30s - 2 minutes for automatic failover

Database Sharding

Q: What is sharding and when do you need it?

Answer from First Principles:

Sharding is horizontally partitioning data across multiple databases.

Why?

Single database has capacity limits
Vertical scaling (bigger server) has limits
Need to scale writes (replicas only help reads)

Example: User Database

Without Sharding:
All users in one database (10 million users)

With Sharding:
Shard 1: Users with ID 1-2.5M
Shard 2: Users with ID 2.5M-5M
Shard 3: Users with ID 5M-7.5M
Shard 4: Users with ID 7.5M-10M

Sharding Strategies:

1. Range-Based:

User ID 1-1000 → Shard 1
User ID 1001-2000 → Shard 2

Pros: Simple
Cons: Uneven distribution (hotspots)

2. Hash-Based:

Shard = hash(userId) % num_shards

Pros: Even distribution
Cons: Can't easily query ranges

3. Geographic:

US users → Shard 1 (US datacenter)
EU users → Shard 2 (EU datacenter)

Pros: Low latency
Cons: Uneven distribution

Challenges:

1. Joins Across Shards:

User in Shard 1, their posts in Shard 2
Can't do SQL JOIN!
Must query both and join in application code

2. Resharding:

Need more shards?
Must redistribute data (expensive!)
Use consistent hashing to minimize movement

3. Hotspots:

Celebrity user gets 1M followers
Their shard gets overloaded
Solution: Further partition hot keys

Scaling Principles

First Principles Understanding

Q: What does scaling mean?

Answer from First Principles:

Scaling is increasing capacity to handle more load. "Load" can mean:

More users
More requests
More data
More computations

Vertical vs Horizontal Scaling

Vertical Scaling (Scale Up):

Make your server more powerful
- Add more RAM
- Add more CPUs
- Faster disks

Pros:
+ Simple (no code changes)
+ No distributed system complexity

Cons:
- Limited by hardware
- Single point of failure
- Downtime during upgrades
- Expensive at high end

Horizontal Scaling (Scale Out):

Add more servers
Go from 1 server to 10 servers

Pros:
+ Unlimited scaling (add more servers)
+ Better fault tolerance (one server fails, others continue)
+ Cost-effective (use commodity hardware)

Cons:
- Complex (distributed system problems)
- Code must be designed for it
- Data consistency challenges

Interview Question: "When do you scale vertically vs horizontally?"

Answer:

Scale Vertically When:

Getting started (simplicity matters)
Application isn't designed for distribution
Working with legacy code
Database that's hard to shard

Scale Horizontally When:

Need to scale beyond one machine
Want fault tolerance
Have unpredictable traffic spikes
Building for long-term growth

Ideal Approach: Start vertical, plan for horizontal

Identifying Bottlenecks

Q: How do you identify bottlenecks in a system?

Answer from First Principles:

A bottleneck is the slowest component that limits overall performance.

Common Bottlenecks:

1. CPU Bound:

Symptoms:
- High CPU usage (90%+)
- Request processing time increases

Causes:
- Complex computations
- Encryption/hashing
- Image processing

Solutions:
- Optimize algorithms
- Cache results
- Offload to workers
- Horizontal scaling

2. Memory Bound:

Symptoms:
- High memory usage
- Swapping (using disk as memory)
- Out of memory errors

Causes:
- Large in-memory datasets
- Memory leaks
- Too many cached items

Solutions:
- Use pagination
- Implement better caching strategy
- Fix memory leaks
- Upgrade RAM

3. I/O Bound:

Symptoms:
- Low CPU usage but slow responses
- High disk I/O
- Database query times high

Causes:
- Disk reads/writes
- Database queries
- Network calls

Solutions:
- Add indexes
- Use caching
- Optimize queries
- Use SSD instead of HDD

4. Network Bound:

Symptoms:
- High latency
- Network saturation

Causes:
- Large payloads
- Many external API calls
- Chatty protocols

Solutions:
- Compress data
- Reduce payload size
- Batch requests
- Use CDN

Performance Optimization

Q: How do you optimize backend performance?

Answer: A Systematic Approach:

1. Measure First

"Premature optimization is the root of all evil"

Tools:
- APM (Application Performance Monitoring)
- Profilers
- Database query logs
- Metrics (response time, throughput)

2. Optimize in Order of Impact

Database Optimization:

- Add indexes (biggest impact)
- Optimize queries (EXPLAIN to find slow queries)
- Use connection pooling
- Denormalize if needed
- Add read replicas

Application Optimization:

- Add caching
- Use async processing for slow operations
- Optimize N+1 queries
- Reduce payload size

Infrastructure Optimization:

- Use CDN for static assets
- Enable compression (gzip)
- Horizontal scaling
- Load balancing

Interview Question: "Your API suddenly became slow. How do you debug?"

Answer: Systematic Debugging

1. Gather Information:
   - When did it start?
   - Affects all endpoints or specific ones?
   - Error rates changed?
   
2. Check Metrics:
   - CPU, Memory, Disk, Network usage
   - Database connections
   - Response times
   
3. Check Recent Changes:
   - New deployments?
   - Configuration changes?
   - Traffic increase?
   
4. Drill Down:
   - Slow database queries?
   - External API timeouts?
   - Application-level bottleneck?
   
5. Form Hypothesis and Test:
   - Example: "Database query missing index"
   - Test: Add index to staging, measure impact
   
6. Implement Fix:
   - Deploy fix
   - Monitor metrics
   - Document learnings

Security Best Practices

First Principles Understanding

Q: What is security in backend development?

Answer from First Principles:

Security is about protecting systems from misuse. It's about:

Confidentiality: Keeping sensitive data secret
Integrity: Preventing unauthorized modifications
Availability: Keeping systems accessible to legitimate users

Common Vulnerabilities

Q: What are common backend security vulnerabilities?

1. SQL Injection

How it Works:

Bad Code:
query = "SELECT * FROM users WHERE username = '" + userInput + "'"

Attack:
userInput = "admin' OR '1'='1"

Result:
query = "SELECT * FROM users WHERE username = 'admin' OR '1'='1'"
Returns all users!

Fix: Use Parameterized Queries

Good Code:
query = "SELECT * FROM users WHERE username = ?"
execute(query, [userInput])

Database treats userInput as DATA, not CODE

2. Cross-Site Scripting (XSS)

How it Works:

User submits comment:
"<script>alert('Hacked!')</script>"

If website displays it without sanitizing:
Script executes in other users' browsers!

Can steal cookies, redirect to phishing sites, etc.

Fix: Sanitize Output

- Escape HTML characters
- Use Content Security Policy headers
- Validate and sanitize input

3. Cross-Site Request Forgery (CSRF)

How it Works:

User logged into bank.com
Attacker sends email with:
<img src="https://bank.com/transfer?to=attacker&amount=1000">

When user opens email:
Browser sends request with user's cookies
Transfer executes without user intent!

Fix: CSRF Tokens

1. Server generates random token
2. Token embedded in forms
3. Server validates token on submission
4. Attacker can't guess token

4. Authentication Bypass

Common Mistakes:

Bad: Checking auth only in frontend
Bad: Using predictable session IDs
Bad: Not validating tokens properly
Bad: Storing passwords in plain text

Fixes:

- Always validate auth on server
- Use cryptographically secure random tokens
- Hash passwords with bcrypt/argon2
- Implement rate limiting
- Use multi-factor authentication

5. Insufficient Authorization

How it Works:

GET /api/users/123/profile

User 456 shouldn't access user 123's profile
But if we only check authentication (logged in)
and not authorization (allowed to access this resource)
→ Insecure Direct Object Reference (IDOR)

Fix:

// Check both authentication AND authorization
if (!isAuthenticated()) {
  return 401; // Unauthorized
}

if (requestedUserId !== loggedInUserId && !isAdmin()) {
  return 403; // Forbidden
}

Security Best Practices

Q: What are essential security practices?

1. Input Validation

Principles:
- Never trust user input
- Validate type, format, range
- Whitelist (allow known good) > Blacklist (block known bad)
- Validate on server (client validation can be bypassed)

Example:
Email: Must match email regex
Age: Must be integer between 0-150
File upload: Check file type, size, content

2. Password Security

DO:
- Hash with bcrypt/argon2 (NOT MD5/SHA1)
- Use salt (prevents rainbow table attacks)
- Enforce minimum length (12+ characters)
- Support long passwords (64+ characters)

DON'T:
- Store plain text
- Use weak hashing
- Limit password length unnecessarily
- Show which field is wrong (username vs password)

3. Rate Limiting

Why:
- Prevent brute force attacks
- Prevent DoS attacks
- Limit API abuse

Implementation:
- Per IP address
- Per user account
- Per API key

Example:
- Login: 5 attempts per 15 minutes
- API: 100 requests per minute
- Password reset: 3 attempts per hour

4. HTTPS Everywhere

Why:
- Encrypts data in transit
- Prevents man-in-the-middle attacks
- Protects cookies/tokens

How:
- Use TLS 1.2 or higher
- Get certificate (Let's Encrypt is free)
- Redirect HTTP to HTTPS
- Use HSTS header (forces HTTPS)

5. Principle of Least Privilege

Give minimum permissions necessary:

Database user:
- Application: Read/write only to its tables
- Admin: Full access
- Backup: Read-only access

User roles:
- Regular user: Own data only
- Moderator: Delete posts
- Admin: All permissions

Interview Question: "How do you store sensitive configuration (API keys, database passwords)?"

Answer:

DON'T:

❌ Hardcode in source code
❌ Commit to git
❌ Store in plain text files

DO:

✅ Use environment variables
✅ Use secrets management (AWS Secrets Manager, HashiCorp Vault)
✅ Encrypt at rest
✅ Rotate regularly
✅ Different credentials for dev/staging/production

Example:

Development: .env file (git-ignored)
Production: Cloud secrets manager
CI/CD: Encrypted secrets in pipeline

Common Interview Questions

System Design Questions

Q1: Design a URL Shortener (like bit.ly)

Approach:

1. Requirements Clarification:

Functional:
- Given long URL, generate short URL
- Short URL redirects to long URL
- Custom aliases (optional)
- Analytics (click count)

Non-Functional:
- High availability
- Low latency
- Scalable (1B URLs)

2. Back-of-Envelope Calculations:

Assumptions:
- 100M URLs shortened per month
- Read:Write ratio = 100:1 (more redirects than creates)

Storage:
- Each URL: ~200 bytes (long URL + short URL + metadata)
- 1B URLs × 200 bytes = 200 GB (manageable)

Requests:
- Writes: 100M/month ≈ 40/second
- Reads: 4000/second

3. API Design:

POST /shorten
Body: { "longUrl": "https://example.com/very/long/path" }
Response: { "shortUrl": "https://short.ly/abc123" }

GET /:shortCode
Response: 301 Redirect to long URL

4. Database Design:

Table: urls
- id (primary key)
- short_code (indexed, unique)
- long_url
- created_at
- user_id (optional)
- click_count

Index on short_code for fast lookups

5. URL Generation Strategy:

Option 1: Hash
- Hash long URL with MD5/SHA256
- Take first 7 characters
- Problem: Collisions

Option 2: Base62 Encoding
- Generate unique ID (auto-increment or distributed ID generator)
- Encode ID in base62 [a-zA-Z0-9]
- ID 125 → short code "cb"
- No collisions!

We'll use Option 2

6. High-Level Architecture:

Client → Load Balancer → Web Servers → Cache (Redis) → Database

Write Flow:
1. Receive long URL
2. Generate unique ID
3. Encode to base62
4. Store in database
5. Return short URL

Read Flow:
1. Receive short code
2. Check cache
3. If not in cache, query database
4. Update cache
5. Redirect to long URL

7. Scaling Considerations:

- Cache frequently accessed URLs (Redis)
- Replicate database for read scaling
- Use CDN for geographic distribution
- Partition database by range of IDs (sharding)
- Generate IDs using distributed ID generator (Snowflake)

Q2: Design a Rate Limiter

Approach:

1. Requirements:

Functional:
- Limit requests per user/IP
- Different limits for different endpoints
- Return clear error when limited

Non-Functional:
- Low latency (shouldn't slow down requests)
- Distributed (works across multiple servers)
- Accurate

2. Algorithms:

Token Bucket:

Concept:
- Bucket holds tokens
- Each request consumes token
- Tokens refill at fixed rate

Example:
- Capacity: 10 tokens
- Refill rate: 1 token/second

Time    Tokens   Action
0       10       Request (9 left)
1       10       Refilled to 10, request (9 left)
2       10       Refilled to 10
5       10       3 requests (7 left)

Allows bursts up to bucket capacity

Sliding Window Log:

Store timestamp of each request
Count requests in last N seconds

Accurate but memory-intensive

Fixed Window Counter:

Count requests per fixed time window

Window: 0-59 seconds
If limit is 100:
- Request at 0:59 (request #100)
- Request at 1:00 (request #1, new window)

Problem: Burst at window boundary

Sliding Window Counter (Best):

Combines fixed window + sliding window
Weighted count from previous and current window
More accurate, less memory than log

3. Implementation:

Storage: Redis

Why Redis?
- Fast (in-memory)
- Supports atomic operations
- TTL for auto-cleanup
- Distributed (all servers see same data)

Data Structure:
Key: "rate_limit:user123"
Value: Count
TTL: Window duration

Pseudocode:

function allowRequest(userId):
  key = "rate_limit:" + userId
  current = redis.get(key)
  
  if current == null:
    redis.setex(key, 3600, 1)  // 1 request in 1 hour window
    return true
  
  if current >= limit:
    return false  // Rate limited
  
  redis.incr(key)
  return true

4. Response:

When rate limited:

HTTP 429 Too Many Requests
Headers:
  X-RateLimit-Limit: 100
  X-RateLimit-Remaining: 0
  X-RateLimit-Reset: 1234567890 (timestamp)
  Retry-After: 60 (seconds)

Body:
{
  "error": "Rate limit exceeded",
  "retryAfter": 60
}

Conceptual Questions

Q3: Explain how a web request works end-to-end

Answer:

1. User enters URL in browser: https://example.com/api/users

2. DNS Resolution:
   Browser: "What's the IP of example.com?"
   DNS: "It's 93.184.216.34"
   (Cached locally for future requests)

3. TCP Connection:
   - Browser initiates 3-way handshake with server
   - SYN → SYN-ACK → ACK
   - Connection established

4. TLS Handshake (if HTTPS):
   - Browser and server exchange certificates
   - Agree on encryption algorithm
   - Establish encrypted connection

5. HTTP Request:
   Browser sends:
   GET /api/users HTTP/1.1
   Host: example.com
   User-Agent: Mozilla/5.0
   Accept: application/json
   Cookie: session=abc123

6. Server Receives Request:
   - Load balancer receives request
   - Forwards to available web server

7. Web Server Processing:
   - Parse request
   - Check authentication (validate session cookie)
   - Check authorization (user allowed to access?)
   - Route to appropriate controller

8. Application Logic:
   - Controller receives request
   - Validates input
   - Checks cache (Redis)
   - If not cached, queries database
   - Business logic processing
   - Format response

9. Database Query:
   SELECT * FROM users LIMIT 10;
   - Query optimizer creates execution plan
   - Uses indexes if available
   - Returns results

10. Response Preparation:
    - Serialize data to JSON
    - Set headers (Content-Type, Cache-Control)
    - Update cache
    - Add security headers

11. HTTP Response:
    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: max-age=300
    
    [{"id": 1, "name": "John"}, ...]

12. Browser Receives Response:
    - Parse JSON
    - JavaScript processes data
    - Updates DOM
    - Renders to user

Total time: 50-500ms depending on:
- Geographic distance
- Server load
- Database query complexity
- Network speed

Q4: How would you debug a production issue where some users report slow response times but others don't?

Answer:

Systematic Approach:

1. Gather Information:

Questions to ask:
- Which users are affected? (geographic region, ISP, device?)
- Which endpoints are slow?
- When did it start?
- Is it consistent or intermittent?
- What's "slow"? (1s vs 10s)

2. Check Monitoring:

Look at:
- APM tools (New Relic, DataDog)
- Server metrics (CPU, Memory, Network)
- Database metrics (query times, connections)
- Error logs
- CDN logs

3. Reproduce Locally:

Try to reproduce:
- Same endpoint
- Same user data
- Same geographic location (VPN)
- Same time of day

4. Form Hypotheses:

Possible causes:

Geographic:
- CDN not working in some regions
- Database replica lag in some regions

User-Specific:
- Large accounts with more data
- Specific data causing slow query
- User hitting rate limits

Infrastructure:
- One server in pool is slow
- Network issues to specific regions
- Database connection pool exhausted

Code:
- N+1 query problem
- Missing cache for some users
- Deadlock/blocking queries

5. Test Hypotheses:

Example: Database query slow for large accounts

Test:
1. Check query execution plans (EXPLAIN)
2. Look at slow query logs
3. Check if specific to users with lots of data
4. Add index or optimize query
5. Test in staging
6. Deploy fix
7. Monitor metrics

6. Implement Fix:

Short-term:
- If one server is bad, remove from load balancer
- If database issue, point reads to faster replica
- If user-specific, optimize their data or limit results

Long-term:
- Add monitoring/alerting
- Optimize queries
- Improve indexing
- Add caching
- Document for future reference

7. Post-Mortem:

After resolution:
- What happened?
- Why did it happen?
- How did we detect it?
- How did we fix it?
- How can we prevent it?
- What can we improve?

Q5: Difference between processes and threads

Answer from First Principles:

Process:

- Independent program in execution
- Has own memory space
- Has own resources (file handles, etc.)
- Heavy (expensive to create)
- Isolated (crash doesn't affect other processes)

Example:
- Each Chrome tab is a process
- Multiple Node.js instances

Thread:

- Lightweight unit of execution within a process
- Shares memory space with other threads in same process
- Shares resources
- Lightweight (cheap to create)
- Not isolated (crash can affect whole process)

Example:
- Handling multiple requests in same server
- Background tasks in same application

Analogy:

Process = House
- Complete unit with own resources
- Walls separate it from other houses

Thread = Person in house
- Multiple people (threads) live in house (process)
- Share resources (kitchen, bathroom)
- Can see what others are doing

Concurrency Models:

Multi-Process:

Advantages:
- True parallelism on multiple CPUs
- Fault isolation
- No shared memory issues

Disadvantages:
- Heavy resource usage
- IPC (Inter-Process Communication) needed
- More memory

Use when:
- CPU-intensive tasks
- Need fault isolation
- Working with legacy code

Multi-Threading:

Advantages:
- Lightweight
- Shared memory (easy communication)
- Less resource usage

Disadvantages:
- Race conditions
- Deadlocks
- Complex synchronization
- One thread crash can crash all

Use when:
- I/O-intensive tasks
- Need shared state
- Many concurrent operations

Event Loop (Node.js, Python asyncio):

- Single-threaded
- Non-blocking I/O
- Async operations

Advantages:
- Simple (no threading complexity)
- Efficient for I/O-bound
- Low memory

Disadvantages:
- One CPU core only
- Blocking operations stop everything

Use when:
- I/O-intensive (APIs, database)
- Real-time applications
- Microservices

Q6: How do you ensure data consistency in a distributed system?

Answer:

Challenge:

Multiple servers processing requests
Data stored across multiple databases
Network delays and failures

Strategies:

1. Two-Phase Commit (2PC):

Use for: Strong consistency required

Phase 1 - Prepare:
Coordinator: "Can you all commit this transaction?"
All nodes: "Yes, I'm ready" or "No, I can't"

Phase 2 - Commit:
If all say yes:
  Coordinator: "Commit now"
  All nodes commit
Else:
  Coordinator: "Abort"
  All nodes rollback

Problems:
- Slow (multiple round trips)
- Blocking (if coordinator fails)
- Not partition-tolerant

2. Saga Pattern:

Use for: Long-running transactions across microservices

Break transaction into steps:
1. Reserve inventory
2. Charge payment
3. Create shipment

If step fails, execute compensating transactions:
- Cancel shipment
- Refund payment
- Release inventory

Eventual consistency, more resilient

3. Event Sourcing:

Store all changes as events
Current state = replay all events

Example: Bank account
Event 1: Deposited $100 (balance: 100)
Event 2: Withdrew $30 (balance: 70)
Event 3: Deposited $50 (balance: 120)

Advantages:
- Complete audit trail
- Can rebuild state
- Can replay events

Disadvantages:
- Complexity
- Storage overhead

4. CQRS (Command Query Responsibility Segregation):

Separate write model from read model

Write:
- Handle commands
- Update write database
- Publish events

Read:
- Subscribe to events
- Update read database (optimized for queries)
- Handle queries

Advantages:
- Optimize each side independently
- Scale reads and writes separately

Disadvantages:
- Eventual consistency
- More complex

5. Eventual Consistency:

Accept that data might be temporarily inconsistent
Guarantee it will become consistent eventually

Example: Social media likes
- User clicks like
- Update shown immediately (optimistic)
- Update propagates to servers
- If fails, revert

Good for:
- Non-critical data
- High availability needed
- Global distribution

Interview Question: "Which approach would you use for an e-commerce checkout?"

Answer:

Use Saga Pattern with event-driven architecture:

1. Reserve Inventory (compensate: release inventory)
2. Authorize Payment (compensate: refund)
3. Create Order (compensate: cancel order)
4. Send Confirmation Email

Why:
- Need reliability (can't charge without inventory)
- Need to handle failures gracefully
- Microservices architecture (different services)
- Better UX (not blocking on all operations)

Critical: Payment and inventory must be consistent
Non-critical: Email can be eventually consistent

Conclusion

Mastering backend development is about understanding fundamental principles rather than memorizing solutions. When faced with interview questions:

Clarify Requirements: Ask questions before jumping to solutions
Think from First Principles: Understand the "why" behind concepts
Consider Trade-offs: There's no perfect solution, only trade-offs
Start Simple: Begin with basic solution, then optimize
Communicate: Explain your thought process

Remember: Interviewers want to see how you think, not just what you know.

Additional Resources

Books:

Designing Data-Intensive Applications by Martin Kleppmann
System Design Interview by Alex Xu
Clean Architecture by Robert C. Martin

Practice:

LeetCode System Design
System Design Primer (GitHub)
Design Gurus

Communities:

r/backend
Dev.to
Stack Overflow

Good luck with your interviews! Remember: You've got this! 🚀

Backend First Principles - Complete Interview Preparation Guide

Backend First Principles - Complete Interview Preparation Guide

Join Our Community for Updates

Introduction

Table of Contents

What is Backend Development?

First Principles Understanding

Client-Server Architecture

First Principles Understanding

Interview Questions on Client-Server

HTTP Protocol Deep Dive

First Principles Understanding

HTTP Methods (Verbs)

HTTP Status Codes

HTTP Headers

REST API Principles

First Principles Understanding

1. Resource-Based

2. Stateless

3. Cacheable

4. Uniform Interface

Database Fundamentals

First Principles Understanding

SQL vs NoSQL

ACID Properties

Database Indexing

Database Normalization

Authentication & Authorization

First Principles Understanding

Session-Based Authentication

Token-Based Authentication (JWT)

OAuth 2.0

Caching Strategies

First Principles Understanding

Where to Cache?

Caching Strategies

Cache Eviction Policies

Message Queues & Async Processing

First Principles Understanding

Common Use Cases

Popular Message Queue Systems

Queue Patterns

System Design Fundamentals

First Principles Understanding

CAP Theorem

Load Balancing

Database Replication

Database Sharding

Scaling Principles

First Principles Understanding

Vertical vs Horizontal Scaling

Identifying Bottlenecks

Performance Optimization

Security Best Practices

First Principles Understanding

Common Vulnerabilities

Security Best Practices

Common Interview Questions

System Design Questions

Conceptual Questions

Conclusion

Additional Resources