Forem: umesh kushwaha

🚀 Designing a Flash Sale System That Never Oversells

From 1 User to 1 Million Users (Without Crashing Redis)

umesh kushwaha — Fri, 06 Feb 2026 07:19:05 +0000

Example: Flash sale for 1,000 iPhones with 1,000,000 users clicking “Buy” at the same time.

🧠 Why Flash Sales Are Hard

Flash sales look simple:

“We have 1,000 items. When inventory reaches zero, stop selling.”

But in production, flash sales are one of the hardest problems in distributed systems.

Millions of concurrent requests
Multiple app servers
Eventually consistent caches
Databases that cannot absorb spikes
Redis that can still melt under pressure

The real challenge is not inventory.
It is correctness under extreme contention.

🎯 Core Requirements

❌ No overselling (ever)
⚡ Low latency
🧱 Handle massive traffic spikes
🔥 Protect Redis & database
🛡️ Graceful failure & recovery

🧩 Core Insight

Flash sales are load-shedding problems disguised as inventory problems.

If only 1,000 users can succeed, then 999,000 users must fail fast — cheaply and safely.

1️⃣ Naive Database Approach (Incorrect)

SELECT stock FROM inventory WHERE product_id = 1;

IF stock > 0:
  UPDATE inventory SET stock = stock - 1;
  CREATE order;

❌ What goes wrong

Two requests read stock = 1
Both decrement
Inventory oversold

Verdict: ❌ Incorrect even at low scale.

2️⃣ Database Locking (Correct but Not Scalable)

SELECT stock
FROM inventory
WHERE product_id = 1
FOR UPDATE;

✅ Pros

Strong consistency
No overselling

❌ Cons

Requests serialized
Database becomes bottleneck
Throughput collapses

Use only for very low traffic.

3️⃣ Atomic SQL Update (Better, Still Limited)

UPDATE inventory
SET stock = stock - 1
WHERE product_id = 1 AND stock > 0;

✅ Pros

Simple
Correct

❌ Cons

Database still hot
Does not scale for flash sales

4️⃣ Redis as Inventory Gatekeeper

DECR inventory:iphone

If result < 0 → rollback and reject.

Redis + Lua (Atomic)

local stock = redis.call("GET", KEYS[1])
if tonumber(stock) > 0 then
  redis.call("DECR", KEYS[1])
  return 1
else
  return 0
end

✅ Pros

Very fast
No overselling

🚨 Hidden Problem: Redis Can Still Go Down

Scenario:

Inventory: 1,000
Users: 1,000,000
All users hit the same Redis key

Even Redis has limits:

Single hot shard
Network saturation
CPU contention
Timeouts and failures

Correctness without traffic control is failure.

5️⃣ Mandatory Defense: Early Rejection

Local In-Memory Gate

Each app instance keeps a small local counter.

if localRemaining == 0:
  reject immediately

✅ Pros

Protects Redis massively
Very cheap

❌ Cons

Soft limits
Needs reconciliation

6️⃣ Batch Inventory Allocation (High Impact)

DECRBY inventory:iphone 20

Serve 20 users locally before hitting Redis again.

✅ Pros

Redis calls ≈ inventory count
Huge throughput improvement

❌ Cons

Over-allocation needs give-back logic
Slight fairness skew

7️⃣ Redis Hot Shard Problem & Striping

Single key → single shard → overload.

Solution: Bucketed inventory.

inv:iphone:0
inv:iphone:1
...
inv:iphone:49

✅ Pros

Load distributed across shards

❌ Cons

Retry logic near tail

8️⃣ Token / Permit Model

1 token = 1 purchase. Pre-generate 1,000 tokens.

✅ Pros

Impossible to oversell
Clean mental model

❌ Cons

Token cleanup on failure

9️⃣ Admission Control

Only allow slightly more users than inventory to proceed.

INCR sale:attempts
reject if > 1500

Effect

Redis protected
Fast rejection

🔟 Queue-Based Flash Sale (Extreme Scale)

Users enqueue buy requests
Workers process sequentially
Stop after inventory exhausted

Trade-off

Higher latency
Excellent stability

🔄 Failure Handling

Payment failure: TTL + release inventory
Duplicate clicks: Idempotency keys
Redis crash: Reload from DB
Cache drift: Reconciliation job

⚖️ Trade-off Summary

Approach	Scale	Redis Load	Complexity
DB Lock	Low	None	Low
Redis DECR	High	High	Medium
Batch Allocation	Very High	Low	High
Queue-Based	Extreme	Minimal	High

