DEV Community: yanmoheluo

Laravel Exchange Rate Service: How We Solved Multi-Currency Refund Disputes

yanmoheluo — Wed, 10 Jun 2026 09:09:24 +0000

"I paid 102.30, and you returned 99.85? That’s not a refund, that’s a penalty."

Alex had ordered sneakers from our cross-border platform — ¥16,500, which came out to €102.30 at the time of payment. A few days later the size didn’t fit, so he requested a refund. Everything went smoothly from an operations standpoint … until the money hit his card.

We sent back ¥16,500, but the yen-to-euro rate had moved since his purchase. He got €99.85 — €2.45 less than he paid. The root cause wasn’t a calculation error. It was our naive exchange rate handling: we were using whatever rate was current at the time of the refund, not the rate at the time of the original payment.

The Real Problem: A Drifting Exchange Rate

Our platform is a Laravel monolith that powers a marketplace connecting European buyers with Japanese sneaker sellers. Order amounts are captured in the seller’s local currency — yen. But we charge customers in their preferred currency (euros, dollars, etc.), and all the financial reporting is in yet another base currency. That meant every money‑moving operation crossed a rate boundary.

For a purchase, we would fetch the live rate from an external provider, convert the total, and charge the customer. The order record only stored the final converted amount and the currency, not the rate itself. When a refund was triggered, the system simply fetched the current rate again and used it to calculate the refund amount in the customer’s currency. If the yen had weakened against the euro between purchase and refund, the customer lost money. If it had strengthened, we lost money. Either way, someone was unhappy.

The fix was obvious in hindsight: we needed to pin the exchange rate to the order at the moment of creation, and then reuse that exact same rate for any subsequent financial event — refunds, partial refunds, chargebacks, everything.

Building a Laravel Exchange Rate Service That Actually Works

We introduced an OrderExchangeRate model and a dedicated service class to handle rate capture and retrieval. The service’s job is simple:

When an order is placed, fetch the live rate and store it together with the order.
When a refund is initiated, retrieve that stored rate — avoid hitting the API again.
Fall back gracefully if no rate is found (which shouldn’t happen, but paranoia pays).

Here’s the core of the service:

namespace App\Services;

use App\Models\OrderExchangeRate;
use App\Services\ExchangeRateProvider;
use Illuminate\Support\Facades\Log;

class ExchangeRateService
{

public function captureRateForOrder(int $orderId, string $from, string $to): void

{

try {

$rate = app(ExchangeRateProvider::class)->getRate($from, $to);

} catch (\Throwable $e) {

Log::error('Failed to fetch rate for order', [

'order_id' => $orderId,

'exception' => $e->getMessage(),

]);

throw $e;

}

OrderExchangeRate::create([

'order_id' => $orderId,

'from_currency' => $from,

'to_currency' => $to,

'rate' => $rate,

'captured_at' => now(),

]);

}
}
The `ExchangeRateProvider` is just a thin wrapper around the actual rate API (we used Fixer, later switched to the ECB feed for cost reasons). The important part is that the rate is captured *exactly once* and stored immutably. No drifting.

Then, when a refund is initiated, we look up that stored rate:

php
public function getRateForOrder(int $orderId): float
{

$rate = OrderExchangeRate::where('order_id', $orderId)

->latest('captured_at')

->value('rate');

if (!$rate) {

Log::warning('No stored rate found for order, falling back', [

'order_id' => $orderId,

]);

// Emergency fallback – fetch live, but not for refund calculation

// This path should be extremely rare and trigger an alert

return app(ExchangeRateProvider::class)->getRate('JPY', 'EUR');

}

return $rate;
}
Notice the fallback – it’s deliberately kept as a last resort. In production we haven’t hit it because the capture happens in the same database transaction as the order creation. But having it there, with a loud log, saved us one night when a deployment script accidentally dropped a handful of rate records. Knowing exactly which orders were affected let us manually recalculate the refunds before any customer noticed.




## A Note on Caching

