External Sellers: How to Protect Internal Systems from Spiky External Traffic (Part 1)
Key point
Oliveyoung's external seller service introduced an architecture that protects internal systems from spiky traffic through asynchronous processing and service separation.
Details
The existing external seller service connected requests from shopping mall integration management solutions to Oliveyoung's internal API in a synchronous (Sync) manner. This approach had limitations: when internal API responses were delayed, it caused CPU and Memory load on the external seller service, and users experienced long wait times and network errors.
To solve this, Oliveyoung introduced an asynchronous (Async) event-driven architecture. The service's roles were separated into request handling (seller-external-api) and creation handling (seller-internal-api), with AWS MSK introduced in between to buffer traffic.
- Request handling service: After essential validation, it delivers events to MSK to provide fast responses to users.
- Creation handling service: Consumes events from MSK and sequentially delivers them to the internal API, ensuring stability through Retry logic in case network issues occur.
Additionally, to guarantee data processing order in a distributed environment, a Partition Key was designated so that identical product requests are always loaded into the same partition.
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.