🏁 Final Thought

A successful flash sale is not about selling fast.
It is about rejecting users correctly while protecting shared state.

If you enjoyed this, follow for more system design deep dives.

🚀 How Uber, Swiggy & Zomato Find the Nearest Delivery Agent in Real Time

umesh kushwaha — Fri, 23 Jan 2026 13:20:22 +0000

Real-Time Matching Architecture Using Redis (Deep Dive)

Finding nearby restaurants is a search problem. Finding a nearby delivery agent is a real-time coordination problem.

This blog focuses on how large-scale systems match a restaurant or user with the nearest available delivery agent in near real time.

1️⃣ Problem Definition

Inputs

Pickup location (restaurant or user)
Thousands of moving agents
Agent state: available, assigned, offline

Output

Exactly one agent assigned
Low ETA
< 100ms decision time

2️⃣ Data Characteristics (Why Search Systems Fail Here)

Attribute	Behavior
Location	Updates every 2–5 seconds
Availability	Highly volatile
Write throughput	Extremely high
Consistency	Near real-time

➡️ This is not a search problem
➡️ This is a real-time in-memory coordination problem

3️⃣ High-Level Architecture


Agent App → Location Updates → Redis (Geo Index)
                                 ↓
Order Created → Matching Service → Availability Filter
                                 ↓
                          Assignment Lock
                                 ↓
                         Notification Service

Key idea: Location, availability, and assignment are separate concerns.

4️⃣ Core Redis Data Structures

1. Location Index (Geo / Geohash)

Stores only where agents are, nothing else.


GEOADD drivers:geo:blr 77.5946 12.9716 driver_123

This structure answers one question:

“Who is physically nearby?”

2. Availability Set (Separate)

Availability is volatile and must not be embedded in geo keys.


SADD drivers:available:blr driver_123

This answers:

“Who is eligible to receive an order?”

3. Assignment Lock (Separate)

Assignment is transient and must be atomic.


SET agent:123:lock order_789 NX EX 10

This ensures:

“No agent is assigned twice.”

5️⃣ Why Availability Must NOT Be Stored with GeoHash

Embedding availability inside geo keys causes serious problems.

Geo + Availability Combined	Separated Structures
Frequent reindexing	Stable geo index
High write amplification	Cheap set updates
Complex cleanup	Simple TTL / set ops
Poor scalability	Horizontal scaling

Rule of thumb:
📍 Geo index answers where
✅ Availability answers who
🔒 Lock answers who wins

6️⃣ Spatial Segmentation (Preprocessing)

To avoid hot keys and large scans, systems segment the map.


geo_cell = geohash(lat, lon, precision=7)

Data layout:


drivers:geo:cell:tdr9k
drivers:available:cell:tdr9k

Each cell is independent and scalable.

7️⃣ Matching Flow (Step-by-Step)

Identify pickup geo cell
Fetch nearby agent IDs from GEO index
Intersect with availability set
Sort by ETA / distance
Attempt assignment via lock

Intersection example:


nearby_agents = GEORADIUS(...)
available_agents = SMEMBERS(...)
candidates = intersection(nearby_agents, available_agents)

8️⃣ Sequential Assignment (Preferred Strategy)

Most delivery platforms use sequential assignment.


for agent in candidates:
    if acquire_lock(agent):
        send_request(agent)
        wait T seconds
        if accepted:
            assign
            break
        else:
            release_lock(agent)

This minimizes agent spam and improves acceptance quality.

9️⃣ Handling Rejections & Timeouts

Timeout → agent returned to availability set
Reject → next best candidate
No response → TTL auto-release

Redis TTLs prevent stuck assignments.

🔟 Write Amplification Control

Agents update location frequently. Mitigations include:

Update only if moved > X meters
Adaptive frequency (slow vs fast movement)
Batch updates

Availability changes are cheap set operations, not geo rewrites.

1️⃣1️⃣ Failure Handling

Failure	Mitigation
Agent crash	TTL expiry
Redis node down	Sharding + replicas
Network lag	Optimistic retries

1️⃣2️⃣ Why Elasticsearch Is the Wrong Tool Here

Elasticsearch	Redis
Index refresh latency	Instant mutation
Disk-based	In-memory
Search optimized	Coordination optimized

Real-time assignment requires Redis.

1️⃣3️⃣ Key Tradeoffs