A common temptation is to cache rates in Redis to avoid the API call on every order. We did that too – until we realized that a 5‑minute cache window could still mean two orders placed seconds apart would use slightly different rates. That’s fine for display purposes, but for money‑locking, every order needs its own point‑in‑time snapshot. So we kept the rate capture per‑order, and used a short‑lived cache only for the order‑creation page’s currency conversion preview. The actual payment captured the rate afresh and stored it.

In a project I reviewed later — Taocarts, a cross‑border e‑commerce SaaS — they handle this similarly. Each order carries its own exchange rate, and refunds consistently reference that original rate. The lesson is the same everywhere: exchange rates are not a global variable.

## The Impact: From Angry Tickets to Boring Books

After rolling out the exchange rate service, the number of refund‑related disputes dropped to practically zero. Before, we averaged 3–5 complaints per month about refund amounts being off. In the eight months since, we’ve had one — and that one turned out to be a double‑charge caused by a payment gateway callback retry, not a rate issue.

The other win was on the accounting side. With every order pinned to a known rate, our finance team stopped spending hours reconciling currency‑conversion discrepancies at month‑end. The "books don’t match" meetings became 10‑minute check‑ins rather than multi‑day investigations.

## Lessons Learned (the Hard Way)

* **Don’t use a live rate for money that already moved.** The moment a payment is captured, the exchange rate becomes part of the transaction’s DNA. Storing it in the order record is cheap; customer trust isn’t.
* **Store the rate, not just the converted amount.** If you only store the final amount, you can’t reverse‑engineer the correct rate for partial refunds, and you lose the ability to provide transparency to the customer.
* **Fallbacks are dangerous, but necessary.** Design for the impossible. A missing rate record is an edge case that shouldn’t exist, but when it does, a clear log entry and an alert are worth more than an automatic “fix.”
* **The exchange rate service doesn’t need to be complex.** A single model, two methods, and a database column. The complexity isn’t in the code — it’s in realising you need it in the first place.

Looking back, the €2.45 that sparked all this work was the best unexpected investment. Alex eventually got his full refund — manually, while we were fixing the system — and stayed a customer. That’s the part that stuck with me: a €2.45 rounding error nearly lost us a customer, and fixing it was cheaper than any ad campaign.

These days our refund disputes are close to zero — one incident in eight months, and that was a gateway retry. One model, two methods, and a database column.

The key takeaway: capture the rate once and trust that snapshot. Have you faced similar refund issues?

DESCRIPTION: Storing exchange rates at order creation prevents multi-currency refund disputes.

Daigou Code: How We Solved Payment Reconciliation Nightmares in Cross-border Order Management

yanmoheluo — Thu, 04 Jun 2026 10:18:23 +0000

Last month, a client pulled me into their finance Slack channel. Their operations lead had spent four nights reconciling orders from the previous quarter. The ledger showed total revenue around $47,000, but the payment gateway settlement came in at just over $45,200. Almost two grand missing.

The usual suspects were innocent: gateway fees matched the contract, refunds were accounted for, exchange rates didn't explain that gap. Three days later we found it — a cron job that retried failed payment callbacks, and the system processed the same webhook twice for about 120 orders over two months. Each double‑processed callback didn't charge the customer again, but it did insert duplicate reconciliation records that inflated the ledger.

That's when I stopped blaming Excel and started fixing the code.

Solution

The root cause was simple: no idempotency layer in payment callbacks. Every external webhook — from PayPal, Stripe, or any local gateway — was handled by a controller that verified signature, updated order status, and logged the transaction. If the same payload arrived twice (network retry, gateway resend), the system inserted duplicate records.

We redesigned the callback handler around a request idempotency key. The pattern is now standard in our daigou code base.

