Kurly Pay · 2022.09 — 2023.12

Improving the Kurly Mall Gift Card Purchase Process

  • Redesigned data inconsistencies during failures into a Kafka-based eventually consistent structure that could self-recover, connecting the Go legacy with the new Kotlin/Spring flow

Background

After launch, any failure caused data inconsistencies between Kurly and Kurly Pay, requiring operators to respond manually.
With the legacy Go logic and the new Kotlin/Spring flow coexisting, we needed a way to connect the two flows while restoring consistency.

Outcomes

  • Redesigned the structure into Kafka-based eventual consistency capable of self-recovering during failures
  • Established a foundation for gradual migration while running the Go legacy and the new Kotlin/Spring flow simultaneously

Details

Problem analysis and TO-BE design

Problem / TO-BE summary

Summary of the failure-driven inconsistency problem and the TO-BE design.

Architecture change

AS-IS (polling-based)

TO-BE (Kafka event-based)

Polling-based architecture

AS-IS polling-based architecture between Kurly and Kurly Pay.

Kafka event-based architecture

TO-BE Kafka event-based architecture enabling eventual consistency.

Other operational considerations

Abuse scenarios

Analysis of abuse scenarios considered during the redesign.

3P Partner Office integration wiki structure

Wiki structure documenting the 3P Partner Office integration.