Decision	Tradeoff
Separate availability	Extra lookup, massive scalability
Sequential assignment	Slight latency, better UX
In-memory only	Speed over durability

Closing Thoughts

Real-time matching systems succeed because they:

Separate location, availability, and assignment
Avoid expensive reindexing
Favor atomic operations

Great architectures don’t overload data structures — they compose them.

How Uber Eats & Zomato Find “Restaurants Near You"

umesh kushwaha — Fri, 23 Jan 2026 12:30:42 +0000

Search & Discovery Architecture for Location-Based Systems (Deep Dive)

Finding nearby restaurants looks simple. At scale, it’s a hard distributed systems problem involving spatial indexing, ranking, freshness, and tradeoffs between accuracy and performance.

This blog deep-dives into Search & Discovery for location-based systems like:

Restaurant discovery (Zomato, Swiggy)
Store search (Blinkit, Instamart)
Nearby places (Google Maps-lite use cases)

1️⃣ Problem Definition

Inputs

User location (latitude, longitude)
Optional text query: “pizza”, “burger”, “south indian”
Filters: open now, rating, price, cuisine
Radius: 1–10 km

Output

Ranked list of nearby restaurants
Sorted by relevance, distance, and business signals

Constraints

Millions of restaurants
Low latency (< 200ms P95)
High read QPS
Data changes, but not every second

2️⃣ Nature of the Data

Understanding data behavior drives architectural decisions.

Attribute	Behavior
Location	Mostly static
Name / Cuisine	Rarely changes
Ratings	Periodic updates
Open / Close status	Time-based
Query pattern	Read-heavy

➡️ This is not a real-time problem
➡️ This is a search and indexing problem

3️⃣ High-Level Architecture


User Request
     ↓
Search API
     ↓
Elasticsearch (Geo + Text)
     ↓
Source DB (Postgres / MySQL)

Optional Redis cache can be added for hot queries.

4️⃣ Why Elasticsearch?

Elasticsearch combines three critical capabilities:

Geo-spatial indexing
Full-text search
Relevance scoring and sorting

Doing all three efficiently in a relational database becomes painful at scale.

5️⃣ Location Modeling

Geo Point Mapping

{
  "location": {
    "type": "geo_point"
  }
}

This allows Elasticsearch to index latitude and longitude efficiently.

6️⃣ Geo Distance Query

{
  "query": {
    "bool": {
      "filter": {
        "geo_distance": {
          "distance": "5km",
          "location": {
            "lat": 12.9716,
            "lon": 77.5946
          }
        }
      }
    }
  }
}

This avoids full scans and only evaluates nearby spatial segments.

7️⃣ How Elasticsearch Computes “Nearby”

Elasticsearch performs spatial preprocessing using:

BKD Trees
Geohash-based partitioning

Restaurants are indexed into spatial cells. Queries only scan nearby cells.

Distance is calculated inflight only for filtered candidates.

8️⃣ Preprocessing vs Inflight Computation

Aspect	Preprocessing	Inflight
Spatial segmentation	✅	❌
Distance calculation	❌	✅
Text relevance	❌	✅

9️⃣ Full-Text + Geo Search

Example: “pizza near me”

{
  "query": {
    "bool": {
      "must": {
        "match": {
          "cuisine": "pizza"
        }
      },
      "filter": {
        "geo_distance": {
          "distance": "3km",
          "location": {
            "lat": 12.97,
            "lon": 77.59
          }
        }
      }
    }
  }
}

🔟 Ranking Strategy

Distance alone is insufficient.

Typical conceptual scoring:


Final Score =
  Text Relevance
+ Rating Weight
+ Popularity Score
- Distance Penalty

Scripted Sorting Example

{
  "_script": {
    "type": "number",
    "script": {
      "source": "doc['rating'].value * 2 - doc['distance'].value"
    },
    "order": "desc"
  }
}

1️⃣1️⃣ Radius Search Tradeoffs

Small radius → faster, fewer results
Large radius → slower, noisier results
Dynamic radius → best UX

Common approach: start small, expand if results are insufficient.

1️⃣2️⃣ Caching with Redis

Caching is optional but useful for hot locations.

Example cache key:


city:blr:lat:12.97:lon:77.59:radius:3km

TTL should be short (5–15 minutes).

1️⃣3️⃣ Why Not Redis GEO for Discovery?

Redis GEO	Elasticsearch
Fast	Slightly slower
No full-text	Full-text search
No ranking	Advanced ranking
Memory-heavy	Disk-backed

