Interview answer:

System design is the process of defining the architecture, components, data storage, APIs, communication patterns, and infrastructure of a software system based on its requirements.

The goal is not only to make the application function correctly, but also to ensure it can handle requirements such as scalability, availability, reliability, performance, security, and maintainability.

For example, if we're designing an e-commerce application, we need to decide how clients communicate with backend services, where product and order data is stored, how frequently accessed data is cached, how requests are distributed across servers, and how the system behaves when a component fails.

Key sentence to remember:

System design is about deciding how different components work together to build a scalable, reliable, and maintainable system.

Interview answer:

HLD, or High-Level Design, describes the overall architecture of the system and the major components and their interactions.

For example:

Client
   ↓
API Gateway
   ↓
Backend Services
   ↓
Cache / Database / Message Queue

In HLD, we discuss things such as:

• Services
• Databases
• Caching
• Load balancing
• Message queues
• API communication
• Scalability
• Fault tolerance

LLD, or Low-Level Design, focuses on the internal implementation of individual components.

For example, in a .NET application:

ProductController
       ↓
IProductService
       ↓
ProductService
       ↓
IProductRepository
       ↓
Database

LLD includes:

public interface IProductService
{
    Task<Product?> GetProductAsync(int id);
}

It covers classes, interfaces, relationships, SOLID principles and design patterns.

Key difference:

HLD explains how the overall system is structured, while LLD explains how individual components are implemented.

Interview answer:

Functional requirements describe what the system should do.

For an e-commerce application, functional requirements could be:

Search products
Add product to cart
Place order
Make payment
Track order

Non-functional requirements describe how well the system should perform those functions.

Examples include:

Scalability
Availability
Reliability
Latency
Security
Consistency
Durability
Maintainability

For example:

"The user should be able to place an order."

is a functional requirement.

Whereas:

"The order API should respond within 300 milliseconds for 99% of requests."

is a non-functional requirement.

Remember:

Functional     → WHAT the system does

Non-functional → HOW WELL the system does it

Interview answer:

Scalability is the ability of a system to handle increasing workload by adding resources without significantly degrading performance.

For example, suppose our API initially handles:

1,000 requests/sec

but after the application grows, it needs to handle:

100,000 requests/sec

The architecture should allow us to increase capacity.

There are two main approaches:

Vertical Scaling
Horizontal Scaling

Vertical scaling means increasing the resources of an existing server.

Horizontal scaling means adding additional servers.

For distributed web applications, horizontal scaling is commonly preferred because it can provide both greater capacity and better fault tolerance.

Interview answer:

Vertical scaling means increasing the resources of an existing machine.

For example:

Before
4 CPU
8 GB RAM

     ↓

After
16 CPU
64 GB RAM

This is also called scaling up.

Horizontal scaling means adding more machines.

              Load Balancer
             /      |      \
            ↓       ↓       ↓
        Server 1 Server 2 Server 3

This is called scaling out.

Comparison

Interview follow-up: Which would you choose?

I'd say:

"For a small application, vertical scaling may be sufficient and simpler. For a high-traffic distributed application, I'd generally design for horizontal scaling because we can add application instances as traffic increases and avoid depending on a single server."

Interview answer:

Availability refers to whether a system is accessible and able to serve requests when users need it.

For example:

99.9% availability

means the system is expected to be available for 99.9% of the measured period.

Reliability refers to whether the system continues to perform its intended function correctly and consistently over time.

Consider a payment system.

Suppose the API is reachable almost all the time:

Availability = High

but occasionally the application processes the same payment twice.

The system may be highly available, but it isn't sufficiently reliable or correct.

Easy way to remember

Availability
      ↓
Can I access the system?

Reliability
      ↓
Can I trust the system to work correctly?

In real system design, these concepts overlap, but they're not identical.

Interview answer:

Latency is the amount of time required to process a request or operation.

For example:

Client → API → Database → API → Client

Total = 120 ms

The request latency is approximately:

120 ms

Throughput represents how much work the system processes within a given amount of time.

For an API, we might measure:

10,000 requests/second

For a messaging system:

500,000 messages/second

For storage:

MB/s or GB/s

So:

Latency measures how long an operation takes, while throughput measures how many operations can be processed over time.

This question often follows Q7.

Interview answer:

Latency measures the time required for an individual operation, whereas throughput measures the amount of work completed within a given period.

For example:

Average API response = 100 ms

That's latency.

API handles 20,000 requests/sec

That's throughput.

A system can theoretically have:

Low latency + Low throughput
High latency + High throughput
Low latency + High throughput ← usually desirable

Important interview point

Don't assume improving throughput automatically improves latency.

For example, batch processing may increase throughput because many records are processed together, while increasing the latency experienced by an individual item waiting for a batch.

This is extremely important.

If an interviewer says:

"Design an e-commerce system."

Don't immediately say:

"I'll use microservices, Kafka, Redis, Kubernetes..."

That's a common mistake.

Start with requirements clarification.

Functional requirements

Ask:

"What are the core features we need to support?"

For example:

Product search?
Cart?
Orders?
Payments?
Inventory?
Recommendations?

Then clarify scale.

How many users?

How many daily active users?

What's the expected read/write traffic?

Are there traffic spikes?

Then ask about non-functional requirements.

What availability do we require?

What latency is acceptable?

Do we need strong consistency?

Are there durability requirements?

Then clarify data characteristics.

How much data?

How quickly does it grow?

What's the read/write ratio?

How long should we retain it?

Strong interview response

I'd say:

"Before choosing technologies, I'd first clarify the functional requirements, expected scale, traffic patterns, data volume, consistency requirements, latency expectations and availability requirements. Those constraints will drive the architecture."

That's a very good sentence to remember.

This is the most important question today because it tests whether you can apply the framework.

Suppose the interviewer says:

Design a URL Shortener like Bitly.

Don't immediately start designing.

Step 1 — Clarify Requirements

I'd start by asking:

"Before getting into the architecture, I'd like to clarify the requirements and expected scale."

Functional requirements

We need:

1. Create short URL

Long URL
     ↓
https://example.com/something/very/long

     ↓

Short URL

short.ly/Ab12Cd

Second:

2. Redirect short URL

short.ly/Ab12Cd

       ↓

Original URL

Potential additional requirements:

Custom aliases
Expiration
Analytics

But if the interviewer says they're out of scope, don't design them.

Step 2 — Estimate Scale

Suppose the interviewer gives:

10 million new URLs/day
100 million redirects/day

Calculate approximate average QPS.

For writes:

10,000,000 / 86,400

≈ 116 writes/sec

For redirects:

100,000,000 / 86,400

≈ 1,157 reads/sec

But average traffic isn't enough.

We should design for peak traffic, potentially several times higher.

Notice something else:

Reads >> Writes

So this is a read-heavy system.

That immediately suggests caching may be useful.

Step 3 — Define APIs

We could expose:

POST /api/urls

Request:

{
  "longUrl": "https://example.com/products/12345"
}

Response:

{
  "shortUrl": "https://short.ly/aB3x91"
}

Redirect:

GET /aB3x91

Response:

HTTP 301/302 Redirect
Location: https://example.com/products/12345

We'd discuss 301 vs 302 later because it has caching and analytics implications.

Step 4 — Data Model

A simple model might be:

UrlMapping

shortCode
longUrl
createdAt
expiresAt

Example:

aB3x91
    ↓
https://example.com/products/12345

The most important lookup is:

shortCode → longUrl

Therefore shortCode should support efficient lookup, typically through an appropriate key/index.

Step 5 — High-Level Architecture

Now we can finally draw the architecture.

                     ┌───────────┐
                     │  Clients  │
                     └─────┬─────┘
                           │
                           ▼
                    ┌─────────────┐
                    │Load Balancer│
                    └──────┬──────┘
                           │
                  ┌────────┴────────┐
                  │                 │
                  ▼                 ▼
             ┌─────────┐       ┌─────────┐
             │API      │       │API      │
             │Server 1 │       │Server 2 │
             └────┬────┘       └────┬────┘
                  │                 │
                  └────────┬────────┘
                           │
                     ┌─────▼─────┐
                     │   Cache   │
                     └─────┬─────┘
                           │
                     Cache Miss
                           │
                           ▼
                     ┌──────────┐
                     │ Database │
                     └──────────┘

Step 6 — Redirect Flow

User enters:

short.ly/aB3x91

Request goes:

Client
  ↓
Load Balancer
  ↓
API Server
  ↓
Cache

If cache contains:

aB3x91
   ↓
https://example.com/products/12345

return the redirect immediately.

This gives us:

Client
 ↓
API
 ↓
Cache
 ↓
Redirect

Very fast.

Step 7 — Cache Miss

If the mapping isn't cached:

API
 ↓
Cache
 ↓
MISS
 ↓
Database
 ↓
Get URL
 ↓
Store in Cache
 ↓
Redirect

Subsequent requests can hit the cache.

Because URL shorteners are typically read-heavy, popular mappings are good caching candidates.

Step 8 — Scaling

If traffic grows:

                 Load Balancer
                /      |      \
               ↓       ↓       ↓
             API1    API2    API3

Application servers should ideally remain stateless so instances can be added or removed easily.

We'll study stateless architecture later.

Step 9 — Identify Bottlenecks

Potential bottlenecks include:

Database traffic

Hot URLs

Cache overload

Short-code generation

Storage growth

Server failures

For example, if a celebrity posts:

short.ly/xyz123

millions of people might access the exact same URL.

That's a hot key scenario.

Caching can reduce database pressure, though at very large scale we'd need to think more carefully about cache distribution and hot-key handling.

Step 10 — Discuss Trade-offs

For example:

SQL vs NoSQL

Don't say:

"NoSQL is better because it's faster."

Instead say:

"The dominant access pattern is a key-based lookup from shortCode to longUrl. Depending on the expected scale and consistency requirements, a distributed key-value store could be a good fit. At smaller scale, a relational database with an indexed shortCode can also work well. I'd choose based on the actual scale and operational requirements."

That's system-design thinking.

⭐ Q10 — Compact Interview Answer

If the interviewer asks you to summarize your approach, say:

"I'd first clarify the functional and non-functional requirements. Then I'd estimate traffic and storage to understand the expected scale. Next I'd define the APIs and data model. After that I'd create the high-level architecture and walk through the major read and write flows. Finally, I'd identify bottlenecks and discuss scaling, caching, availability, failure handling and the trade-offs behind the design choices."

That's one of the most useful answers to remember.

🧠 Day 1 Cheat Sheet

System Design Interview

        ↓

1. Requirements
        ↓
2. Scale Estimation
        ↓
3. APIs
        ↓
4. Data Model
        ↓