// Callback controller snippet
public function handlePaymentCallback(Request $request)
{

$payload = $request->getContent();

$idempotencyKey = $request->header('X-Idempotency-Key') ?? md5($payload);

// Try to acquire lock with Redis

$lockKey = "payment:lock:{$idempotencyKey}";

$lock = Redis::setnx($lockKey, time() + 10);

if (!$lock) {

// Another process is handling the same callback

return response('Processing', 202);

}

DB::beginTransaction();

try {

// Check if already processed

$processed = DB::table('payment_idempotency')

->where('key', $idempotencyKey)

->exists();

if ($processed) {

DB::commit();

return response('OK', 200);

}

// Extract order_id from payload

$orderId = $payload['order_id'] ?? null;

if (!$orderId) {

throw new \Exception('Missing order reference');

}

// Update order status with state machine check

$order = Order::find($orderId);

if ($order->status === 'paid') {

// Already paid, still record idempotency but skip double action

$this->recordIdempotency($idempotencyKey, $orderId);

DB::commit();

return response('OK', 200);

}

$order->status = 'paid';

$order->paid_at = now();

$order->save();

// Record idempotency entry

$this->recordIdempotency($idempotencyKey, $orderId);

DB::commit();

Redis::del($lockKey);

return response('OK', 200);

} catch (\Exception $e) {

DB::rollBack();

Redis::del($lockKey);

Log::error('Payment callback failed', ['key' => $idempotencyKey, 'error' => $e->getMessage()]);

return response('Failed', 500);

}
}

private function recordIdempotency($key, $orderId)
{

DB::table('payment_idempotency')->insert([

'key' => $key,

'order_id' => $orderId,

'created_at' => now(),

]);
}

The payment_idempotency table has a unique index on key, so even if Redis lock fails (rare), the database insertion prevents the second write.

We also locked the exchange rate at order creation time. Before, the system used a live rate at payment confirmation — which could be hours or days after the customer clicked "buy". Now the orders table stores exchange_rate_used and base_currency_amount. The customer sees the final price immediately, and the finance team reconciles against that frozen rate.

ALTER TABLE orders ADD COLUMN exchange_rate_used DECIMAL(10,6) NOT NULL DEFAULT 1.0;
ALTER TABLE orders ADD COLUMN base_currency_amount DECIMAL(12,2) NOT NULL;

Order creation flow:

$rate = Redis::get('cny_to_usd_rate') ?? 6.45; // cached, refreshed every 5 min
$order->exchange_rate_used = $rate;
$order->base_currency_amount = $cartTotalUSD * $rate;
$order->save();

Lessons Learned

Idempotency is not just about deduplication — it's about defining what "once" means. Our first implementation used the raw JSON payload as the idempotency key. That broke when gateways added a timestamp field that changed between retries. We switched to a composite key: gateway name + gateway transaction ID. That survived retries.

The lock + database index combination saved us from deadlocks. Early on we tried using only a UNIQUE index on the idempotency table. Under high concurrency (about 30 callbacks per second during flash sales), the database threw duplicate key exceptions, and our error handler retried the whole request, causing a cascade. Adding the Redis lock reduced duplicate insert attempts by about 95%.

Exchange rate caching has a hidden trade‑off. We refresh the Redis cache every 15 minutes. During extreme volatility (like JPY moving 1.5% in an hour), the customer pays a rate that's already stale. We added a safety valve: if the external rate deviates from cached rate by more than 2%, the system rejects the order and asks the customer to retry. This happens on maybe 1% of orders, but it saved us from losing money on another 3-4% of transactions.

Reconciliation still needs a human in the loop. We built a daily diff report that compares gateway settlement files (CSV) with our payment_idempotency and orders tables. Any mismatch over 0.5% triggers an alert. The report cut monthly reconciliation time from about 15 hours to under 2 hours.

One thing we didn't anticipate: partial refunds. When a customer returns two of five items, which exchange rate do you use for the refund? The original locked rate or the current rate? We settled on original rate to avoid customer complaints, but that means you eat the currency risk on refunds. Our solution now is to hold a small buffer (around 0.6% of order value) in a separate account specifically for refund exchange losses.

Conclusion

Payment reconciliation in cross-border daigou isn't a math problem — it's a design problem. Idempotency keys, rate locking, and daily diffs turn a "where did the money go" mystery into a routine check. Start with the database unique index, add Redis locks when concurrency grows, and never assume a webhook arrives exactly once.