Redis GEO is better suited for real-time driver matching.

1️⃣4️⃣ Postgres + PostGIS?

It works, but with limitations.

Good for early-stage systems
Hard to scale ranking logic
Search complexity grows quickly

At scale, Elasticsearch wins.

1️⃣5️⃣ Data Freshness

Ratings → async index updates
Menu changes → delayed propagation
Location changes → extremely rare

Near real-time consistency is acceptable for discovery.

1️⃣6️⃣ Key Tradeoffs

Elasticsearch complexity vs scalability
Preprocessing vs storage cost
Composite ranking vs explainability
Caching vs freshness

Closing Thoughts

Search & Discovery is fundamentally:

An indexing problem
A ranking problem
A read-scalability problem

Spring Boot vs .NET Core: Complete Developer Migration Guide

umesh kushwaha — Tue, 04 Mar 2025 13:40:00 +0000

Whether you’re moving from Spring Boot to .NET Core or vice versa — your transition guide is here

Supported Languages

Both frameworks allow development in multiple languages, but Spring Boot is tied to JVM-based languages, while .NET Core is more flexible with multiple language options.

Supported Build Tools

Spring Boot primarily uses Maven or Gradle, while .NET Core uses MSBuild and dotnet CLI. Dependency management is handled via Maven/Gradle in Spring Boot and NuGet in .NET Core.

Supported IDEs for Development

You can choose any IDE what ever suits to you. I prefer IntelliJ for Spring Boot and VS Code for .Net Core.

Supported Embedded Servers

Spring Boot applications typically run on Tomcat by default but can be configured to use Jetty or Undertow. .NET Core applications use Kestrel by default but can be hosted behind IIS, HTTP.sys, or Nginx.

Project Setup & Structure

Spring Boot Project Structure

A typical Spring Boot project structure with multiple environment properties:

.NET Core Project Structure

A typical .NET Core project structure with multiple environment settings:

Both frameworks separate concerns using MVC architecture and include configuration files for managing environments. Additionally, both have a dedicated test structure to ensure test-driven development.

Application Initialization

Spring Boot Initialization

Spring Boot applications are initialized using SpringApplication.run() in the main method:

.NET Core Initialization

.NET Core applications are initialized using CreateDefaultBuilder() in Program.cs:

Startup Sequence & Main Application Entry Points

Spring Boot handles configuration automatically using SpringApplication.run(), while .NET Core provides more explicit control via Program.cs and Startup.cs.

Dependency Injection

Both Spring Boot and .NET Core support Dependency Injection (DI) for managing application components.

Registering Dependencies in Spring Boot

Registering Dependencies in .NET Core

Both frameworks support dependency injection, but while Spring Boot uses annotations, .NET Core relies on explicit configuration in Startup.cs.

CRUD Operations with ORM

Spring Boot CRUD Example

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;

    // Getters and Setters
}

@Repository
public interface UserRepository extends JpaRepository<User, Long> {}

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public User createUser(User user) {
        return userRepository.save(user);
    }

    public List<User> getAllUsers() {
        return userRepository.findAll();
    }

    public User updateUser(Long id, User userDetails) {
        User user = userRepository.findById(id).orElseThrow();
        user.setName(userDetails.getName());
        user.setEmail(userDetails.getEmail());
        return userRepository.save(user);
    }

    public void deleteUser(Long id) {
        userRepository.deleteById(id);
    }
}

@RestController
@RequestMapping("/users")
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping
    public User createUser(@RequestBody User user) {
        return userService.createUser(user);
    }

    @GetMapping
    public List<User> getAllUsers() {
        return userService.getAllUsers();
    }

    @PutMapping("/{id}")
    public User updateUser(@PathVariable Long id, @RequestBody User userDetails) {
        return userService.updateUser(id, userDetails);
    }

    @DeleteMapping("/{id}")
    public void deleteUser(@PathVariable Long id) {
        userService.deleteUser(id);
    }
}

.NET Core CRUD Example