5. High-Level Design
        ↓
6. Request/Data Flow
        ↓
7. Bottlenecks
        ↓
8. Scaling
        ↓
9. Failure Handling
        ↓
10. Trade-offs

And remember these five pairs:

Functional       = WHAT
Non-functional   = HOW WELL

Vertical scaling = BIGGER machine
Horizontal       = MORE machines

Latency          = TIME per operation
Throughput       = WORK per unit time

Availability     = Can users access it?
Reliability      = Does it keep working correctly?

HLD              = Architecture
LLD              = Classes / objects / implementation

Interview answer

Horizontal scaling means increasing system capacity by adding more servers or application instances instead of increasing the resources of an existing server.

For example, instead of running one API server:

Users
  ↓
API Server

we can run multiple instances:

              Load Balancer
             /      |      \
            ↓       ↓       ↓
          API 1   API 2   API 3

It is often preferred for large-scale systems because we can add or remove instances as traffic changes. It also provides better fault tolerance because failure of one instance doesn't necessarily bring down the entire application.

Example

If one server handles approximately 5,000 requests/sec:

1 server → 5K req/sec
3 servers → ~15K req/sec
10 servers → ~50K req/sec

The actual capacity depends on the workload and other bottlenecks.

Strong follow-up answer

Interviewer: "Can a monolithic application be horizontally scaled?"

Yes. Horizontal scaling doesn't require microservices. An ASP.NET Core monolith can run as multiple stateless instances behind a load balancer.

That's an important point.

Interview answer

Vertical scaling means increasing the CPU, RAM, storage, or other resources of an existing machine. Horizontal scaling means adding more machines or application instances.

Vertical

Before:
4 CPU + 8 GB RAM

        ↓

After:
16 CPU + 64 GB RAM

Horizontal

        Load Balancer
        /     |     \
       ↓      ↓      ↓
     API 1  API 2  API 3

Comparison

Interview conclusion

"For a small application, vertical scaling may be simpler. For a high-traffic application, I'd generally design for horizontal scaling because it provides greater capacity and allows us to add or remove instances based on demand."

Interview answer

A load balancer distributes incoming requests across multiple backend servers or instances.

For example:

                    Users
                      │
                      ▼
               ┌─────────────┐
               │Load Balancer│
               └──────┬──────┘
                ┌──────┼──────┐
                ↓      ↓      ↓
              API 1  API 2  API 3

It provides several benefits:

1. Traffic distribution

Prevents one server from receiving all requests.

2. Scalability

We can add more instances behind the load balancer.

3. Availability

If one instance becomes unhealthy, traffic can be routed to healthy instances.

4. Routing

Advanced load balancers can route based on:

• URL
• Host
• Headers
• Ports
• IP
• Other application-level information

Good interview sentence

"The load balancer provides a single entry point for clients while distributing traffic across healthy backend instances."

This is a common interview question.

Layer 4 — Transport Layer

Layer 4 primarily operates using network/transport information such as:

• IP address
• TCP
• UDP
• Port

It doesn't need to understand the HTTP request in detail.

Conceptually:

Client
  ↓
TCP
  ↓
L4 Load Balancer
  ↓
Server

Layer 7 — Application Layer

Layer 7 understands application protocols such as HTTP/HTTPS.

It can make routing decisions based on:

URL
HTTP method
Host
Headers
Cookies

For example:

