9 posts
Grouping 10,000+ same-category notifications into one third-party group meant the chunks a batch server throws as jobs get consumed asynchronously. Where waiting-children fits in keeping one group and one send on top of that, and how five races were closed one by one and verified with invariants.
The sending quota was 100 messages per 5 seconds and our average was 20 req/s. On paper we were inside the limit, yet 429s kept appearing. Two fixed windows whose start times were not aligned turned out to be the cause, and the fact that another team shared the same third-party account pushed us to redesign the sending path itself.
Every service needs to send messages to users, whether through AlimTalk, email, or push notifications. But implementing notification delivery as a simple HTTP call quickly runs into limits. Each problem can be solved with another tool: consolidate delivery into one module, enforce a rate limit inside the function, create timing branches with a scheduler, and record delivery…
Kubernetes provides two kinds of probes for determining a Pod's state. A liveness probe asks, "Is this container alive?" The kubelet periodically calls a configured endpoint and restarts the container if the call fails or receives no response. This automatically recovers an application that has become unresponsive because of a deadlock or memory leak.
An event is being held to celebrate a celebrity's visit, with tickets available only to the first 1,000 people. Applications will be accepted through a web application. Suppose you protect the system with a distributed lock. Are you confident that concurrency is now completely under control?
This article continues from the previous post, "Understanding Pessimistic Locks Through a Like Feature." It corrects the misconception that "Lettuce supports only spin locks" and explains how Spring RedisLockRegistry's Pub/Sub lock mode can implement an efficient distributed lock without Redisson.
This article follows the process of solving the concurrency problems in a like feature with database locks. It explains how pessimistic locking works and examines the performance degradation caused by next-key locks.
Suppose we are designing a first-come, first-served event system. The requirements are listed below. If 1,000 people request 100 available items at the same time, how can we ensure that exactly 100 people receive one? The solutions commonly proposed in this situation are listed below.
Our team began a project integrating with an external system. The requirement seemed simple: "We need to use an external API to determine whether an order can be placed on a given date." In practice, however, giving customers accurate information required fetching 40–60 date-specific delivery plans at once on a single screen. Even with parallel processing…