public class User {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

public class UserService
{
    private readonly AppDbContext _context;
    public UserService(AppDbContext context) {
        _context = context;
    }
    public User CreateUser(User user) {
        _context.Users.Add(user);
        _context.SaveChanges();
        return user;
    }
    public IEnumerable<User> GetAllUsers() {
        return _context.Users.ToList();
    }
    public User UpdateUser(int id, User userDetails) {
        var user = _context.Users.Find(id);
        user.Name = userDetails.Name;
        user.Email = userDetails.Email;
        _context.SaveChanges();
        return user;
    }
    public void DeleteUser(int id) {
        var user = _context.Users.Find(id);
        _context.Users.Remove(user);
        _context.SaveChanges();
    }
}

[Route("api/users")]
[ApiController]
public class UserController : ControllerBase
{
    private readonly UserService _userService;
    public UserController(UserService userService) {
        _userService = userService;
    }
    [HttpPost]
    public ActionResult<User> CreateUser(User user) {
        return Ok(_userService.CreateUser(user));
    }
    [HttpGet]
    public ActionResult<IEnumerable<User>> GetUsers() {
        return Ok(_userService.GetAllUsers());
    }
    [HttpPut("{id}")]
    public ActionResult<User> UpdateUser(int id, User userDetails) {
        return Ok(_userService.UpdateUser(id, userDetails));
    }
    [HttpDelete("{id}")]
    public IActionResult DeleteUser(int id) {
        _userService.DeleteUser(id);
        return NoContent();
    }
}

Here are the key differences between the CRUD approaches in Spring Boot and .NET Core:

![]

Authentication & Authorization

Spring Boot Security

Dependency

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.11.2</version>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Security Configuration & Controller

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Autowired
    private UserDetailsService userDetailsService;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
            .authorizeRequests()
            .antMatchers("/auth/**").permitAll()
            .anyRequest().authenticated()
            .and()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);
    }
}

@RestController
@RequestMapping("/auth")
public class AuthController {
    @PostMapping("/login")
    public ResponseEntity<String> login(@RequestBody LoginRequest request) {
        // Authenticate and generate JWT token
        return ResponseEntity.ok("JWT-TOKEN");
    }
}

.NET Core Identity Authentication

Install Required Packages

dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer

Identity Configuration

public class ApplicationUser : IdentityUser {}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser> {
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options) { }
}

Authentication Middleware in Startup.cs

public void ConfigureServices(IServiceCollection services) {
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores<ApplicationDbContext>()
        .AddDefaultTokenProviders();

    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options => {
            options.RequireHttpsMetadata = false;
            options.SaveToken = true;
            options.TokenValidationParameters = new TokenValidationParameters {
                ValidateIssuerSigningKey = true,
                IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("YOUR_SECRET_KEY")),
                ValidateIssuer = false,
                ValidateAudience = false
            };
        });
}

public void Configure(IApplicationBuilder app) {
    app.UseAuthentication();
    app.UseAuthorization();
}

Controller for Authentication

[ApiController]
[Route("api/auth")]
public class AuthController : ControllerBase {
    private readonly SignInManager<ApplicationUser> _signInManager;
    private readonly UserManager<ApplicationUser> _userManager;

    public AuthController(UserManager<ApplicationUser> userManager, SignInManager<ApplicationUser> signInManager) {
        _userManager = userManager;
        _signInManager = signInManager;
    }

    [HttpPost("login")]
    public async Task<IActionResult> Login([FromBody] LoginRequest request) {
        var result = await _signInManager.PasswordSignInAsync(request.Username, request.Password, false, false);
        if (result.Succeeded) {
            return Ok("JWT-TOKEN");
        }
        return Unauthorized();
    }
}

Key differences between Spring security & .NET core Identity framework

Writing Unit Tests (TDD Approach)

Unit Testing Frameworks

Sample Unit Test — Spring Boot

@SpringBootTest
@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    public void testGetUserById() {
        User user = new User(1L, "John Doe");
        Mockito.when(userRepository.findById(1L)).thenReturn(Optional.of(user));

        User result = userService.getUserById(1L);
        assertEquals("John Doe", result.getName());
    }
}

Sample Unit Test — .NET Core

public class UserServiceTest {
    private readonly Mock<IUserRepository> _userRepositoryMock;
    private readonly UserService _userService;

    public UserServiceTest() {
        _userRepositoryMock = new Mock<IUserRepository>();
        _userService = new UserService(_userRepositoryMock.Object);
    }

    [Fact]
    public void TestGetUserById() {
        var user = new User { Id = 1, Name = "John Doe" };
        _userRepositoryMock.Setup(repo => repo.GetById(1)).Returns(user);

        var result = _userService.GetUserById(1);
        Assert.Equal("John Doe", result.Name);
    }
}

Running & Testing the Application

Spring Boot

.NET Core

References

Spring Boot

.NET Core