A Ticketing System That Can Theoretically Handle 100,000 QPS
The first 1,000 tickets go through a web app behind a distributed lock. Does that lock actually keep concurrency under control when the rush hits?
9 posts

The first 1,000 tickets go through a web app behind a distributed lock. Does that lock actually keep concurrency under control when the rush hits?

Spring AOP pulls distributed-lock code out of business logic. A DistributedLock aspect modeled on @Transactional, with a SpEL key evaluator like Spring Cache.

Lettuce is not limited to spin locks. How Spring RedisLockRegistry's Pub/Sub lock mode builds an efficient distributed lock without Redisson.

Like-button races, solved with database locks. How pessimistic locking works, and how next-key locks slow the check for whether a review was already liked.

How the JVM monitor behind synchronized works, what ReentrantLock adds, and a producer-consumer fix. Then lock striping on per-user keys to raise throughput.

Network I/O was blocking threads. JDK 21 virtual threads fixed that, then pinning and overwhelming showed up. How each one was handled.

1,000 people request 100 items at once. How a single UPDATE gives one to exactly 100 of them, instead of the locks usually proposed for a first-come event.

Loading 40–60 delivery plans per screen from an external API was slow. Redis and local caches made it 50–100x faster, and Redis Pub/Sub kept servers in sync.

A healthy production system can slow down and fail from one overlooked line. How a small memory-management mistake becomes an outage.