Kurly Builds AccessBlock System to Block Service Maintenance at the Application Level Without nginx

Kurly's Inbound Product Development Team introduced the AccessBlock system to resolve stacking errors that occurred during Inventory DB maintenance. Due to slow response times and permission issues with the existing infrastructure team's nginx configuration changes, they adopted an approach that blocks access directly at the application level.

Initial AccessBlock Implementation and Limitations

The initial version operated based on MySQL's access_block and access_block_group tables. During page routing, the frontend called an API to check block status and validate the URL, redirecting to a maintenance page upon a match. This approach provided the additional benefit of enabling immediate logout processing without nginx access, but had a critical limitation: the AccessBlock data itself became inaccessible during DB maintenance.

Removing RDBMS Dependency Through Redis Caching

To maintain blocking functionality even during DB outages, the system was upgraded with a caching strategy using Redis. MySQL is now used only as a metadata source, while actual block status determination was changed to reference Redis's BLOCKED_..._ID_LIST data structure. When toggle status changes, the Redis data structure is immediately updated, and lookup APIs read Redis values instead of the RDBMS, improving response speed.

Remaining Challenges and Future Plans

The current system can check block status even during a complete RMS DB outage, but registering and modifying new metadata still depends on the RDBMS. To solve the problem of being unable to change metadata during DB outages, providing an intuitive table lookup and modification UI and completely removing RDBMS dependency remain as future tasks.