/api/products/*
        ↓
Product Service

/api/orders/*
        ↓
Order Service

Comparison

Interview answer

"I'd use Layer 4 when I primarily need transport-level load balancing, while Layer 7 is useful when routing needs to understand HTTP-level information such as hostnames, paths, or headers."

1. Round Robin

Requests are distributed sequentially.

Request 1 → Server 1
Request 2 → Server 2
Request 3 → Server 3
Request 4 → Server 1
Request 5 → Server 2

Pattern:

S1 → S2 → S3 → S1 → S2 → S3

Simple and works well when servers have similar capacity and requests have reasonably similar cost.

2. Weighted Round Robin

Servers receive different amounts of traffic based on assigned weights.

Server 1 → Weight 5
Server 2 → Weight 3
Server 3 → Weight 2

Server 1 receives more traffic.

Useful when:

Server 1 = 16 CPU
Server 2 = 8 CPU
Server 3 = 4 CPU

3. Least Connections

The load balancer sends the next request to the server with the fewest active connections.

Server 1 → 100 connections
Server 2 → 50 connections
Server 3 → 20 connections

New request
     ↓
Server 3

This can be useful when requests have varying processing times.

4. IP Hash

The client's IP is used to determine the backend server.

Conceptually:

Client IP
   ↓
 Hash
   ↓
Server

This can provide a degree of client affinity.

However, it shouldn't be treated as a perfect session-management mechanism because clients can share IPs, change networks, or sit behind proxies/NAT.

Interview summary

"Round Robin is simple sequential distribution, Weighted Round Robin accounts for different server capacities, Least Connections considers current connection load, and IP Hash maps clients to servers based on their IP."

Interview answer

A health check is a mechanism used to determine whether an application instance or dependency is healthy and capable of serving traffic.

For example:

GET /health

Healthy response:

200 OK

If an instance repeatedly returns errors or times out:

API 1 → Healthy
API 2 → Unhealthy
API 3 → Healthy

the load balancer can stop routing new traffic to API 2.

             Load Balancer
             /           \
            ↓             ↓
         API 1           API 3
          ✅               ✅

         API 2
          ❌
       removed from
       traffic

ASP.NET Core example

builder.Services.AddHealthChecks();

app.MapHealthChecks("/health");

You can also add checks for dependencies such as databases.

Important distinction

Liveness:

Is the application process alive?

Readiness:

Is the application ready to receive traffic?

For example, an application might be running but unable to connect to its required database. It may be alive but not ready to serve certain requests.

Strong interview answer

"I'd use health checks together with load balancing so unhealthy instances can be removed from traffic automatically."

Stateless service

A stateless service doesn't depend on information stored only in the memory of a particular application instance to process the next request.

Example:

Request 1
   ↓
API 1

Request 2
   ↓
API 2

Both servers can process the user's requests.

Shared state, when necessary, can be stored externally:

API 1 ──┐
API 2 ──┼──→ Redis / Database
API 3 ──┘

Stateful service

A stateful service maintains important state locally or is otherwise tied to a particular instance.

For example:

User
 ↓
Server 1
 ↓
Session stored in Server 1 memory

If the next request goes to Server 2:

User
 ↓
Server 2

❌ Session isn't available locally

Key difference

A stateless service doesn't require a particular server's local state to process a request, whereas a stateful service depends on stored state associated with the service or instance.

This is a very important interview question.

Interview answer

Stateless services are easier to scale horizontally because any instance can handle any request without depending on session data stored in another instance's local memory.

Suppose we have:

             Load Balancer
             /     |     \
            ↓      ↓      ↓
          API 1  API 2  API 3

If the APIs are stateless:

Request A → API 1
Request B → API 3
Request C → API 2
Request D → API 1

No problem.

If traffic increases:

             Load Balancer
          /    /    |    \    \
         ↓    ↓     ↓     ↓    ↓
       API1 API2  API3  API4  API5

we can simply add instances.

In ASP.NET Core

A common architecture is:

Client
  ↓
Load Balancer
  ↓
Multiple ASP.NET Core instances
  ↓
Redis / Database / Message Queue

Authentication using bearer tokens can also support this model because the API instances don't need to keep the user's primary authentication session in local memory.

Strong sentence

"Statelessness removes server affinity as a requirement, which makes horizontal scaling and failover much easier."

Interview answer

Sticky sessions, also called session affinity, mean that the load balancer tries to send subsequent requests from the same client to the same backend instance.

Example:

User A
  ↓
Load Balancer
  ↓
API 1

Future requests:

User A → API 1
User A → API 1
User A → API 1

Why use them?

They're useful when an application maintains session state locally on the server.

For example:

API 1
 └── User session

Without affinity:

Request 1 → API 1
Request 2 → API 2

API 2 doesn't have API 1's local session

Advantages

• Can support legacy stateful applications
• Simple way to preserve local session affinity
• May reduce some external session-storage requirements

Disadvantages

1. Uneven load

One server may receive more users than others.

2. Reduced scalability

Scaling becomes less flexible.

3. Failure impact

If the server containing a user's session fails, that session may be lost unless replicated elsewhere.

4. Poorer elasticity

Dynamic addition/removal of instances becomes more complicated.

Preferred modern approach

Instead of:

Sticky sessions
      ↓
Local server memory

we often prefer:

Stateless APIs
      ↓
Shared external state
      ↓
Redis / Database

Interview conclusion

"Sticky sessions can be useful for legacy stateful applications, but for a modern horizontally scalable API, I'd generally prefer stateless services with shared external state."

Interview answer

A Single Point of Failure, or SPOF, is a component whose failure can cause the entire system or a critical part of the system to become unavailable.

Example:

Users
  ↓
Single API Server
  ↓
Database

If that API server fails:

API Server ❌

Entire application unavailable

That's a SPOF.

Remove the API SPOF

Use multiple instances:

              Load Balancer
             /      |      \
            ↓       ↓       ↓
          API 1   API 2   API 3

If API 2 fails:

API 1 ✅
API 2 ❌
API 3 ✅

The other instances can continue serving requests.

But there's another problem

What if we have:

Users
  ↓
Single Load Balancer
  ↓
Multiple APIs

The load balancer itself can become a SPOF.

Therefore production architecture needs redundancy at critical infrastructure layers as appropriate.

Similarly, consider the database:

Multiple APIs
      ↓
Single Database

If the database fails, the entire application may still fail.

We might introduce:

Primary
   │
   ├── Replica 1
   └── Replica 2

and appropriate failover/recovery mechanisms.

Important point

You don't simply eliminate SPOFs by adding servers everywhere.

You need to identify:

Application
Load Balancer
Database
Cache
Message Broker
Network
Storage

and determine which failures the system must tolerate.

Strong interview answer

"I'd identify critical components that can bring down the system, then introduce redundancy, health checks, failover mechanisms, replication and appropriate recovery strategies. I'd also consider whether the added complexity is justified by the availability requirement."

That last sentence demonstrates trade-off thinking.

🔥 Day 2 Scenario — Interview Practice

Suppose the interviewer says:

"Your ASP.NET Core API is currently deployed on one Azure VM. Traffic has increased significantly. How would you redesign it?"

A strong answer would be:

"First, I'd determine the current bottleneck using metrics such as CPU, memory, request latency, throughput and database utilization. If the application tier is the bottleneck, I'd make the API stateless and deploy multiple instances behind a load balancer or appropriate Azure application-routing service. I'd configure health checks so unhealthy instances are removed from traffic and enable autoscaling based on demand. I'd move any instance-local session state to a shared store such as Redis or the database. I'd also check whether the database or other dependencies become the next bottleneck, because scaling the API layer alone won't solve a database bottleneck."

That's the kind of answer you should aim for.

🧠 Day 2 Final Revision

Memorize this architecture:

                         INTERNET
                            │
                            ▼
                    ┌─────────────┐
                    │Load Balancer│
                    └──────┬──────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
           API 1         API 2        API 3
              │            │            │
              └────────────┼────────────┘
                           │
                    ┌──────┴──────┐
                    ▼             ▼
                 Redis        Database

And these concepts:

⭐ Most important lesson from Day 2

Don't think:

"More servers = scalable system."

Think:

"Can I add/remove instances safely, distribute traffic, survive instance failures, and avoid relying on local state?"

That's the foundation of horizontal scalability.

Interview answer

A database can become a bottleneck when its available resources or processing capacity are insufficient to handle the workload generated by application servers.

Even if we add multiple ASP.NET Core instances, they may all send queries to the same database. This increases database CPU utilization, memory pressure, disk I/O, lock contention, and connection usage.

For example:

                 Load Balancer
                /      |      \
               ▼       ▼       ▼
             API 1    API 2    API 3
                \      |      /
                 \     |     /
                  ▼    ▼    ▼
                  SQL Server
                   CPU: 100%

Adding more API instances won't necessarily improve performance because all instances depend on the same overloaded database.

How would you solve it?

I'd first identify the actual bottleneck using database metrics and query execution plans. Depending on the findings, I would:

1. Optimize expensive SQL queries.
2. Add appropriate indexes.
3. Reduce unnecessary database calls.
4. Introduce caching for frequently accessed data.
5. Use read replicas for suitable read-heavy workloads.
6. Consider partitioning or sharding if the workload or data volume justifies it.

Key interview point: Always identify the bottleneck before selecting a scaling strategy.

Interview answer

SQL databases are generally relational databases that organize data into tables with defined schemas, relationships, and constraints. They support SQL queries and commonly provide transactions with ACID guarantees.

NoSQL is a broad category that includes document, key-value, wide-column, and graph databases. These systems offer different data models and consistency, transaction, and scaling capabilities.

Example

For an order-management system:

Customers
   │
   └── Orders
          │
          └── OrderItems

A relational database is a natural choice because these entities have relationships and transactional requirements.

For a distributed session store:

sessionId → sessionData

A key-value database such as Redis could be appropriate.

Important follow-up: Is NoSQL always faster than SQL?

No. Performance depends on the database implementation, data model, query patterns, workload, consistency requirements, and configuration.

Remember: Choose the database based on requirements and access patterns, not simply because one category is supposedly faster.

Interview answer

I'd choose SQL Server when the application has relational data, complex queries, transactional requirements, constraints, and a need for reliable consistency across related records.

For example, consider an order-processing application involving customers, orders, inventory, and payments.

A transaction may need to update multiple related records together. SQL Server supports ACID transactions and relational constraints that help maintain data integrity.

Example:

BEGIN TRANSACTION;

UPDATE Inventory
SET Quantity = Quantity - 1
WHERE ProductId = 100
  AND Quantity > 0;

-- Application must verify that exactly one row was updated.
-- Otherwise, roll back.

COMMIT TRANSACTION;

In a real implementation, the application must check the affected row count and roll back if the update did not succeed. Payment processing may also require idempotency and coordination with external services.

When might NoSQL be a better choice?

• Large-scale key-based lookups.
• Flexible document structures.
• High-volume event ingestion.
• Distributed workloads with specific access patterns.
• Workloads where a particular NoSQL database's scaling and consistency model is appropriate.

Strong conclusion

"I wouldn't choose SQL or NoSQL based on popularity. I'd evaluate the data relationships, query patterns, transaction boundaries, consistency needs, throughput, and operational cost. For a relational order-processing system, SQL Server would often be my starting point."

Interview answer

A database index is a data structure that helps the database locate records efficiently without scanning every row in a table.

Suppose we have a table containing millions of users:

SELECT *
FROM Users
WHERE Email = 'user@example.com';

Without a suitable index, SQL Server may need to scan many rows to find the matching email.

With an appropriate index:

CREATE INDEX IX_Users_Email
ON Users(Email);

SQL Server can use the index to locate matching records more efficiently, depending on the query plan and selectivity.

Conceptually:

Query: Find user by email

Index on Email

Locate the matching key

Matching row(s)

Common index types in SQL Server

• Clustered index: Organizes the table's data rows according to the clustered index key.
• Nonclustered index: Maintains a separate index structure with keys and row locators.
• Composite index: Uses multiple columns, with column order affecting which queries can benefit.
• Unique index: Enforces uniqueness of indexed key values.

Follow-up: Should every column have an index?

No. Indexes consume storage and add overhead to inserts, updates, and deletes. I'd create indexes based on frequently executed queries, filtering, joins, sorting, and measured execution plans.

Interview answer

Indexes improve certain read operations but introduce storage and maintenance costs.

Every time an indexed column changes, the database may need to update the corresponding index structure.

Too many indexes can cause:

1. Slower writes: Inserts, updates, and deletes may need to maintain multiple indexes.
2. More storage: Indexes consume disk space and potentially memory.
3. Maintenance overhead: Indexes may require maintenance and statistics updates.
4. Query-planning complexity: Additional indexes can create more possible access paths without necessarily improving a query.
5. Cache pressure: Index pages can compete for memory with other useful data.

Example

Suppose an orders table receives thousands of inserts per second.

Orders table
   ├── Index on CustomerId
   ├── Index on OrderDate
   ├── Index on Status
   ├── Index on Amount
   └── Index on another column

If several indexes aren't useful to actual queries, they may add overhead without providing meaningful benefits.

How would you decide which indexes to retain?

I'd examine:

• Query execution plans.
• Query frequency and duration.
• Index usage statistics.
• Write volume.
• Existing clustered and composite indexes.

Interview takeaway: Indexing is a trade-off between read performance, write performance, and storage cost.

Interview answer

Database replication involves maintaining copies of data on multiple database instances or nodes.

A common architecture has a primary database that accepts writes and one or more replicas that receive changes.

Primary Database

Accepts writes

Replicate changes

Replica 1

Replica 2

Replication can provide:

• Redundancy and improved availability.
• Read scaling, when replicas are used for reads.
• Disaster recovery options.
• Additional copies for certain reporting workloads.

Important distinction

Replication does not automatically guarantee zero data loss or automatic failover. Those depend on the replication mode, failure-detection mechanism, configuration, and recovery strategy.

Follow-up: Does replication improve write performance?

Not necessarily. In a primary-replica setup, writes generally still go through the primary, which must also handle replication work. Replication primarily helps with redundancy and, when appropriately configured, read scaling.

Interview answer

A read replica is a copy of a database that can serve read queries while the primary database typically handles writes.

It's particularly useful when an application has significantly more reads than writes.

For example:

                 Application
                 /          \
             Writes         Reads
                │              │
                ▼              ▼
             Primary       Read Replicas
                           /           \
                          ▼             ▼
                     Replica 1      Replica 2

Suppose the workload is:

• 20,000 read requests per second.
• 2,000 write requests per second.

After verifying the primary's actual capacity, we could distribute suitable read traffic across replicas to reduce the primary's read workload.

Which reads are suitable?

Good candidates may include:

• Product catalogue queries.
• Reports.
• Historical records.
• Read-heavy pages where a short delay in data propagation is acceptable.

Which reads need caution?

Suppose a user updates their address and immediately requests it again. If that read goes to a lagging replica, it might return the old address.

For read-after-write consistency, the application may need to read from the primary or use a database-specific consistency mechanism.

Key interview sentence

"I'd introduce read replicas when read traffic is a bottleneck, but I'd route reads according to their consistency requirements rather than sending every read to a replica."

Interview answer

Replication lag is the delay between a change being committed on the primary database and that change becoming visible on a replica.

Consider this sequence:

T1: User updates profile
          │
          ▼
Primary: Name = "Ramesh"
          │
          │ Replication delay
          ▼
Replica: Name = old value

If the next request reads from the replica before the change arrives, the user may see stale data.

Real-world consequences

• A newly created order may not immediately appear in order history.
• A profile update may appear to have failed.
• Inventory displayed from a replica may be outdated.
• Reporting results may lag behind recent transactions.

How would you handle it?

1. Route consistency-sensitive reads to the primary.
2. Use database-specific mechanisms for read-after-write consistency when available.
3. Monitor replica lag.
4. Avoid using potentially stale replica data for critical decisions such as inventory allocation unless the design explicitly handles that risk.
5. Use bounded staleness or eventual consistency where the business requirements allow it.

Important: Replication lag is not necessarily a failure. It becomes a problem when the application's consistency expectations are stricter than the replica's guarantees.

Interview answer

Replication creates additional copies of data, whereas sharding divides data across multiple database partitions or nodes.

Replication

All data

Copy A

Copy B

Purpose: redundancy, availability and potentially read scaling.

Sharding

All data

Shard A

Part 1

Shard B

Part 2

Purpose: distribute data, storage and workload.

Example

Suppose we have 100 million customers.

With replication, multiple database nodes may hold the same 100 million customers.

With sharding:

Shard 1 → Customers A–F
Shard 2 → Customers G–M
Shard 3 → Customers N–Z

Each shard stores a different subset of customers.

Can we use both together?

Yes. A common architecture distributes data across shards and replicates each shard for availability or read scaling.

Key interview sentence

"Replication addresses the need for additional copies of data, while sharding distributes different portions of the data across nodes. They're complementary techniques, not alternatives."

Interview answer

A shard key is the field, or combination of fields, used to determine which shard stores a particular record.

For example, in a customer database, we might use CustomerId to route records to shards.

Conceptually:

CustomerId
     │
     ▼
Shard Routing Logic
     │
     ├── Shard 1
     ├── Shard 2
     └── Shard 3

The application or database routing layer uses the shard key to locate the relevant shard.

Characteristics of a good shard key

1\. Even data distribution

Each shard should receive a reasonable share of the data.

2\. Even traffic distribution

One shard shouldn't receive a disproportionate share of requests.

3\. Query compatibility

The shard key should support common query patterns and avoid unnecessary cross-shard operations.

4\. Stability

The key should not change frequently, because moving records between shards can be expensive.

5\. Sufficient cardinality

There should be enough distinct key values to distribute the workload effectively.

Bad example: Sharding by country

Suppose the user population is:

India   → 80%
US      → 10%
UK      → 5%
Others  → 5%

Sharding only by country may overload the India shard while leaving other shards underutilized.

Another possible approach: Hash-based distribution

A hash function can distribute customer IDs across shards:

shard = hash(CustomerId) % numberOfShards

This is a simplified illustration. In real systems, changing the number of shards can cause many records to be remapped; consistent hashing or other routing strategies can help, depending on the database.

Strong interview conclusion

"I'd select a shard key based on data distribution, traffic distribution, and the application's most common queries. I'd also evaluate hotspot risk and the operational complexity of resharding before committing to the design."

🎯 Day 3 — Bonus Interview Scenario

Interviewer: Your ASP.NET Core e-commerce API is experiencing high SQL Server CPU utilization. How would you improve the architecture?

A good answer should be progressive:

1\. Measure the bottleneck

CPU, I/O, waits, connections, query plans

2\. Optimize SQL

Queries, indexes, execution plans, N+1 calls

3\. Reduce database workload

Caching, fewer round trips, pagination

4\. Scale the right workload

Read replicas, partitioning, suitable database scaling

5\. Consider sharding if necessary

When one database can no longer meet capacity requirements

Sample interview response

"I'd first examine query execution plans, database waits, CPU utilization, I/O, and connection usage to identify the actual cause. I'd optimize expensive queries and indexes, remove unnecessary database calls, and introduce caching for suitable frequently accessed data. If reads are the main bottleneck, I'd evaluate read replicas while accounting for replication lag. If storage or write throughput exceeds what a single database can support, I'd consider partitioning or sharding. I'd choose the solution based on measured bottlenecks and consistency requirements rather than jumping straight to sharding."

🧠 Day 3 Revision Sheet

Quick self-test

5-question quiz

0/5 answered

1\. Which technique creates additional copies of database data?

Sharding

Replication

Partition pruning

Indexing

2\. Which issue can cause a read replica to return an old value?

Horizontal scaling

Index fragmentation only

Replication lag

Load balancing

3\. What should you do first when SQL Server CPU reaches 100%?

Immediately shard the database

Measure and identify the bottleneck

Add API servers only

Replace SQL with NoSQL

4\. What is the main role of a shard key?

Encrypt database records

Determine which shard stores a record

Replicate every write

Create an index automatically

5\. Why can excessive indexes hurt performance?

They prevent all SELECT queries

They eliminate transactions

They add storage and write-maintenance costs

They always cause stale reads

Interview-ready answer

Caching is a technique that temporarily stores frequently accessed or expensive-to-compute data in a faster storage layer so that subsequent requests can retrieve it without repeating the original work.

For example, suppose an ASP.NET Core API retrieves product details from SQL Server. If thousands of users request the same product, querying SQL Server for every request creates unnecessary database load.

We can cache the product in Redis.

Client

ASP.NET Core API

Redis Cache

Hit: return cached data

Miss: query SQL Server

Benefits

• Lower response latency.
• Reduced database CPU and query load.
• Higher throughput for repeated reads.
• Reduced repeated computation and external API calls.

Example

Assume, illustratively, a database lookup takes 50 ms and a cache lookup takes 2 ms.

For repeated requests, a cache hit may avoid most of that database lookup time. Actual end-to-end latency depends on networking, serialization, application processing, and other factors.

Important: Caching doesn't automatically make every request faster. Cache misses, serialization, network calls, and invalidation overhead must also be considered.

Follow-up: Can caching replace a database?

No. In a typical application, the database remains the authoritative source of durable business data, while the cache stores temporary copies that can be rebuilt.

Interview-ready answer

Redis is an in-memory data store that supports low-latency access to data structures and is commonly used for caching, session storage, counters, and rate limiting.

For example, a product could be cached with the key:

Key:   product:100
Value: {"id":100,"name":"Keyboard","price":1500}
TTL:   300 seconds

The key identifies the cached value, and the TTL specifies its expiration time.

Why Redis?

1. Fast access to frequently used data.
2. Shared access from multiple application instances.
3. Built-in expiration support.
4. Useful data structures such as strings, hashes, sets and sorted sets.
5. Supports additional patterns such as counters and distributed coordination, when configured appropriately.

Redis vs SQL Server

Follow-up: Is Redis always faster?

Redis is optimized for low-latency data access, but real performance depends on network latency, data size, workload, configuration and database query efficiency.

Interview takeaway: Redis complements SQL Server; it doesn't automatically replace it.

Interview-ready answer

IMemoryCache stores cached objects in the memory of the application process. IDistributedCache provides an abstraction for caching through an external or distributed cache provider, such as Redis.

IMemoryCache

builder.Services.AddMemoryCache();

Example:

_cache.Set(
    "product:100",
    product,
    TimeSpan.FromMinutes(5));

The data is local to that application instance.

IDistributedCache

Register a distributed cache provider, then use methods such as:

await cache.SetStringAsync(
    "product:100",
    json,
    new DistributedCacheEntryOptions
    {
        AbsoluteExpirationRelativeToNow =
            TimeSpan.FromMinutes(5)
    });

Comparison

Scenario

Suppose your application runs on three servers.

With IMemoryCache:

API 1 → Cache A
API 2 → Cache B
API 3 → Cache C

These caches can contain different values.

With Redis-backed IDistributedCache:

API 1 ──┐
API 2 ──┼── Redis
API 3 ──┘

All three instances can access the same cached entries.

Important: IDistributedCache is only an abstraction. Registering AddDistributedMemoryCache() does not create a shared Redis cache; it uses in-process memory.

Interview-ready answer

Cache-aside, also called lazy loading, is a pattern where the application checks the cache first. If the requested value isn't present, it loads the data from the database, stores it in the cache, and returns it.

Flow

1\. Request product 100

2\. Check Redis

Hit

Return cached value

Miss

Query SQL Server

3\. Cache database result with TTL

4\. Return product

C# example

public async Task<Product?> GetProductAsync(int id)
{
    string key = $"product:{id}";

    var cached = await _cache.GetStringAsync(key);

    if (cached is not null)
    {
        return JsonSerializer.Deserialize<Product>(cached);
    }

    var product = await _dbContext.Products
        .AsNoTracking()
        .FirstOrDefaultAsync(p => p.Id == id);

    if (product is not null)
    {
        await _cache.SetStringAsync(
            key,
            JsonSerializer.Serialize(product),
            new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow =
                    TimeSpan.FromMinutes(5)
            });
    }

    return product;
}

Here, _cache is an IDistributedCache, and _dbContext is an EF Core DbContext. The required namespaces and dependency registrations must be configured.

Advantages

• Simple to implement.
• Only requested data gets cached.
• Works well for read-heavy APIs.

Disadvantages

• The first request after a miss is slower.
• Cached values may become stale.
• Concurrent misses can cause multiple database queries.

Follow-up: What happens if Redis is unavailable?

The application needs an explicit failure strategy. For noncritical cache reads, it may fall back to SQL Server, subject to database capacity and timeout limits. For cache writes, it may log the error and continue if the database update has already succeeded. Don't allow a cache outage to trigger unlimited database traffic.

Interview-ready answer

These patterns describe how cache data and authoritative storage are updated.

1. Cache-aside

The application loads data into the cache when a read misses.

Read → Cache miss → Database → Cache

Best for: Read-heavy workloads with frequently reused data.

Trade-off: Cache misses add latency, and writes require a separate invalidation/update strategy.

2. Write-through

The write path updates the authoritative database and cache as part of the chosen write strategy.

Write → Database + Cache update

Best for: Workloads where keeping the cache fresh after successful writes is valuable.

Trade-off: More coordination and error handling are required. SQL Server and Redis do not automatically share one atomic transaction.

3. Write-behind

The cache accepts changes first, and the database is updated asynchronously later.

Write → Cache → Async persistence → Database

Best for: Carefully designed workloads such as aggregations and buffered events.

Trade-off: Changes may be lost before persistence unless the system has appropriate durability, retry and recovery mechanisms.

Which would you choose for a typical .NET product API?

I'd usually start with cache-aside and invalidate the product cache after a successful database update.

It is straightforward and separates authoritative writes from cache population.

For payments, balances or inventory correctness, I would not rely on a cache write as proof that the business transaction has been durably committed.

Interview-ready answer

TTL, or Time To Live, specifies how long a cache entry remains valid before expiration.

For example:

Key: product:100
Value: Keyboard
TTL: 300 seconds

The entry expires after five minutes, unless its expiration is changed.

How do you choose a TTL?

Consider:

1. How frequently the underlying data changes.
2. How stale the application can tolerate the data becoming.
3. How expensive a cache miss is.
4. Memory capacity and eviction policy.
5. Traffic patterns and cache-miss bursts.

These are starting points, not fixed rules.

Follow-up: What is the difference between absolute and sliding expiration?

• Absolute expiration: The entry expires at a fixed deadline.
• Sliding expiration: The expiry is extended when the entry is accessed, subject to the configured interval.

For example, with a 10-minute sliding expiration, a frequently accessed entry may remain cached as long as it continues to be accessed within each 10-minute window. It can still expire according to other configured limits.

Interview takeaway: TTL balances freshness, memory usage, and cache-hit rate.

Interview-ready answer

Cache invalidation is the process of removing or refreshing cached data when the cached value is no longer valid.

Suppose Redis stores:

product:100 → price = ₹1,500

The product price changes in SQL Server to ₹1,700. If Redis isn't updated or invalidated, the application may continue returning the old price.

A common cache-aside approach

1. Update product in SQL Server
2. Commit the database transaction
3. Delete product:100 from Redis
4. Next read loads the updated value

Example:

await _dbContext.SaveChangesAsync();

await _cache.RemoveAsync($"product:{product.Id}");

This snippet assumes the database update has succeeded. It also assumes cache invalidation is best-effort; production code should handle failures and consider retry or reconciliation mechanisms.

What if Redis deletion fails?

SQL Server may contain the new value while Redis still holds the old one.

Possible mitigations include:

• Shorter TTLs where appropriate.
• Retrying invalidation.
• Recording cache-invalidation events in a durable outbox.
• Processing those events asynchronously.
• Versioning or coordinated refresh mechanisms for stricter requirements.

An outbox can help prevent the invalidation event from being lost when the database transaction commits, but consumers still need retries and idempotent processing.

Strong interview answer

"I'd treat SQL Server as the source of truth. After a successful database update, I'd invalidate the corresponding Redis key. For stronger reliability, I'd consider a transactional outbox and background processing so cache invalidation can be retried if Redis is unavailable."

Interview-ready answer

These are three different problems that can cause cache effectiveness to degrade or database load to spike.

Cache stampede

Many requests try to load the same missing or expired cache entry simultaneously.

Example: A popular product expires from Redis, and thousands of requests query SQL Server for that product at once.

Solutions: Request coalescing, single-flight loading, suitable locking and TTL jitter.

Cache penetration

Requests repeatedly ask for records that don't exist, so they keep missing the cache and reaching the database.

Example: Thousands of requests for a nonexistent product ID.

Solutions: Validate requests, rate-limit abusive traffic and use short-lived negative caching when appropriate.

Cache avalanche

Many cache entries expire or become unavailable around the same time, causing a surge of requests to the database.

Solutions: TTL jitter, staggered expiration, controlled cache warming and database capacity planning.

Remember the difference

• Stampede: many requests compete to load the same key.
• Penetration: requests repeatedly target nonexistent data.
• Avalanche: many entries become unavailable together.

Interview-ready answer

I'd use a Redis-backed distributed cache so multiple ASP.NET Core instances can access the same cache.

The architecture would look like this:

Load Balancer

API 1

API 2

API 3

Redis — shared cache

SQL Server — source of truth

Implementation approach

1. Register a Redis-backed IDistributedCache provider.
2. Use predictable, namespaced cache keys such as product:100.
3. Serialize values consistently.
4. Apply suitable expiration.
5. Use cache-aside for reads.
6. Invalidate affected entries after successful database updates.
7. Monitor cache hits, misses, latency, errors and evictions.
8. Define timeouts and a fallback strategy for cache outages.

Example registration

For a Redis-backed provider such as Microsoft.Extensions.Caching.StackExchangeRedis, configuration can be registered using the package's supported extension methods and your deployment's Redis connection settings.

Conceptually:

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration =
        builder.Configuration.GetConnectionString("Redis");

    options.InstanceName = "MyApp:";
});

This requires the appropriate provider package and a valid Redis connection string. Keep credentials in secure configuration, not in source control.

Follow-up: Why not use IMemoryCache?

With multiple instances, each local cache can contain different values. Redis gives the instances a shared cache, although invalidation and consistency still need to be designed correctly.

Interview-ready answer

I'd first investigate why database requests remain high despite the cache.

Potential causes include:

• A low cache-hit ratio.
• Frequently expiring keys.
• Incorrect cache keys.
• Large numbers of unique requests.
• Cache stampedes.
• Cache bypasses in certain API paths.
• Expensive queries unrelated to cached data.
• Cache failures or timeouts causing fallback traffic.
• Heavy writes that caching cannot eliminate.

Step 1: Measure

I'd examine:

Redis:
- Hit/miss ratio
- Latency
- Evictions
- Errors

SQL Server:
- CPU and I/O
- Expensive queries
- Wait statistics
- Connection usage
- Query execution plans

Application:
- Request volume
- Endpoint latency
- Cache errors
- Database calls per request

Step 2: Identify the actual cause

If a frequently requested product is repeatedly missing from Redis, I would inspect key generation, TTLs and invalidation behavior.

If SQL Server is overloaded by writes, read caching may not solve the main problem.

Step 3: Apply the appropriate fix

Strong interview response

"I'd measure Redis hit rates and latency alongside SQL Server query performance. If caching isn't working as expected, I'd investigate key design, TTLs, invalidation and stampedes. I'd optimize expensive queries and cache suitable read-heavy data. If writes are the bottleneck, I'd optimize the write path rather than assuming Redis will solve it. I'd also design controlled fallback behavior so a Redis outage doesn't overwhelm SQL Server."

Day 4 — Final Revision

What you should be able to explain without notes

• Why Redis helps a read-heavy .NET API.
• Why cache-aside is a good starting strategy.
• Why cache invalidation is difficult.
• How TTL affects freshness and database load.
• How to handle Redis outages safely.
• Why caching isn't a substitute for database optimization.

Next: Day 5 — Message Queues and Asynchronous Processing. We'll cover RabbitMQ, Azure Service Bus, Kafka, producer/consumer architecture, decoupling, retries, dead-letter queues, idempotency and how to use background processing in .NET.

A message queue is a communication mechanism that allows one application or service to send messages to another service without requiring the receiver to process them immediately.

It acts as an intermediary between a producer and a consumer.

Producer

Order API publishes an order

Message Broker / Queue

Stores the message until it can be processed

Consumer

Inventory or notification service

Why do we use message queues?

1. Loose coupling: The producer does not need to know how the consumer works.
2. Asynchronous processing: The API can respond without waiting for lengthy background work.
3. Load leveling: Messages can accumulate in the queue during traffic spikes and be processed at a sustainable rate.
4. Resilience: A temporary consumer outage need not cause the producer to fail, provided the broker durably accepts the message.
5. Independent scaling: We can add consumers to increase processing capacity.
6. Retries: Failed messages can be retried or moved to a dead-letter queue.

Example: E-commerce order processing

When a customer places an order:

• The Order API validates and saves the order.
• It publishes an OrderPlaced message.
• Background consumers process inventory, payment, email, and shipping tasks.

The customer does not have to wait for every downstream task to finish.

Interview answer: “A message queue decouples services and enables asynchronous processing, buffering, retries, and independent scaling. It improves resilience and helps systems handle traffic spikes.”

Important: A queue does not automatically guarantee that messages will never be lost. Reliability depends on durable messaging, publisher confirmation, acknowledgment strategy, retries, and correct application design.

Synchronous example

An API calls a payment service and waits for the result.

Client → Order API → Payment API
                       ↓
Client ← Order API ← Payment result

If the payment service takes 8 seconds, the Order API may remain waiting during that time.

Asynchronous example

Client → Order API → Save order + publish message
Client ← Order accepted

                  Queue → Payment Worker
                        → Notification Worker

The API can respond with 202 Accepted when processing has been accepted for later completion, or return 201 Created if the order resource has already been created. The correct status depends on the API contract.

Which should you use?

Use synchronous communication when the caller needs an immediate result—for example, retrieving a product or validating a login.

Use asynchronous communication when work can finish later—for example, sending emails, generating reports, processing images, or running long workflows.

Interview tip: async and await in C# do not automatically make communication asynchronous in the distributed-systems sense. An async HTTP call still waits for the remote response. Queue-based processing lets the request and the actual work have separate lifecycles.

Both are messaging patterns, but they distribute messages differently.

Queue: typically one competing consumer processes each message

                    ┌→ Worker A
Producer → Queue ───┤
                    └→ Worker B

If Worker A and Worker B compete for messages, a particular message is normally delivered to one of them for processing. Redelivery may happen if processing fails or acknowledgment is missing.

Use cases: Order fulfillment, background jobs, image processing, report generation.

Pub/Sub: multiple subscribers can receive the same event

                       ┌→ Inventory Service
Producer → Topic/Event ├→ Notification Service
                       └→ Analytics Service

Each subscriber or subscription receives its own copy or logical delivery of the event, depending on the broker's model and configuration.

Use cases: An order-created event consumed by inventory, notifications, analytics, and shipping.

Interview answer: “A queue distributes work among consumers, while Pub/Sub allows multiple independent subscribers to react to the same event. The exact delivery behavior depends on the broker and subscription configuration.”

All three support messaging, but they are optimized for different needs.

RabbitMQ Logo & Brand Assets (SVG, PNG and vector) - Brandfetch

RabbitMQ

• General-purpose message broker.
• Supports queues, routing, exchanges, acknowledgments, and retries through appropriate configuration.
• Good for background jobs and task distribution.
• Often chosen when flexible routing and traditional message-queue patterns are important.

Running Kafka on Production. Apache Kafka is an open-source… | by Pradyumna Khawas | WorkIndia.in | Medium

Apache Kafka

• Distributed event-streaming platform.
• Stores ordered records in partitioned, durable logs.
• Consumers can replay retained events by moving their offsets.
• Good for high-throughput event streams, analytics, and data pipelines.

Microsoft - Azure - Servicebus - Messageidplugin 2 - Azure Service Bus Logo Clipart - Large Size Png Image - PikPng

Azure Service Bus

• Managed Azure enterprise messaging service.
• Supports queues, topics/subscriptions, dead-letter queues, duplicate detection, and scheduled delivery.
• Integrates well with Azure-hosted .NET applications.
• Good for reliable business workflows and enterprise integration.

Quick comparison

Which would you choose?

• RabbitMQ: A task queue for processing jobs with flexible routing.
• Kafka: A high-volume event stream where consumers need to replay historical events.
• Azure Service Bus: An Azure-based business application needing durable messaging, retries, dead-letter handling, and enterprise integration.

For a .NET application already hosted in Azure, Azure Service Bus is often a practical starting point. But choose based on throughput, ordering, replay requirements, cost, operational needs, and the team's experience—not simply because the application uses Azure.

These terms describe how a messaging system handles delivery and redelivery.

1. At-most-once

A message may be lost if the consumer fails after receiving it but before completing the operation.

Receive message → Acknowledge → Process
                               ↓
                         Process fails

This approach can be suitable when occasional loss is acceptable.

2. At-least-once

The consumer acknowledges the message only after successful processing.

Receive → Process → Save result → Acknowledge

If the consumer crashes after saving the result but before acknowledging, the broker may redeliver the message. The consumer could therefore process it again.

For important business workflows, at-least-once delivery combined with idempotent processing is a common design.

3. Exactly-once

A broker may provide exactly-once guarantees within a particular scope, such as specific stream-processing operations or transactional messaging features. However, that does not automatically guarantee exactly one external effect across a database, payment provider, and email service.

For example, a payment may succeed but the consumer may crash before recording the success. Retrying blindly could charge the customer twice.

Use techniques such as:

• Idempotency keys.
• Unique message IDs.
• Database uniqueness constraints.
• Atomic database transactions.
• Provider-supported idempotency for external operations.

Interview answer: “I usually design consumers for at-least-once delivery and make their business operations idempotent. Exactly-once behavior across distributed systems requires a clearly defined scope and additional coordination; I don't assume the broker alone guarantees it.”

An operation is idempotent if repeating the same operation produces the same final effect as performing it once.

For a message consumer, idempotency prevents a redelivered message from causing duplicate business effects.

Example

Suppose an OrderPlaced message is delivered twice. The consumer should not create two inventory reservations for the same order.

A simple database-backed pattern uses a unique message ID:

CREATE TABLE ProcessedMessages
(
    MessageId UNIQUEIDENTIFIER PRIMARY KEY,
    ProcessedAt DATETIME2 NOT NULL
);

Conceptually, the consumer does the following:

1. Begin a database transaction.
2. Insert the message ID into ProcessedMessages.
3. If the ID already exists, treat the message as already processed.
4. Otherwise, perform the business update.
5. Commit both changes in the same transaction.
6. Acknowledge the message only after the commit succeeds.

The unique constraint handles concurrent attempts to process the same message. The implementation must catch the duplicate-key case and treat it as an already-processed message.

C#-style pseudocode

public async Task HandleAsync(
    OrderPlaced message,
    CancellationToken cancellationToken)
{
    await using var transaction =
        await db.Database.BeginTransactionAsync(
            cancellationToken);

    var alreadyProcessed = await db.ProcessedMessages
        .AnyAsync(x => x.MessageId == message.MessageId,
                  cancellationToken);

    if (alreadyProcessed)
        return;

    db.ProcessedMessages.Add(new ProcessedMessage
    {
        MessageId = message.MessageId,
        ProcessedAt = DateTime.UtcNow
    });

    var order = await db.Orders.FindAsync(
        new object[] { message.OrderId },
        cancellationToken);

    if (order is null)
        throw new InvalidOperationException("Order not found.");

    order.Status = "Processing";

    await db.SaveChangesAsync(cancellationToken);
    await transaction.CommitAsync(cancellationToken);
}

This illustrates the pattern, but production code must handle concurrent duplicates and ensure the transaction's behavior matches the database and broker acknowledgment strategy. A unique constraint remains essential even if the code checks for an existing message first.

Important: This protects database changes in the same transaction. It does not automatically make an external payment API or email send idempotent. For external effects, use provider-supported idempotency keys or a separate reliable workflow.

Interview answer: “Idempotency is essential because messages can be redelivered. I use stable message IDs, database constraints, and atomic transactions to ensure duplicate delivery doesn't repeat the business effect.”

These mechanisms help a messaging system recover from failures without endlessly blocking processing.

Retries

A retry attempts to process a failed message again.

Typical policy:

• Retry transient network or service failures.
• Use exponential backoff to avoid overwhelming an unhealthy dependency.
• Add jitter to spread out retries.
• Limit the number of attempts.
• Do not retry permanent failures indefinitely.

For example, retry after approximately 1, 2, 4, and 8 seconds, subject to a maximum delay and a configured attempt limit.

Dead-letter queue (DLQ)

A DLQ stores messages that cannot be processed successfully under the configured delivery and failure policy.

It allows engineers to inspect failures, identify the cause, and replay or correct messages deliberately.

Common reasons include:

• Maximum delivery attempts exceeded.
• Invalid message schema.
• Missing required business data.
• Unsupported message version.
• A permanent business validation failure.

Poison message

A poison message repeatedly causes processing to fail—for example, a message with invalid JSON that crashes the consumer on every attempt.

Queue

Consumer attempts processing

Transient failure?

Yes

Retry with backoff

No / limit reached

Dead-letter queue

How should a DLQ be managed?

1. Log the message ID, error, and correlation ID.
2. Monitor DLQ depth and age.
3. Alert when messages accumulate.
4. Identify and fix the underlying issue.
5. Replay messages only after checking whether they have already produced a business effect.

Interview answer: “I use bounded retries with exponential backoff for transient failures, then dead-letter messages that cannot be processed. I monitor the DLQ and investigate before replaying messages to avoid duplicates or repeated failures.”

The transactional outbox pattern solves a common distributed-systems problem: saving data in a database and publishing a message are two separate operations.

The dual-write problem

Imagine an Order API:

1. It saves an order to SQL Server.
2. It publishes an OrderPlaced message to a broker.

Two failure cases are possible:

• The database commit succeeds, but publishing the message fails. The order exists, but downstream services never learn about it.
• The message is published, but the database transaction fails. Consumers receive an event for an order that does not exist.

A normal SQL transaction does not atomically commit a separate broker publish.

Solution: transactional outbox

Write the order and an outbox record in the same database transaction.

Single SQL transaction

Insert Order + Insert Outbox message

Outbox Publisher

Reads unsent records and publishes them

Message Broker

Consumers process published events

If the transaction rolls back, neither the order nor its outbox message is committed. If it succeeds, the outbox record remains available for publishing, even if the broker is temporarily unavailable.

Example schema

CREATE TABLE OutboxMessages
(
    Id UNIQUEIDENTIFIER PRIMARY KEY,
    MessageType NVARCHAR(200) NOT NULL,
    Payload NVARCHAR(MAX) NOT NULL,
    CreatedAt DATETIME2 NOT NULL,
    PublishedAt DATETIME2 NULL
);

Implementation approach in .NET

Inside one EF Core transaction:

await using var transaction =
    await db.Database.BeginTransactionAsync(cancellationToken);

db.Orders.Add(order);

db.OutboxMessages.Add(new OutboxMessage
{
    Id = Guid.NewGuid(),
    MessageType = "OrderPlaced",
    Payload = JsonSerializer.Serialize(orderEvent),
    CreatedAt = DateTime.UtcNow
});

await db.SaveChangesAsync(cancellationToken);
await transaction.CommitAsync(cancellationToken);

A separate background publisher then:

1. Reads pending outbox messages.
2. Publishes each message to the broker.
3. Marks messages as published after confirmation.

Important production details

• Use publisher confirmations or the broker's equivalent.
• Make publishing and marking records safe to retry.
• Use locking or leasing to coordinate multiple publisher instances.
• Expect duplicate publication if a crash occurs after publish but before marking the record.
• Make consumers idempotent.
• Monitor outbox backlog and age.
• Consider cleanup or archival of published records.

Interview answer: “The transactional outbox makes the database change and intent to publish atomic. A background publisher eventually delivers the event, while idempotent consumers handle possible duplicate delivery.”

ASP.NET Core provides BackgroundService and IHostedService for running background work inside an application host.

Simple implementation using BackgroundService

public sealed class OrderWorker : BackgroundService
{
    private readonly ILogger<OrderWorker> _logger;

    public OrderWorker(
        ILogger<OrderWorker> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                _logger.LogInformation(
                    "Checking for pending orders");

                // Fetch and process a small batch
                // of pending orders from the database.

                await Task.Delay(
                    TimeSpan.FromSeconds(5),
                    stoppingToken);
            }
            catch (OperationCanceledException)
                when (stoppingToken.IsCancellationRequested)
            {
                break;
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex, "Order worker iteration failed");

                await Task.Delay(
                    TimeSpan.FromSeconds(5),
                    stoppingToken);
            }
        }
    }
}

Register it in Program.cs:

builder.Services.AddHostedService<OrderWorker>();

This demonstrates the worker lifecycle. The database polling, batch selection, concurrency handling, and processing logic still need to be implemented.

Important: scoped dependency injection

EF Core's DbContext is typically registered as a scoped service. Do not inject a scoped DbContext directly into a long-lived singleton worker.

Instead, inject IServiceScopeFactory and create a scope for each processing batch:

public sealed class OrderWorker : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;
    private readonly ILogger<OrderWorker> _logger;

    public OrderWorker(
        IServiceScopeFactory scopeFactory,
        ILogger<OrderWorker> logger)
    {
        _scopeFactory = scopeFactory;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(
        CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                using var scope = _scopeFactory.CreateScope();

                var processor = scope.ServiceProvider
                    .GetRequiredService<IOrderProcessor>();

                await processor.ProcessPendingBatchAsync(
                    stoppingToken);
            }
            catch (OperationCanceledException)
                when (stoppingToken.IsCancellationRequested)
            {
                break;
            }
            catch (Exception ex)
            {
                _logger.LogError(
                    ex, "Background processing failed");

                await Task.Delay(
                    TimeSpan.FromSeconds(5),
                    stoppingToken);
            }
        }
    }
}

Register the dependencies:

builder.Services.AddScoped<IOrderProcessor, OrderProcessor>();
builder.Services.AddHostedService<OrderWorker>();

This assumes IOrderProcessor implements the batch-processing method shown in the example.

When is BackgroundService enough, and when do you need a broker?

Crucial trade-off: An in-memory queue such as Channel<T> is not durable. If the process terminates, queued items can be lost. A background worker also runs within the application lifecycle, so deploying several application instances requires care to avoid duplicate processing.

For Azure-based .NET systems, Azure Service Bus with a BackgroundService consumer is a common combination: the broker handles durable messaging, while the worker hosts the processing code.

This is a common system design interview question. I would start by clarifying the requirements, then design the simplest reliable architecture that meets them.

1. Requirements

Functional requirements

• Customers can place orders.
• Orders are saved and assigned unique IDs.
• Payment and inventory processing happen asynchronously.
• Customers can check order status.
• Failed work can be retried and investigated.

Non-functional requirements

• Handle sudden increases in order traffic.
• Avoid losing accepted orders.
• Support independent scaling of consumers.
• Prevent duplicate charges and inventory reservations.
• Provide observability and failure recovery.

2. High-level architecture

Client / Web Application

Load Balancer / API Gateway

Order API — ASP.NET Core

Validate request, persist order and outbox record

SQL Server

Orders + Outbox, committed in one transaction

Outbox Publisher → Durable Message Broker

For example, Azure Service Bus

Payment Worker

Idempotent payment processing

Inventory Worker

Reserve stock safely

Notification Worker

Send order updates

Monitoring

Logs, metrics, alerts

3. Order-processing flow

1. The client submits an order with a client-generated idempotency key.
2. The API validates the request.
3. In one SQL transaction, the API saves the order and an outbox event.
4. The API returns the order ID and initial status after the database commit. It can use 201 Created when the order resource has been created, even though downstream work is pending.
5. The outbox publisher publishes the event to the durable broker.
6. Payment and inventory consumers process their respective messages.
7. Each consumer records its result safely and acknowledges successful processing.
8. The order's status is updated as the workflow progresses.
9. Notification work is triggered when appropriate.
10. The client polls an order-status endpoint or receives updates through an appropriate push mechanism.

4. How do you handle traffic spikes?

Suppose normal traffic is 100 orders per second, but a promotion increases incoming traffic to 1,000 orders per second.

The broker can buffer messages while consumers process them at a sustainable rate.

I would:

• Scale the API horizontally, subject to database capacity.
• Scale consumers independently based on queue depth, message age, and processing latency.
• Apply concurrency limits to protect SQL Server and payment providers.
• Batch work where appropriate.
• Use backpressure and rate limits to prevent downstream overload.
• Monitor queue growth and increase capacity before the backlog becomes critical.

A queue smooths bursts; it does not create unlimited processing capacity. If the incoming rate continuously exceeds the processing rate, the backlog will keep growing.

5. How do you prevent order loss?

6. How do you maintain correct order status?

I would model the order lifecycle explicitly, for example:

Pending → Processing → Confirmed

Alternative terminal outcomes could include PaymentFailed or Cancelled.

Because multiple services participate, the order workflow is a distributed process. If payment succeeds but inventory reservation fails, the system needs a defined compensation or recovery strategy—for example, refunding the payment if the business rules require it. A distributed workflow may use a Saga pattern rather than a single transaction spanning all services.

7. How do you monitor the system?

Track:

• Orders accepted and completed per second.
• Queue depth and oldest-message age.
• Consumer success and failure rates.
• Retry counts and dead-letter queue depth.
• Payment latency and timeout rates.
• Database CPU, query latency, connection pool pressure, and transaction failures.
• End-to-end order completion time.

Use correlation IDs and structured logs so a single order can be traced across the API, broker, and consumers.

8. Azure implementation choices

For a Microsoft Azure stack, one reasonable implementation is:

• ASP.NET Core Web API hosted on Azure App Service or Azure Container Apps.
• Azure SQL Database or SQL Server, depending on deployment requirements.
• Azure Service Bus for durable messaging.
• BackgroundService consumers hosted in a suitable worker deployment.
• Azure Monitor and Application Insights for metrics, logs, and distributed tracing.

These are implementation options, not mandatory components. The final choices depend on expected throughput, latency, budget, operational requirements, and the existing environment.

Strong interview summary

“I would build an ASP.NET Core Order API backed by SQL Server, using the transactional outbox pattern to ensure that a committed order also has a durable record of the event to publish. Azure Service Bus would buffer work during traffic spikes. Independently scalable consumers would process payment, inventory, and notifications with bounded retries, dead-letter handling, and idempotency. I would monitor queue depth, message age, consumer failures, and database health. For workflows involving multiple services, I would define explicit state transitions and compensation logic rather than relying on a distributed database transaction.”

Day 5 — Final revision sheet

Recommended practice: Explain Q8 and Q10 aloud without looking at the notes. The transactional outbox and the complete order-processing design are particularly useful interview topics for a .NET/Azure backend role.

REST (Representational State Transfer) is an architectural style for designing APIs around resources and standard HTTP semantics.

Key principles

1. Client-server separation: The client handles the user interface; the server handles data and business logic.
2. Stateless communication: Each request contains the information needed to process it. The server does not rely on session state from a previous request.
3. Cacheability: Responses indicate whether they can be cached and under what conditions.
4. Uniform interface: Resources are identified by URLs and manipulated using consistent representations and HTTP methods.
5. Layered system: Clients may communicate through gateways, proxies, or load balancers without needing to know the complete architecture.
6. Code on demand: An optional constraint that allows servers to send executable code to clients.

Example

GET /api/products/101
Authorization: Bearer <token>

The API receives the product ID and authentication credentials in the request. It does not need to remember which server instance handled the user's previous request.

Why is statelessness useful?

Suppose an application runs three API instances behind a load balancer:

             Load Balancer
             /     |     \
          API 1  API 2  API 3

A user's first request might reach API 1 and the next request API 3. If requests are independently authenticated and the application doesn't rely on in-memory session state, any healthy instance can process them.

This improves horizontal scalability and simplifies failover.

Important distinction: Statelessness does not mean that the application has no state. Orders and user information can still be stored in SQL Server or another database. It means that each request does not depend on conversational state retained by a particular server instance.

Interview answer: “REST is a resource-oriented architectural style using standard HTTP semantics. Statelessness means every request contains the information required for processing, making it easier to scale APIs horizontally behind a load balancer.”

These are HTTP methods that express the intended operation on a resource.

GET

GET /api/products/101

Returns a product without changing its business state.

POST

POST /api/products
Content-Type: application/json

{
  "name": "Keyboard",
  "price": 1500
}

Creates a product. Repeating the request may create duplicates unless the API implements deduplication or an idempotency mechanism.

PUT

PUT /api/products/101
Content-Type: application/json

{
  "name": "Mechanical Keyboard",
  "price": 2500
}

Replaces the resource representation. Repeating the same request should leave the resource in the same state.

PATCH

PATCH /api/products/101
Content-Type: application/merge-patch+json

{
  "price": 2700
}

Updates part of a resource. Setting a price to 2700 repeatedly is idempotent in its intended effect. An operation such as “increment price by 100” is not idempotent if repeated.

DELETE

DELETE /api/products/101

The intended effect is to delete the product. A subsequent request might return 404 Not Found rather than the original success status, but the resource remains deleted.

Why does idempotency matter in distributed systems?

Network failures create uncertainty. A client might send a request, the server might complete it, and the response might get lost. The client then retries.

For order creation or payments, use an idempotency key or equivalent deduplication mechanism so retries do not create duplicate business effects.

Interview answer: “GET, PUT, and DELETE are defined as idempotent methods. POST is not guaranteed to be idempotent, and PATCH depends on the patch operation. Idempotency is especially important when clients retry requests after timeouts.”

ASP.NET Core example

[HttpPost]
public async Task<IActionResult> Create(
    CreateProductDto request,
    CancellationToken cancellationToken)
{
    if (!ModelState.IsValid)
        return ValidationProblem(ModelState);

    var product = await _productService.CreateAsync(
        request, cancellationToken);

    return CreatedAtAction(
        nameof(GetById),
        new { id = product.Id },
        product);
}

This returns 201 Created and a Location header pointing to the newly created resource, assuming the GetById action is correctly configured.

For validation, ASP.NET Core controllers using [ApiController] can automatically return a 400 Bad Request when model validation fails.

Two important distinctions

• 401 vs. 403: 401 means valid authentication has not been established; 403 means the authenticated caller is not allowed to perform the operation.
• 201 vs. 202: 201 means the resource has been created. 202 means the request has been accepted for processing, which may still be underway.

For a queued order-processing API, returning 201 after persisting the order can be appropriate even if fulfillment is pending. Returning 202 can be appropriate when the API accepts a job for later execution and exposes a way to check its status.

Interview answer: “I choose status codes based on the API contract and the actual processing state. I use consistent validation and error responses, and I never expose internal exception details in production responses.”

Pagination prevents an API from returning an excessively large result set in one request.

Offset pagination

Example:

GET /api/products?page=4&pageSize=20

For one-based page numbers:

\\[ \text{offset}=(\text{page}-1)\times\text{pageSize} \\]

Page 4 with a page size of 20 means skipping 60 rows and returning the next 20.

ASP.NET Core with EF Core:

var page = Math.Max(1, requestedPage);
var pageSize = Math.Clamp(requestedPageSize, 1, 100);

var products = await db.Products
    .AsNoTracking()
    .OrderBy(p => p.Id)
    .Skip((page - 1) * pageSize)
    .Take(pageSize)
    .ToListAsync(cancellationToken);

Advantages:

• Easy to implement.
• Supports jumping to a particular page.
• Suitable for admin tables and smaller datasets.

Disadvantages:

• Large offsets can be expensive.
• Inserts or deletes between requests can cause records to be repeated or skipped.

Cursor pagination

Example:

GET /api/products?afterId=500&pageSize=20

var pageSize = Math.Clamp(requestedPageSize, 1, 100);

var products = await db.Products
    .AsNoTracking()
    .Where(p => p.Id > afterId)
    .OrderBy(p => p.Id)
    .Take(pageSize)
    .ToListAsync(cancellationToken);

This example assumes IDs are unique and increasing. Production cursor pagination often returns an opaque cursor based on the last item's sort values.

Advantages:

• Efficient for large datasets when supported by an appropriate index.
• Works well for feeds and continuously changing collections.
• Avoids scanning a large number of skipped rows.

Disadvantages:

• Directly jumping to page 100 is difficult.
• Cursor construction and validation require more care.

Comparison

Interview answer: “I use offset pagination when users need numbered pages and the dataset is manageable. For large datasets or feeds, I prefer cursor pagination using indexed, deterministic sort keys.”

I would design the endpoint so clients can retrieve only the records they need, while the database performs filtering, sorting, and pagination.

Example API request

GET /api/v1/products?category=electronics&minPrice=500&maxPrice=5000&sortBy=price&sortDirection=asc&pageSize=20

Step 1: Define a query DTO

public sealed class ProductQuery
{
    public string? Category { get; init; }
    public decimal? MinPrice { get; init; }
    public decimal? MaxPrice { get; init; }
    public string SortBy { get; init; } = "id";
    public string SortDirection { get; init; } = "asc";
    public int PageSize { get; init; } = 20;
}

Validate inputs, including price ranges and allowed sort fields. Clamp or reject excessive page sizes according to the API contract.

Step 2: Build the database query

IQueryable<Product> query = db.Products.AsNoTracking();

if (!string.IsNullOrWhiteSpace(request.Category))
{
    query = query.Where(p => p.Category == request.Category);
}

if (request.MinPrice.HasValue)
{
    query = query.Where(
        p => p.Price >= request.MinPrice.Value);
}

if (request.MaxPrice.HasValue)
{
    query = query.Where(
        p => p.Price <= request.MaxPrice.Value);
}

query = request.SortBy.ToLowerInvariant() switch
{
    "price" => request.SortDirection == "desc"
        ? query.OrderByDescending(p => p.Price)
                .ThenByDescending(p => p.Id)
        : query.OrderBy(p => p.Price)
                .ThenBy(p => p.Id),

    _ => query.OrderBy(p => p.Id)
};

var pageSize = Math.Clamp(request.PageSize, 1, 100);

var products = await query
    .Take(pageSize)
    .Select(p => new ProductDto(
        p.Id, p.Name, p.Price))
    .ToListAsync(cancellationToken);

This illustrates server-side filtering, sorting, projection, and a bounded result size. A real endpoint would also implement the chosen pagination contract—offset or cursor—and validate SortDirection explicitly rather than silently treating all unknown values as ascending.

Step 3: Optimize the database

For millions of rows:

• Add indexes aligned with common filtering and ordering patterns.
• Use AsNoTracking() for read-only EF Core queries.
• Project only the required columns.
• Avoid loading all records into memory before filtering.
• Use cursor pagination for deep traversal where appropriate.
• Check actual query plans and database metrics before adding indexes.
• Consider caching frequently requested, relatively stable results.

Step 4: Return a consistent response

For offset pagination, a response might look like:

{
  "items": [
    {
      "id": 101,
      "name": "Keyboard",
      "price": 1500
    }
  ],
  "page": 1,
  "pageSize": 20,
  "totalCount": 1250
}

totalCount can be expensive for very large or complex filtered queries. Include it when the product requirement justifies the cost; cursor-based APIs often omit it.

Interview answer: “I would validate the query parameters, apply filters and ordering in SQL, use a bounded page size, project only required fields, and create indexes based on real query patterns. For deep pagination, I would consider cursor-based pagination and avoid expensive counts unless required.”

Rate limiting protects an API from excessive traffic and helps preserve capacity for legitimate requests.

1. Fixed-window limiter

Allows a fixed number of requests during each time window.

Example: 100 requests per minute.

If a client sends 100 requests just before a minute ends and another 100 just after the next window starts, it can send 200 requests within a short period.

Best for: Simple quotas and straightforward policies.

2. Sliding-window limiter

Tracks requests across a rolling time interval or estimates usage using adjacent windows.

It reduces the fixed-window boundary problem.

Best for: More consistent request-rate limits.

3. Token-bucket limiter

Tokens replenish at a configured rate up to a maximum capacity. Each request consumes a token.

For example, a bucket may hold 20 tokens and replenish at 5 tokens per second. A client can make a burst of up to 20 requests when the bucket is full, while sustained traffic is constrained by the refill rate.

Best for: APIs that need to permit controlled bursts.

4. Concurrency limiter

Limits the number of requests executing simultaneously, regardless of the number of requests received over a particular time window.

For example, an API might allow at most 50 concurrent report-generation requests.

Best for: Protecting expensive database queries, CPU-heavy operations, or constrained downstream services.

Which would I choose?

For a general public API, I might use a token bucket or sliding-window policy. For expensive operations, I would also consider a concurrency limiter. The right choice depends on whether the goal is to limit request frequency, bursts, or simultaneous work.

Interview answer: “A request-rate limiter controls how frequently a client calls an API, while a concurrency limiter controls how many requests execute simultaneously. I choose the algorithm based on the traffic pattern and the resource being protected.”

First, I would identify the caller reliably, then apply a rate-limit policy based on that identity.

Step 1: Define the policy

For example:

• Authenticated users: 100 requests per minute each.
• Expensive report endpoints: a stricter policy.
• Unauthenticated endpoints: a separate policy, possibly keyed by client IP.

The exact limits should come from capacity testing and business requirements.

Step 2: Configure a partitioned rate limiter

ASP.NET Core supports partitioned rate limiting through AddPolicy and RateLimitPartition.

using System.Security.Claims;
using System.Threading.RateLimiting;

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode =
        StatusCodes.Status429TooManyRequests;

    options.AddPolicy("PerUser", httpContext =>
    {
        var userId = httpContext.User
            .FindFirst(ClaimTypes.NameIdentifier)?.Value;

        var partitionKey = userId ?? "anonymous";

        return RateLimitPartition.GetFixedWindowLimiter(
            partitionKey,
            _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 100,
                Window = TimeSpan.FromMinutes(1),
                QueueLimit = 0,
                AutoReplenishment = true
            });
    });
});

Register the middleware after routing and before mapping endpoints:

app.UseRouting();
app.UseAuthentication();
app.UseRateLimiter();
app.UseAuthorization();

app.MapControllers()
   .RequireRateLimiting("PerUser");

This is a simplified example. In a production application, anonymous users should not all share one partition if that would cause them to interfere with each other. Use a suitable fallback identity, and validate authentication and identity extraction.

The horizontal-scaling problem

Suppose there are three API instances:

              Load Balancer
              /     |     \
           API 1  API 2  API 3

If each instance independently allows 100 requests per minute for a user, the user might effectively receive up to 300 requests per minute across all three instances.

The built-in in-process limiter does not automatically share counters between instances.

Production solutions

1. Gateway-level rate limiting: Enforce shared policies at an API gateway when its features meet the requirements.
2. Distributed rate limiter: Use a shared store or a purpose-built distributed limiting service when accurate cross-instance quotas are needed.
3. Per-instance limits: Use them when approximate aggregate enforcement is acceptable and the policy accounts for instance count.
4. Separate policies by endpoint: Apply stricter quotas to expensive or abuse-prone operations.

Also, do not trust a caller-supplied user ID or arbitrary X-Forwarded-For header as the identity. Authenticate users and configure trusted proxies correctly.

Interview answer: “I would partition requests by authenticated user or tenant and apply a suitable policy. For horizontally scaled deployments, I would enforce shared quotas at a gateway or use distributed coordination if a strict global limit is required.”

API versioning lets an API evolve while supporting existing clients that depend on older contracts.

URL path versioning

GET /api/v1/products
GET /api/v2/products

Advantages: Explicit, easy to discover, and straightforward to route.

Trade-off: The version appears in the URL.

Query-string versioning

GET /api/products?api-version=1.0

Advantages: The resource path stays unchanged.

Trade-off: The version is less visible in the route and must be handled consistently in routing and documentation.

Header-based versioning

GET /api/products
X-API-Version: 2

Advantages: Keeps the URL clean.

Trade-off: The version is less visible when inspecting a URL alone. Caching and diagnostics must account for the header when responses differ by version.

A related approach is media-type versioning, using a versioned Accept header.

How do I choose?

For a straightforward REST API, URL versioning is often easiest for clients and operations teams to understand. Query-string or header-based versioning can be suitable when it better fits the organization's API conventions.

Implementing versioning in ASP.NET Core

One approach is explicit route templates:

[ApiController]
[Route("api/v1/products")]
public sealed class ProductsV1Controller : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new[]
        {
            new { Id = 101, Name = "Keyboard" }
        });
    }
}

A separate controller or endpoint can expose /api/v2/products with the newer contract.

For larger APIs, a versioning library can help with version selection, API Explorer integration, and OpenAPI documentation. The configuration depends on the library and versioning method.

Interview answer: “API versioning lets clients migrate without breaking existing integrations. I choose a clear versioning convention, keep each contract stable, document deprecation, and measure old-version usage before retirement.”

The key principle is backward compatibility: existing clients should continue to work when a new API release is deployed, unless a deliberate breaking change is being introduced through a migration plan.

Example

Version 1 response:

{
  "id": 101,
  "name": "Keyboard"
}

A backward-compatible addition might be:

{
  "id": 101,
  "name": "Keyboard",
  "category": "Electronics"
}

Many clients will tolerate the additional field, but compatibility depends on the client and schema contract. Some strict deserializers or schema validators may reject unknown fields.

A breaking change would be renaming name to productName or changing the type of an existing field without maintaining compatibility.

Best practices

1. Prefer additive changes: Add optional fields instead of removing or renaming existing fields.
2. Avoid changing field meanings: Keep existing semantics stable.
3. Use explicit versions for breaking changes: Support old and new contracts during migration.
4. Publish deprecation timelines: Give clients enough time to upgrade.
5. Measure actual usage: Identify which clients still use the old version.
6. Use automated contract tests: Verify expected request and response shapes.
7. Use observability: Track errors, latency, and version usage.
8. Plan a rollback: Ensure deployment and migration strategies allow recovery if a release causes issues.

Database changes matter too

An API can be backward-compatible at the HTTP layer but still fail if the database schema changes abruptly.

A common deployment strategy is expand and contract:

1. Add the new database field or structure without removing the old one.
2. Deploy application code that supports both representations.
3. Migrate data and clients.
4. Confirm old usage has stopped.
5. Remove the old field in a later release.

Interview answer: “I prefer additive API changes, maintain stable contracts, test compatibility, and use an expand-and-contract database migration strategy. For unavoidable breaking changes, I introduce a new version and deprecate the old one with clear timelines and usage monitoring.”

I would design a read-oriented API that supports efficient database queries, predictable response sizes, controlled traffic, and backward-compatible evolution.

1. Requirements

Functional requirements

• List products.
• Filter by category and price range.
• Sort by supported fields.
• Paginate results.
• Expose versioned API contracts.

Non-functional requirements

• Low latency.
• Support a large product catalog.
• Protect the database from excessive requests.
• Scale horizontally.
• Maintain backward compatibility.

2. High-level architecture

Client

Web app or mobile app

API Gateway

Authentication, quotas, request routing

ASP.NET Core API

Versioning, validation, filtering, pagination

Cache — optional

Redis for suitable repeated queries

SQL Server

Indexes, filtering, sorting, bounded queries

The cache is optional; I would introduce it when repeated reads justify the additional complexity and cache invalidation strategy.

3. Define the API contract

Example request:

GET /api/v1/products?category=electronics&minPrice=500&maxPrice=5000&sortBy=price&sortDirection=asc&pageSize=20&afterId=500

Example response:

{
  "items": [
    {
      "id": 501,
      "name": "Keyboard",
      "price": 1500
    },
    {
      "id": 502,
      "name": "Mouse",
      "price": 2000
    }
  ],
  "nextCursor": "opaque-cursor-value",
  "hasMore": true
}

The cursor is illustrative. In a real implementation, it would encode the last item's sort values, with validation and possibly signing. The example's afterId parameter is appropriate only for ID-based ordering; price ordering requires a cursor containing the relevant sort key and a unique tie-breaker.

4. Optimize the database

I would:

• Filter in SQL instead of retrieving everything into application memory.
• Use deterministic ordering.
• Use cursor pagination for deep traversal of large datasets.
• Add indexes based on the most common filter and sort combinations.
• Use EF Core AsNoTracking() for read-only queries.
• Select only the fields needed by the response.
• Check query plans and performance metrics before making index changes.

5. Protect the API

I would apply rate limits at the gateway or API layer, with separate policies for users or tenants and stricter limits for expensive queries.

When a client exceeds its quota, the API returns 429 Too Many Requests. For horizontally scaled deployments, shared limits may require gateway enforcement or distributed coordination.

6. Support API evolution

I would use /api/v1/products for the current contract and introduce /api/v2/products when a breaking change is required.

I would document both versions, monitor old-version usage, communicate deprecation dates, and remove the old version only after the migration plan allows it.

7. Monitor performance

Key metrics include:

• Request rate and p95/p99 latency.
• HTTP 4xx and 5xx rates.
• Rate-limit rejections.
• Database query latency and connection pool pressure.
• Cache hit rate, if caching is enabled.
• Pagination query performance.

Strong interview summary

“I would design a versioned ASP.NET Core product API behind an API gateway. The API would validate filter and sort parameters, enforce a maximum page size, and use indexed SQL queries with cursor pagination for large datasets. I would implement rate limiting to protect backend capacity, add Redis only where repeated reads justify it, and use metrics to identify bottlenecks. For breaking contract changes, I would introduce a new API version and manage the migration explicitly.”

Day 6 — Quick revision checklist

Explain REST statelessness and horizontal scaling.

Know HTTP methods and idempotency.

Choose appropriate HTTP status codes.

Compare offset and cursor pagination.

Design indexed, bounded queries for large datasets.

Explain four rate-limiting algorithms.

Understand per-user limits across multiple API instances.

Compare URL, query-string, and header-based versioning.

Explain backward-compatible changes and expand-and-contract migrations.

Walk through the complete product API architecture.

0 of 10 revised

Reset

Next: Day 7 — Database Scaling, Replication, Sharding, and Consistency Patterns. This builds on the database fundamentals from Day 3 and applies them to larger system designs.