If your team still reconciles with Excel and coffee at midnight, you're one flash sale away from a very bad week. The code above is production‑tested on a system handling a few hundred orders daily. Full example with migration files and test webhook simulator is in our internal repo — adapt the pattern to your stack.

About the Author: I'm a CTO who's built and scaled cross‑border purchasing platforms for the past decade. Currently working with Taocarts — a daigou system that handles order management, warehouse coordination, and international shipping for 1688/Taobao sourcing. The idempotency pattern described here runs in production on Taocarts deployments.

Bulk Downloading 1688 Product Images: A Lesson in Maxing Out Bandwidth

yanmoheluo — Wed, 27 May 2026 03:32:46 +0000

ur purchasing system suddenly went down. Monitoring showed that outbound bandwidth was maxed out at 500Mbps, causing all external API requests to timeout. The culprit was a script for bulk downloading 1688 product images—it launched 200 concurrent download threads without any rate limiting, completely saturating our shared bandwidth.

Problem Scenario: A Brutal Approach to Image Downloading

We needed to sync approximately 3,000 1688 products daily, including main images and detail images, averaging 5 images per product. The initial implementation was straightforward but crude:

// Old brute-force download script
function downloadAllImages($productIds) {
    foreach ($productIds as $id) {
        $images = get1688ProductImages($id); // Call 1688 API to get image URL list
        foreach ($images as $url) {
            $content = file_get_contents($url); // Synchronous blocking download
            file_put_contents("/images/$id/".basename($url), $content);
        }
    }
}

This script had 3 critical issues:

No concurrency control: While file_get_contents is synchronous, the outer loop had no limits, resulting in massive HTTP requests fired simultaneously
No retry mechanism: If an image download failed (e.g., network jitter), the script simply skipped it, leaving product images missing
No bandwidth limiting: 200 concurrent requests downloading simultaneously, each averaging 2MB, instantly consumed 400MB of bandwidth

The immediate consequence: all other business operations (including order processing and logistics queries) were interrupted for 18 minutes. We had to manually kill the process and spend 2 hours re-downloading the failed images.

Solution: A Downloader with Rate Limiting and Queue

We redesigned the downloader using Guzzle's async capabilities, adding bandwidth control and retry mechanisms.

Step one: Use Guzzle's concurrent request pool with a maximum concurrency limit.
Step two: Implement a simple token bucket algorithm for bandwidth control.

// New rate-limited downloader
use GuzzleHttp\Client;
use GuzzleHttp\Pool;
use GuzzleHttp\Psr7\Request;

class ThrottledImageDownloader {
    private $client;
    private $concurrency = 10; // Maximum concurrency
    private $bandwidthLimit = 50 * 1024 * 1024; // 50MB/s bandwidth limit
    private $tokens;
    private $lastRefillTime;

    public function __construct() {
        $this->client = new Client(['timeout' => 30]);
        $this->tokens = $this->bandwidthLimit;
        $this->lastRefillTime = microtime(true);
    }

    // Token bucket algorithm for bandwidth control
    private function consumeBandwidth($bytes) {
        $now = microtime(true);
        $elapsed = $now - $this->lastRefillTime;
        $this->tokens = min($this->bandwidthLimit, $this->tokens + $elapsed * $this->bandwidthLimit);
        $this->lastRefillTime = $now;

        if ($this->tokens < $bytes) {
            $sleepTime = ($bytes - $this->tokens) / $this->bandwidthLimit;
            usleep($sleepTime * 1e6);
            $this->tokens = 0;
        } else {
            $this->tokens -= $bytes;
        }
    }

    public function downloadBatch(array $imageUrls) {
        $requests = function ($urls) {
            foreach ($urls as $url) {
                yield new Request('GET', $url);
            }
        };

        $pool = new Pool($this->client, $requests($imageUrls), [
            'concurrency' => $this->concurrency,
            'fulfilled' => function ($response, $index) use ($imageUrls) {
                $content = $response->getBody()->getContents();
                $this->consumeBandwidth(strlen($content));
                // Save image logic
                $filename = basename($imageUrls[$index]);
                file_put_contents("/images/$filename", $content);
            },
            'rejected' => function ($reason, $index) use ($imageUrls) {
                // Retry on failure, up to 3 times
                $this->retryDownload($imageUrls[$index], 3);
            },
        ]);

        $pool->promise()->wait();
    }

