Mert Özen Further With Every Line

Blog

Mert Özen's blog posts on software development, backend, frontend, and DevOps.

Series
4 posts found #case-study
System Design Case Study: Flash Sales and Ticketing
Software Architecture PART 15

System Design Case Study: Flash Sales and Ticketing

What prevents overselling in a flash sale is doing the stock check and the decrement in a single atomic step; a waiting room served from a CDN absorbs the spike, holds with a TTL manage the payment window, and expired holds return stock in the same statement. Real output with 2,000 concurrent buyers for 100 tickets: 2,000 reservations from naive code, a conditional UPDATE and optimistic concurrency, plus payment timeouts and bot defense.

8 Nov 2026 13 min 5
System Design Case Study: Chat and Notification System
Software Architecture PART 14

System Design Case Study: Chat and Notification System

In a chat system, connections live on stateful gateways while order and storage live in a stateless chat service: a message is stored first, gets a sequence number from a per-conversation server counter, the recipient's gateway is found through presence, and offline recipients get a push. Real output for routing between two gateways with Redis and for ordering, deduplication and gap detection by seq on the client, read receipts, group fan-out and message storage.

8 Nov 2026 11 min 4
System Design Case Study: News Feed and Timeline
Software Architecture PART 13

System Design Case Study: News Feed and Timeline

Fan-out on write is the default for a news feed, but because followers follow a power law, a single celebrity post turns into a million writes; the fix is a hybrid model that merges accounts above a high threshold at read time, a feed cache holding only post IDs, and cursor pagination. A computed capacity table, a push, pull and hybrid simulation, and real output comparing offset and cursor on a Redis sorted set.

8 Nov 2026 11 min 4
System Design Case Study: Designing a URL Shortener
Software Architecture PART 12

System Design Case Study: Designing a URL Shortener

A URL shortener is a read-heavy system: ~3,900 redirects against ~40 writes per second, so it needs a stateless redirect path, cache-aside, codes that never collide and are hard to guess, and 302 rather than 301 for analytics. A computed capacity table, a real measurement of hash collisions, counter + bijective mapping + base62, 301/302 curl output, aliases, expiration and abuse.

8 Nov 2026 12 min 4
Blog Map