AI Briefing
KO

Kurly OMS Achieves High-Efficiency Operations for Small Teams with Shared Cache-Based MSA

·2025.05.09 00:00

Key point

Kurly's OMS team secured stable order processing and deployment efficiency with a small workforce through a Shared Cache architecture and MSA separation.

Details

Kurly OMS performs the role of an 'order interpreter' that converts orders from sales channels into fulfillment information, and has enhanced stability and efficiency by applying a microservices architecture (MSA) centered on Shared Cache. This structure clarifies data ownership by having a specific MSA write frequently used data while the rest access it as Read Only, preventing traffic from propagating to internal MSAs.

Shared Cache Architecture and Stability Strategy

Shared Cache is designed so that API requests with high traffic, such as 'order information lookup,' are almost entirely served by the cache alone. This reduces network costs for internal MSAs and keeps the system stable even during peak traffic at 23:00, the order cutoff time for Kurlymall. However, since a cache failure could overload MSA instances running on minimal specs, Auto Scale Out rules are set conservatively, taking into account both cache hit rate and memory size in a combined manner.

Streamlining MSA Operations for a Small Team

A small team consisting of 1 PM and 3 engineers minimized development conflicts by separating MSAs into independent functional units. For example, when developing the order return/pickup feature, tickets were distributed so that return order registration (Operation API), courier pickup registration (Order), and inspection status management (Tracking) were developed simultaneously in different MSAs. This approach prevents source code conflicts and enables independent deployment and monitoring.

Deployment and Technology Stack Composition

The MSA structure has enabled preemptive deployment similar to canary deployment. Before the final full deployment, a specific MSA can be deployed first to preemptively catch issues, and this is also used for canary version-up testing of libraries. The technology stack combines Spring MVC and Spring WebFlux depending on service characteristics, and the architecture was not converted all at once at a specific point in time but gradually took root as a shared concept within the team.

This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.

Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.