    private function retryDownload($url, $maxRetries) {
        for ($i = 0; $i < $maxRetries; $i++) {
            try {
                $response = $this->client->get($url);
                $content = $response->getBody()->getContents();
                $filename = basename($url);
                file_put_contents("/images/$filename", $content);
                return;
            } catch (\Exception $e) {
                if ($i === $maxRetries - 1) {
                    // Log failure
                    error_log("Failed to download $url after $maxRetries attempts");
                }
                sleep(pow(2, $i)); // Exponential backoff
            }
        }
    }
}

Key improvements:

Concurrency control: concurrency set to 10, preventing instant bandwidth saturation
Token bucket rate limiting: The consumeBandwidth method ensures downloads don't exceed 50MB per second
Exponential backoff retry: Wait 2^i seconds after failure, with a maximum of 3 attempts

Lessons Learned: From Bandwidth Disaster to Stable Sync

After deploying the new downloader, we ran A/B tests. The old script took 12 minutes to download images for 3,000 products (~15,000 images), but consumed 500Mbps of bandwidth. The new script took 18 minutes for the same task, but bandwidth remained stable at 45-50Mbps with zero impact on other services.

Further optimization: Incremental downloads and caching

We also added a simple file hash check to avoid re-downloading existing images:

// Incremental check - only download new images
function needsDownload($url, $localPath) {
    if (!file_exists($localPath)) {
        return true;
    }
    // Check if remote file has been updated via HEAD request
    $headers = get_headers($url, 1);
    $remoteSize = $headers['Content-Length'] ?? 0;
    $localSize = filesize($localPath);
    return $remoteSize != $localSize;
}

This optimization reduced daily incremental sync time from 18 minutes to 3-5 minutes, since only about 10% of product images are updated daily.

Summary: When bulk downloading third-party resources, never assume that "faster is better." Brute-force concurrent downloads may seem efficient, but they often sacrifice system stability. Rate limiting, retry mechanisms, and incremental checks are the three core elements of a reliable download system. If your image sync script is still running file_get_contents without protection, it's time for an upgrade.

Has your system encountered similar issues when handling large volumes of external resource downloads? Feel free to share your solutions.

About the Author: Building cross-border purchasing solutions with taocarts — a daigou system for 1688/Taobao purchasing, order management, and international shipping.

Syncing 1688 Orders with Webhooks: A Production Incident

yanmoheluo — Wed, 27 May 2026 03:22:47 +0000

Our order processing queue hit a backlog of over 5,000 messages—compared to a normal baseline under 100. Even worse, customer order statuses were stuck at "Paid" for over 4 hours with no updates. Investigation revealed that our scheduled polling script for syncing 1688 order statuses had exhausted the database connection pool under high concurrency, causing the entire system to hang.

Background: The Cost of Polling

We were running a Cron Job every 5 minutes that called the 1688 Open API to fetch order status changes from the past 24 hours. The code looked like this:

import requests
import time
from myapp.models import Order
from myapp.db import get_db_connection

def poll_1688_orders():
    conn = get_db_connection()
    cursor = conn.cursor()
    # Fetch 100 records per page, no incremental markers
    orders = requests.get("https://api.1688.com/order/list", params={"pageSize": 100, "pageNum": 1})
    for order in orders.json()["data"]:
        cursor.execute("UPDATE orders SET status = %s WHERE order_id = %s", (order["status"], order["id"]))
    conn.commit()
    cursor.close()
    conn.close()

This script had three critical issues:

Full fetch: Retrieved all orders on each run, with no incremental ID or timestamp markers, causing duplicate processing
Synchronous blocking: requests.get was blocking—when the API responded slowly, the entire process stalled
Connection leaks: Under high concurrency, connections created by get_db_connection() weren't properly released, eventually exhausting the connection pool

