Preventing duplicate marketplace orders

Problem

Marketplace orders didn’t enter the system through a single path: the regular sync job, the marketplace’s instant notifications, a manual “fetch orders” in the admin panel and the stock sync could all call the same order creation flow. Because these paths really could run at the same time, the same order was occasionally created twice seconds apart, and both copies could be handed to the carrier. There was a cleanup job that deleted these records afterwards; it didn’t solve the problem, it hid it.

Trendyol had a second issue: when a customer cancels part of an order, Trendyol closes the old package and opens a new package with the remaining items. Unaware of this, the system left the order on the closed package and could process the same cancellation over and over.

Approach

• Root cause first: We evaluated the “let’s just put everything in a queue” proposal; the problem wasn’t the lack of a queue, it was that these paths didn’t share a common lock.
• A shared per-order lock: Every order creation path across the five integrations (Trendyol, Hepsiburada, N11, Propars, ikas) uses the same lock. If the lock can’t be acquired, the job retries shortly after.
• Following the new package: When a Trendyol partial cancellation arrives, the new package is located, the order is moved to it and its items are matched against the package contents.
• Mark instead of delete: Cancelled lines are no longer deleted but marked as cancelled, so already-invoiced orders aren’t corrupted.
• Last line of defense: A database-level rule that prevents the same order from being saved twice.

Lessons learned

• With duplicate record problems, you need to prevent the record from being created twice in the first place rather than cleaning up afterwards.
• When marketplace documentation fell short, collecting real data and deriving the behavior from it was the most reliable approach.

My contribution

I did the root cause analysis, the solution design, the implementation and the tests.