How did Olive Young Store integrate scattered domain data in an MSA environment?

Olive Young Store is a core O2O service that lets customers find nearby stores in the app and check store-specific inventory, promotions, and pickup order status. It has been enhanced through Phase 1 and Phase 2, and most recently completed Phase 3, a revamp of in-store events and promotions.

In an MSA environment, the Store squad, Coupon Issuance squad, and Order/Payment squad each manage different domain data. So rather than simply attaching APIs, the team first decided which integration method to use based on where the data is used, its change characteristics, and its lifecycle.

Offline promotion data changes infrequently and has clear start and end dates. Since fast responses were needed even under heavy traffic, the team ruled out both calling the API every time and saving to S3 once a day, and instead chose a Cache-Aside pattern using API calls as needed + Redis cache.

This approach calls the original API only when an update is needed and stores the result in Redis for reuse. Ended promotions are automatically deleted via periodic batch jobs, and data changed during operation is also reflected through cache updates—securing efficiency, stability, and accuracy all at once.

Pickup order data, on the other hand, undergoes frequent status changes such as order cancellations or ready-for-pickup notifications, and is heavy data that includes product information, amounts, and even customer information. A simple cache alone could lose freshness, and hitting the API on every request would place a heavy load on the providing server, so a different approach was needed.

Here, a hybrid of Kafka Event-Driven + Redis Key cache was applied. When an order status changes, a Kafka event is received, and the Olive Young Store service stores only minimal identifiers such as member number and order number in Redis. When a customer enters the pickup dashboard, the API is called to fetch detailed data only if the Key exists in Redis, reducing unnecessary calls while still showing the latest status.

The key point is that not all data is loaded into the event—instead, the team used an Event Notification pattern that only receives a "status has changed" notification and looks up details only when needed. This keeps Kafka messages lightweight while still providing near-real-time pickup status to the customer screen.

In the end, this revamp offers two lessons.

• Data characteristics determine the integration strategy: infrequently changing promotions used Redis cache, while frequently changing pickup orders used Kafka events + Redis cache.
• The data consumer should lead the integration design: the side that actually uses the data knows best where and how it's used throughout its lifecycle, so in MSA the consumer's perspective should be central to decision-making.

Even for the same kind of data integration, there isn't just one right answer—ultimately, what mattered was understanding the essence of the data and combining approaches accordingly.