The direct consequence of that incident: database connections spiked to 200+, exceeding MySQL's default maximum of 151, causing all write operations to fail. We spent 45 minutes manually restarting services and clearing the queue, during which 120 order shipping status updates were delayed.

Solution: Replacing Polling with Webhooks

We decided to migrate to Webhook mode. The 1688 Open API supports configuring a callback URL for each application. When order statuses change, it proactively pushes a JSON payload to our server. This fundamentally eliminates the resource waste and latency caused by polling.

Step 1: Configure the Webhook endpoint in the 1688 Open Platform.

Step 2: Write a lightweight Webhook receiver using an async framework to process requests without blocking.

from fastapi import FastAPI, Request, HTTPException
from pydantic import BaseModel
import hmac
import hashlib
import asyncio
from myapp.services import update_order_status

app = FastAPI()

class OrderWebhookPayload(BaseModel):
    order_id: str
    new_status: str
    timestamp: int
    signature: str

@app.post("/webhook/1688/order")
async def handle_1688_webhook(payload: OrderWebhookPayload, request: Request):
    # 1. Verify signature - prevent forged requests
    secret = "your_1688_webhook_secret"
    raw_body = await request.body()
    expected_signature = hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
    if payload.signature != expected_signature:
        raise HTTPException(status_code=403, detail="Invalid signature")

    # 2. Async database update - use connection pool
    await update_order_status(payload.order_id, payload.new_status)

    # 3. Return 200 quickly to avoid timeout retries
    return {"status": "ok"}

Key improvements:

Async processing: async def allows FastAPI to handle thousands of concurrent Webhook requests simultaneously without blocking I/O
Signature verification: Uses HMAC-SHA256 to verify payload origin, preventing malicious requests
Connection pool: update_order_status internally uses SQLAlchemy's connection pool, keeping maximum connections under 20

Lessons Learned: Refactoring from the Incident

This incident prompted us to redesign the entire order sync architecture. Here are the specific optimizations:

1. Decouple with a Message Queue

The Webhook receiver only handles verification and enqueuing—it doesn't write directly to the database. We use Redis as a lightweight queue:

import json
import aioredis

redis = await aioredis.from_url("redis://localhost:6379")

async def enqueue_order_update(order_id: str, new_status: str):
    message = json.dumps({"order_id": order_id, "status": new_status})
    await redis.lpush("order_updates", message)

2. Batch Processing in Consumer

Another async worker pulls messages from the queue in batches, updating the database every 10 messages or every 5 seconds:

async def batch_update_worker():
    while True:
        messages = []
        for _ in range(10):
            msg = await redis.rpop("order_updates")
            if msg:
                messages.append(json.loads(msg))
            else:
                break
        if messages:
            async with db_pool.acquire() as conn:
                await conn.executemany(
                    "UPDATE orders SET status = $1 WHERE order_id = $2",
                    [(m["status"], m["order_id"]) for m in messages]
                )
        await asyncio.sleep(5)

After deploying this architecture, our order sync latency dropped from an average of 5 minutes to under 10 seconds, and database connections stabilized at 15-20. More importantly, we haven't experienced any more cascading failures caused by polling.

Summary: Don't use polling to solve real-time problems, especially when a third-party API provides Webhooks. The Webhook + message queue combination not only reduces resource consumption but also makes systems more stable when handling burst traffic. If your order system is still using Cron Job polling, now is the time to refactor.

What do you think of this approach? Has your order sync system encountered similar bottlenecks? Let's discuss in the comments.

About the Author: Building cross-border purchasing solutions with taocarts — a daigou system for 1688/Taobao purchasing, order management, and international shipping.

reverse Haitao Development's 3 Common Pitfalls

yanmoheluo — Sat, 23 May 2026 04:19:53 +0000

When I received this demand, my first reaction was, "Can't this thing work with a ready-made solution?" Later, after a careful analysis of the business scenario, it was found that there were indeed several special constraints.

A three-layer defense system against oversold items: the first layer of Redis Lua atomic withholding inventory (traffic peak shaving), the second layer of Laravel Queue asynchronous processing (fast response), and the third layer of MySQL transactions + optimistic lock-up. Tested to support an average daily order volume of over 100,000 orders with 100% inventory accuracy, Sneaker's代购website development is also a point that many users frequently inquire about.

First, let's see what options are available. There are roughly three options available on the market: developing from scratch, using open-source systems, and directly using off-the-shelf SaaS systems like taocarts. The applicable scenarios and hidden costs for each scheme vary significantly.

It's not scary for a technical decision to turn into technical debt three years later; what's scary is forgetting why it was chosen in the first place.

The final selection primarily considered three constraints: limited server budget (2C4G lightweight cloud), a team of just me working on the backend, and customers needing to go online within two weeks. Under this constraint, taocarts' out-of-the-box solution is more appropriate. When ChatGPT was first introduced, people were still questioning whether 'AI can work.' Now, they no longer question it.

The overall architecture adopts a separation of frontend and backend. PHP's self-developed framework provides RESTful APIs, Vue. JavaScript builds frontend interfaces for authentication using HMAC signatures. File caching is used for hot data caching, while MySQL is used for persistent storage.

Below is a key code snippet:


// Order Status Machine: The Evolution from 5-State to 8-State
// Initially, only 5 states were defined, but it was later discovered that there was a gap between 'pending procurement' and 'purchased'.
// Missing a 'purchase in progress' status — placing an order in 1688 might take 3-5 seconds during this period.
// If users repeatedly click, it will trigger repeat purchases. After adding this intermediate state, the problem is solved.
const ORDER_STATES = {
PENDING: 'pending', // Pending payment
PAID: 'paid', // Paid
PURCHASING: 'purchasing', // Purchasing (for weight protection)
PURCHASED: 'purchased', // 已采购
ARRIVED: 'arrived', // Already in Stock
PACKED: 'packed', // Packaged
SHIPPED: 'shipped', // Shipped
COMPLETED: 'completed', // 已完成
};

Of course, this plan also has limitations. Single-machine deployment limits scalability, and service splitting may be necessary if the number of future tenants doubles. Additionally, file caching is less stable than Redis in high-concurrency scenarios, which is also something that needs to be improved in the future.

Technical selection doesn't have a silver bullet, but it follows principles—first clarify business constraints, then assess team capabilities, and finally choose the most suitable one. Do not rely on technology just for the sake of it.

I wrote this article because I couldn't find complete information online during my previous trip, and I hope it can help those who encountered similar issues. Welcome to share your implementation in the comments.

The COD signature rate in the Middle East market exceeds 90%, while the return rate is below 5%. The consumption peak occurs around Ramadan, so it's important to plan 60 days in advance to seize the traffic window.

Platform 1688 saw a 45% year-over-year increase in cross-border purchase orders in 2025, with an increasing number of overseas merchants purchasing directly from the 1688 source.

In 2025, China's cross-border e-commerce exports exceeded 15 trillion yuan, marking a 18% year-over-year growth.

In 2026, cross-border e-commerce growth in Southeast Asia is expected to exceed 25%, making it the fastest-growing regional market.

The GMV of WeChat mini-program e-commerce is set to exceed 5 trillion yuan by 2025, with mini-programs becoming an important entry point for cross-border shopping agents.

The average unit price in the Middle East market (United Arab Emirates, Saudi Arabia) is three times that of Southeast Asia, with luxury goods代购growth exceeding 50%.

The data shows that after integrating logistics tracking, customer inquiries decreased by 60%, as buyers could check the logistics progress themselves.

A solution for optimizing images from 5MB to 200KB: WebP format (30-50% smaller than JPEG) + multi-size thumbnails (list 200px, details 800px) + CDN distribution + lazy loading (Intersection Observer). Optimized first-screen image loading time has been reduced from 4.5 seconds to 1.2 seconds.

Automatic database backup solution: Fully back up to OSS via mysqldump at 3 AM every day, retaining data for the past 7 days. binlog backups are performed every 2 hours. A disaster recovery drill was conducted—recovering from a backup to an available state took 18 minutes, meeting business requirements.

By 2025, global independent station transactions exceeded $1.2 trillion, growing at a rate of 28.7%, far outpacing platform e-commerce's 16.3%. The cost of acquiring customers for independent stations is 32% lower than for platforms, and the user repeat purchase rate is 27%.

Taobao agent system development pitfalls recorded

yanmoheluo — Sat, 23 May 2026 04:17:54 +0000

he product synchronization module processes over 100,000 product entries daily. The initial plan was to run for 4 hours at a time, which nearly affected the next day's business. Optimized for 20 minutes, there's no time to do more.

Off-topic: From 2013 to the present, toolchains have changed, but the初。of doing technology remains the same—solve the problem well, write the documentation clearly, and let the next successor not scold you.

First, let's look at the data before the optimization. Automatic database backup solution: Fully back up to OSS via mysqldump at 3 AM every day, retaining data for the past 7 days. binlog backups are performed every 2 hours. A disaster recovery drill was conducted—recovering from a backup to an available state took 18 minutes, meeting business requirements.

The first step in optimization is to identify the bottleneck. Using MySQL slow query logs + Chrome DevTools Performance analysis, it was found that the bottleneck distribution is as follows: database 60%, front-end rendering 25%, and network transmission 15%. First, let's address the largest piece.

The optimization plan involves several steps. 1688/Taobao API Callback Processing: The most frustrating aspect is the order status callback for 1688—not real-time push, but batch push every so often. Sometimes users have already paid, but the 1688 callback doesn't arrive until 30 minutes later. The solution is a dual-channel active polling + callback: proactively querying the order status changes of 1688's last 30 minutes every 5 minutes as a supplement to the callback. Every step involves specific modifications and verification methods.

Optimized Real-Time Comparison —— Using Apache Bench to pressure the same interface and the same number of concurrent instances ensures that the data does not lie. The response time was reduced from XX before optimization to YY, and the error rate was zero.

Trudging isn't scary; it's scary if you don't write it down. Each pit was created using real money for the production environment.

Summarize a few experiences. Performance optimization follows a principle: measure first, then optimize, and finally measure. Optimization without data support is esoteric, and shopping agent websites are also a point that many users often ask about.

The core lesson from this optimization: performance bottlenecks are often not where you think they are. I initially doubted the database, but the issue was with the frontend stuffing the entire product list into the DOM at once.

That's the core idea and key implementation of this solution. Welcome to share your implementation in the comments.

The shipping cost estimation feature is very practical, allowing customers to see the estimated shipping costs after selecting the item, without needing to ask me every time.

Merchants using automated代。 systems saw their average unit price increase by 30% due to support for multiple languages and currencies, which made orders smoother for overseas customers.

Multi-tenant data isolation solution: database-level isolation (with each tenant having its own independent database), rather than the traditional tenant_id field isolation. Reasons:一是）。 data security issues (physical isolation of data from different merchants), and二是灵活 flexible backup and recovery (a problem with one tenant does not affect others).

The average unit price in the Middle East market (United Arab Emirates, Saudi Arabia) is three times that of Southeast Asia, with luxury goods代购growth exceeding 50%.

N+1 queries are the most common performance killer in代。 systems. A product detail page has been optimized from 127 SQL queries to 6, and the database time has been reduced from 1.8 seconds to 120ms. The key is Eager Loading (preloading associated data), which uses Laravel's with() method to identify all associations at once, rather than checking each one in a loop.

The biggest feeling is that customer trust has increased. Because the system automatically generates logistics tracking numbers and updates the status in real time, customers don't need to keep urging them.

The most commonly used service is the inspection and photography service. Upon arrival at the warehouse, staff will take photos and upload them, allowing customers to see the physical photos before deciding whether to ship.

API Layer HMAC Signature Authentication Mechanism: Each tenant is assigned a separate App Key and App Secret, and request signatures are protected against replay attacks using sha256 (request body + timestamp + secret). Timestamp error allows ±5 minutes, and Redis records show that Nonce has been used to prevent replay.

The profit statistics report for代。is very intuitive. Daily, weekly, and monthly revenues and costs are clearly visible, with data determining which categories make money and which ones incur losses.