Arkitektur for lagerlåsing i WooCommerce og ERP i æraen for autonome AI-innkjøpsagenter

Fremveksten av autonome AI-innkjøpsagenter, inkludert systemer basert på Claude Computer Use, OpenAI Operator og spesialiserte B2B-anskaffelsesroboter, representerer et fundamentalt skifte for nettbutikkers ytelseskrav. I motsetning til menneskelige kunder som bruker flere minutter på å navigere i varekataloger og fylle ut kassesider sekvensielt, analyserer AI-agenter spesifikasjoner, velger leverandører og sender ferdige betalingskall på millisekunder. Under kampanjer som flash sales, lanseringer av begrensede opplag eller plutselige råvareprisendringer, kan hundrevis av roboter sende parallelle transaksjoner mot kasseendepunktene i WooCommerce.

Den tradisjonelle arkitekturen i WooCommerce, opprinnelig bygget for lineær menneskelig handel, bryter raskt sammen under slik samtidighet dersom nettbutikken mangler tilpasset databaseteknologi. Når en handelsløsning utelukkende baserer lagerreduksjon på relasjonelle radlåser i MySQL i synkrone PHP-FPM-prosesser, oppstår det uunngåelig låsninger (deadlocks), tidsavbrudd og oversalg (overselling): en kritisk tilstand hvor samme fysiske lagerenhet selges til flere kjøpere samtidig.

#Samtidighetsutfordringer og kappløpstilstander i WordPress-transaksjoner

En kappløpstilstand (race condition) oppstår så snart to eller flere samtidige prosesser forsøker å lese og oppdatere den samme databaserekorden parallelt. Se for deg et industrielt scenario der en kostbar trefaset omformer kun har 1 enhet igjen på lager, og to uavhengige B2B-innkjøpsroboter sender bestillinger med 5 millisekunders mellomrom:

1. Tråd A (Agent 1) henter nåværende beholdning: SELECT stock_quantity FROM wp_wc_product_meta_lookup WHERE product_id = 4520; og mottar verdien 1.
2. Tråd B (Agent 2) kjører nøyaktig samme spørring brøkdelen av et sekund senere, og mottar også verdien 1, ettersom Tråd A ennå ikke har bekreftet transaksjonen til disken.
3. Tråd A trekker fra 1 enhet, setter lagerbeholdningen til 0 og oppretter ordren.
4. Tråd B, som baserer seg på sin opprinnelige leseverdi på 1, trekker likeledes fra 1 enhet (og setter ofte lageret til 0 eller -1 avhengig av innstillinger for negativt lager) og bekrefter kjøpet.

Begge agentene mottar en vellykket HTTP 200-respons og ordrebekreftelse, til tross for at lageret fysisk bare rår over én enhet. I B2B-handel, hvor enkeltordrer gjerne utgjør betydelige beløp, utløser slikt oversalg direkte økonomiske tap, kontraktsmessige sanksjoner og svekket tillit hos handelspartnere.

Dersom nettbutikken er koblet til et eksternt ERP-system (som SAP, Microsoft Dynamics 365 eller lokale forretningssystemer), forplantes feilen umiddelbart. Uten distribuerte låser og atomisk datasynkronisering vil det fysiske lageret avvike fra de digitale tallene i butikken. Våre dokumenterte løsninger for pålitelige ERP-koblinger finnes på /nb/woocommerce-erp-integrasjon/.

#Pessimistisk mot optimistisk låsing i MySQL

Innen relasjonsdatabaser benyttes det to hovedstrategier for å håndtere samtidighet: pessimistisk låsing og optimistisk låsing.

#Pessimistisk låsing (pessimistic locking)

Den pessimistiske tilnærmingen forutsetter at datakonflikter vil oppstå under høy belastning. I MySQL InnoDB implementeres dette ved hjelp av SELECT ... FOR UPDATE eller LOCK IN SHARE MODE. Når Tråd A leser en post, legger databaseserveren en eksklusiv radlås på den aktuelle indeksen:

START TRANSACTION;

-- Hent lagerbeholdning og reserver raden eksklusivt
SELECT stock_quantity 
FROM wp_wc_product_meta_lookup 
WHERE product_id = 4520 
FOR UPDATE;

-- Forretningslogikk i PHP: Bekreft at stock_quantity >= onsket antall
UPDATE wp_wc_product_meta_lookup 
SET stock_quantity = stock_quantity - 1 
WHERE product_id = 4520;

COMMIT;

Frem til Tråd A fullfører transaksjonen med COMMIT eller avbryter med ROLLBACK, må alle andre prosesser som ber om samme rad via FOR UPDATE stå i ventekø.

Fordeler med pessimistisk låsing:

• Garanterer full dataintegritet på en enkelt databaseserver.
• Fjerner risikoen for oversalg ved korrekt oppsatte ACID-transaksjoner.

Ulemper med pessimistisk låsing:

• Kraftig reduksjon i systemets gjennomstrømming under trafikktopper.
• Stor risiko for fastlåsinger (deadlocks) dersom handlekurver låser flere produkter i ulik rekkefølge.
• Opphopning av ventende tråder overskrider innodb_lock_wait_timeout, med påfølgende HTTP 504 Gateway Timeout-feil.

#Optimistisk låsing (optimistic locking)

Den optimistiske tilnærmingen antar at kollisjoner inntreffer sjelden. I stedet for å låse rader under behandlingen, utvides tabellen med et versjonsfelt (version_id eller tidsstempel). Ved skriving sjekker spørringen om versjonen er uendret:

-- Trinn 1: Lesing uten databaselaas
SELECT stock_quantity, version_id 
FROM wp_wc_product_inventory_state 
WHERE product_id = 4520;
-- Returnerer: stock_quantity = 1, version_id = 84

-- Trinn 2: Betinget oppdatering
UPDATE wp_wc_product_inventory_state 
SET stock_quantity = stock_quantity - 1, 
    version_id = version_id + 1 
WHERE product_id = 4520 AND version_id = 84;

Dersom en annen prosess i mellomtiden har oppdatert produktet (slik at version_id økte til 85), returnerer UPDATE-spørringen 0 berørte rader (rows affected = 0). PHP-applikasjonen fanger opp dette, ruller tilbake og ber innkjøpsagenten prøve igjen eller avbryte.

Tabellen wp_wc_product_inventory_state i dette eksemplet er en egen tabell laget for mønsteret og er ikke en del av WooCommerce-kjernen.

Ved ekstreme flash sales eller samtidige henvendelser fra roboter fører imidlertid optimistisk låsing til kaskader av avviste transaksjoner (retry storms) som overbelaster servernes prosessorkraft og båndbredde.

#Distribuerte lagerlåser med Redis og Redlock-algoritmen

For WooCommerce-butikker som håndterer tusenvis av samtidige transaksjonskall i sekundet fra AI-innkjøpere, representerer transaksjonslåsing direkte mot MySQL-disken en flaskehals. Skalerbare arkitekturer skiller lagerreservasjonene fra primærdatabasen og flytter samtidighetshåndteringen til et hurtigminne i et Redis-kluster.

Klassen under bruker enkeltinstansmønsteret fra Redis-dokumentasjonen: SET nokkel verdi NX PX ttl med en verdi som er unik for hver låseforespørsel. Låsen frigjøres med et Lua-skript som bare sletter nøkkelen hvis den fortsatt har akkurat denne verdien. Redlock er utvidelsen av samme idé til flere noder. Redis-dokumentasjonen beskriver det med N uavhengige mastere (eksemplet bruker N=5), og en lås regnes som tatt først når klienten har satt den på et flertall (N/2+1) innenfor gyldighetstiden. Samme side advarer om at Redis ikke bruker en monoton klokke for TTL-utløp, og anbefaler fencing tokens for lange operasjoner (Redis: distributed locks). For en lagerteller betyr det at låsen alene ikke garanterer korrekthet; det er den betingede nedtellingen lenger ned som nekter å gå under null. Følgende PHP-klasse viser oppsettet:

<?php
/**
 * Haandtering av distribuerte lagerlaaser med Redis i WooCommerce
 */
declare(strict_types=1);

namespace WPPoland\InventoryConcurrencyNB;

final class RedisInventoryLockManager
{
    private \Redis $redis;
    private int $lockTtlMilliseconds;

    public function __construct(\Redis $redis, int $lockTtlMilliseconds = 5000)
    {
        $this->redis = $redis;
        $this->lockTtlMilliseconds = $lockTtlMilliseconds;
    }

    /**
     * Atomisk innhenting av distribuerte reservasjoner for et produkt
     */
    public function acquireLock(int $productId, string $token): bool
    {
        $lockKey = sprintf('lock:inventory:product:%d', $productId);

        // NX: sett kun hvis nokkelen ikke finnes; PX: utlopstid i millisekunder
        $acquired = $this->redis->set($lockKey, $token, ['NX', 'PX' => $this->lockTtlMilliseconds]);

        return $acquired === true;
    }

    /**
     * Frigjor laasen trygt via et atomisk Lua-skript
     * Hindrer sletting av fremmede laaser etter TTL-utlop
     */
    public function releaseLock(int $productId, string $token): bool
    {
        $lockKey = sprintf('lock:inventory:product:%d', $productId);

        $luaScript = <<<LUA
            if redis.call("get", KEYS[1]) == ARGV[1] then
                return redis.call("del", KEYS[1])
            else
                return 0
            end
LUA;

        $result = $this->redis->eval($luaScript, [$lockKey, $token], 1);

        return $result === 1;
    }

    /**
     * Atomisk lagerreduksjon direkte i Redis-hurtigminnet
     */
    public function decrementInventory(int $productId, int $quantity): int
    {
        $stockKey = sprintf('inventory:stock:product:%d', $productId);

        $luaScript = <<<LUA
            local currentStock = tonumber(redis.call("get", KEYS[1]) or "0")
            local decrementAmount = tonumber(ARGV[1])

            if currentStock >= decrementAmount then
                local newStock = redis.call("decrby", KEYS[1], decrementAmount)
                return newStock
            else
                return -1
            end
LUA;

        $newStock = (int) $this->redis->eval($luaScript, [$stockKey, $quantity], 1);

        return $newStock;
    }
}

Redis garanterer atomisk kjøring av et Lua-skript: mens skriptet kjører, er all annen serveraktivitet blokkert, så effektene har enten ikke skjedd ennå eller skjedd fullt ut (Redis: scripting with Lua). Fordi lagerkontrollen og DECRBY ligger i samme skript, kan ikke to samtidige agenter begge passere kontrollen på den siste enheten. Baksiden av garantien er at et tregt skript stopper alle andre klienter på instansen, enda en grunn til å holde lagerskriptene korte og kjøre dem på en egen Redis-instans atskilt fra objektbufferen. Først etter at reservasjonen i minnet er bekreftet, oppdaterer en asynkron bakgrunnstjeneste MySQL-tabellene og sender endringen til ERP-systemet.

#Betydningen av WooCommerce HPOS for transaksjonskapasitet

I over et tiår lagret WooCommerce ordredata i standardtabellene wp_posts og wp_postmeta. I butikker med tusenvis av daglige bestillinger vokste wp_postmeta til titalls millioner rader. Hvert kassesalg krevde dusinvis av INSERT-spørringer mot denne felles nøkkel-verdi-tabellen, noe som fragmenterte databasens indekser og forlenget låsetidene betraktelig.

Innføringen av High-Performance Order Storage (HPOS) markerer et avgjørende teknologisk løft for WooCommerce:

• Egne transaksjonstabeller: Ordredata plasseres i spesialiserte tabeller (wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data), noe som kobler ordretrafikken fullstendig fra nettsidens innholdstabeller.
• Normaliserte relasjonskolonner: Kjerneattributter som status, ordresum, kunde-ID og valuta lagres i indekserte kolonner i stedet for fragmenterte metadata.
• Omfang og status: WooCommerce-dokumentasjonen for utviklere oppgir ingen latenstall for HPOS; den beskriver færre lese- og skriveoperasjoner og færre travle tabeller. HPOS har vært stabilt siden WooCommerce 8.2 (oktober 2023) og er slått på som standard i nye installasjoner, mens eksisterende butikker slår det på manuelt (WooCommerce: HPOS). De fire tabellene er wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data og wp_wc_orders_meta. HPOS lagrer bestillinger. Lagerbeholdning og priser for produkter ligger fortsatt i produktdataene, så HPOS korter ned skrivingen av bestillinger, men serialiserer ikke lagertrekk av seg selv.

Nedenfor vises dataflyten i en moderne arkitektur tilpasset høy samtidighet:

+------------------------------------+
|     Autonome AI-innkjopsagenter    |
|    (Claude, GPT-4o, B2B-roboter)   |
+------------------------------------+
                   |
                   v (Samtidige HTTPS-kasseforesporsler)
+------------------------------------+
|   Cloudflare Edge / Nginx Proxy    |
|   Rate Limiting & WAF-inspeksjon   |
+------------------------------------+
                   |
                   v
+------------------------------------+
|    Redis Locking & State Layer     | <--- Atomisk Lua-skript (Redlock)
|     (Reservasjon i hurtigminnet)   |      Hindrer oversalg i sanntid
+------------------------------------+
                   |
                   v (Kjores kun etter godkjent minnereservasjon)
+------------------------------------+
|    WooCommerce HPOS Tabeller       |
|  (wp_wc_orders, ACID-transaksjoner)|
+------------------------------------+
                   |
                   v (Asynkron meldingsko: RabbitMQ / Kafka)
+------------------------------------+
|      Lager- og ERP-system          |
| (SAP, Microsoft Dynamics, Visma)   |
+------------------------------------+

For å sikre at butikken ikke har sårbarheter som automatiserte roboter kan utnytte under høytrafikk, bør du gjennomføre en grundig teknisk revisjon som beskrevet på /nb/sikkerhetsrevisjon-wordpress/.

#Hvordan WooCommerce holder av lager i kassen uten ekstra kode

Før du legger til Redis, lønner det seg å vite hva kjernen allerede gjør. Under WooCommerce > Innstillinger > Produkter > Lager slår «Administrer lager» på mengdesporing, og «Hold lager (minutter)» holder av lager for ubetalte bestillinger. Ifølge dokumentasjonen gjelder dette bestillinger med status «Avventer betaling», ikke «På vent». Når tiden er ute, kanselleres bestillingen og lageret går tilbake til beholdningen; et tomt felt slår funksjonen av (WooCommerce: produktinnstillinger).

Den blokkbaserte kassen legger til en ekstra tilstand. Bestillinger med status «Utkast» er midlertidige oppføringer som blokk-kassen oppretter før bestillingen sendes inn, og dokumentasjonen for bestillingsstatuser sier at lageret holdes av så lenge bestillingen står som «Utkast» eller «Avventer betaling». En daglig planlagt opprydding sletter utkast som ikke lenger er aktive. Hvis lageret allerede er trukket for en bestilling som senere går over til «Mislyktes», legger WooCommerce det tilbake i beholdningen (WooCommerce: bestillingsstatuser).

Med agenttrafikk betyr dette to ting. En agent som åpner mange kasser og forlater dem, binder enheter i hele reservasjonsvinduet, så verdien i «Hold lager (minutter)» er en forretningsbeslutning og ikke en standardverdi du lar stå urørt. Og «Terskel for utsolgt» bestemmer ved hvilket antall et produkt regnes som utsolgt; det er denne verdien strukturerte data og enhver feed til agenter bør gjenspeile.

#Hvordan begrense kasseforespørsler fra agenter i WooCommerce Store API

Agenter som ikke styrer en nettleser, snakker vanligvis med Store API, det offentlige REST-laget bak handlekurv- og kasseblokkene. Rutene ligger i navnerommet wc/store/v1; API-et krever ikke autentisering og gir ifølge dokumentasjonen ikke tilgang til sensitive butikkdata eller informasjon om andre kunder (WooCommerce: Store API). Alle kasseendepunktene krever et Nonce Token eller et Cart Token. GET /wc/store/v1/checkout returnerer en utkastbestilling bygd fra gjeldende handlekurv med status checkout-draft, og POST /wc/store/v1/checkout behandler bestilling og betaling (WooCommerce: Checkout API).

Store API har innebygd hastighetsbegrensning som er slått av som standard. Når den slås på, tillater standardoppsettet 25 forespørsler i et vindu på 10 sekunder, gjelder bare POST-forespørsler og returnerer hodene RateLimit-Limit, RateLimit-Remaining og RateLimit-Reset, pluss RateLimit-Retry-After når grensen er nådd (WooCommerce: Store API rate limiting):

add_filter( 'woocommerce_store_api_rate_limit_options', function () {
    return [
        'enabled'       => true,
        'proxy_support' => false, // true bare bak en proxy du kontrollerer
        'limit'         => 25,
        'seconds'       => 10,
    ];
} );

Med proxy_support slått på identifiserer begrenseren klienten ut fra IP-adressen i videresendingshoder som X-Forwarded-For. Slå det bare på når nettstedet står bak en proxy du kontrollerer, fordi disse hodene settes av den som sender forespørselen. Begrensning i kanten (Cloudflare eller Nginx) og begrenseren i Store API utfyller hverandre: kanten tar unna trafikkbølger, og Store API begrenser hva hver enkelt klient får sluppet gjennom til PHP.

#Idempotensnøkler ved kommunikasjon med ERP-systemer

I distribuerte miljøer med maskin-til-maskin-kommunikasjon er nettverksavbrudd uunngåelige. Dersom en autonom innkjøpsrobot sender en kjøpsforespørsel og ikke mottar svar innen 3000 ms på grunn av midlertidig nettverksstøy, vil roboten automatisk sende forespørselen på nytt. Uten idempotensbeskyttelse vil denne gjentakelsen opprette en duplikatordre og trekke varer fra lageret to ganger.

Løsningen er å kreve unike idempotensnøkler i HTTP-headerne (for eksempel: Idempotency-Key: f41e89b2-3c1a-4d78-9e23-772b14c5d809).

Her er en implementering av idempotensstyring i WordPress REST API:

<?php
/**
 * Idempotens-middleware for automatiserte AI-innkjopsforesporsler
 */
declare(strict_types=1);

namespace WPPoland\ApiGovernanceNB;

final class IdempotencyGuard
{
    private \Redis $redis;

    public function __construct(\Redis $redis)
    {
        $this->redis = $redis;
    }

    public function processRequest(\WP_REST_Request $request): ?\WP_REST_Response
    {
        $idempotencyKey = $request->get_header('Idempotency-Key');
        if (empty($idempotencyKey)) {
            return new \WP_REST_Response([
                'error' => 'missing_idempotency_key',
                'message' => 'Foresporsler fra automatiserte agenter ma inneholde en Idempotency-Key header.'
            ], 400);
        }

        $redisKey = sprintf('idempotency:%s', hash('sha256', $idempotencyKey));
        $existingState = $this->redis->get($redisKey);

        if ($existingState !== false) {
            $data = json_decode((string) $existingState, true);

            if ($data['status'] === 'processing') {
                return new \WP_REST_Response([
                    'error' => 'request_in_progress',
                    'message' => 'Transaksjonen behandles allerede. Vennligst vent pa svar.'
                ], 409);
            }

            // Returner tidligere lagret svar uten a belaste lageret pa nytt
            return new \WP_REST_Response($data['response_body'], (int) $data['response_code']);
        }

        // Sett status til 'processing' med 120 sekunders TTL
        $this->redis->set($redisKey, json_encode(['status' => 'processing']), ['EX' => 120]);

        return null;
    }

    public function finalizeRequest(string $idempotencyKey, array $responseBody, int $responseCode): void
    {
        $redisKey = sprintf('idempotency:%s', hash('sha256', $idempotencyKey));

        $payload = [
            'status' => 'completed',
            'response_body' => $responseBody,
            'response_code' => $responseCode
        ];

        // Lagre svaret i 24 timer
        $this->redis->set($redisKey, json_encode($payload), ['EX' => 86400]);
    }
}

Bruk av idempotensnøkler beskytter også meldingene som overføres til ERP-systemets meldingskø. Gjentatte nettverkspakker fører dermed aldri til feilaktige lageravskrivninger eller doble pakksedler på lageret.

#Idempotency-Key i agentiske kasseprotokoller ACP og UCP

Idempotensmønsteret over er ikke en intern vane; spesifikasjonene for agentisk kasse ber om det. OpenAIs Agentic Checkout Spec definerer fem endepunkter på forhandlersiden (POST /checkout_sessions, POST /checkout_sessions/{checkout_session_id}, POST .../complete, POST .../cancel og GET /checkout_sessions/{checkout_session_id}) og lister Idempotency-Key blant hodene som sendes ved hvert kall, sammen med Request-Id, Signature, Timestamp og API-Version. En økt går gjennom statusene not_ready_for_payment, ready_for_payment, completed og canceled (OpenAI: Agentic Checkout Spec).

REST-bindingen i Universal Commerce Protocol (versjon 2026-04-08) er tydeligere om hva serveren skal gjøre. Operasjoner som endrer tilstand, bør støtte idempotens (SHOULD). Når en nøkkel sendes, skal serveren (MUST) lagre den sammen med resultatet av operasjonen i minst 24 timer, returnere det lagrede resultatet for duplikater med samme innhold og svare 409 Conflict når nøkkelen gjenbrukes med annet innhold. Kasserutene er POST /checkout-sessions, GET og PUT /checkout-sessions/{id} samt POST .../complete og POST .../cancel (UCP: checkout REST binding).

For en WooCommerce-adapter gir det to konsekvenser. Mellomvaren vist tidligere lagrer bare en hash av nøkkelen; for å oppfylle UCP-regelen må den også lagre en hash av forespørselens innhold og returnere 409 ved avvik. Og sidene i Store API-dokumentasjonen som er sitert over, beskriver ikke noe Idempotency-Key-hode. Laget som eksponerer ACP- eller UCP-endepunkter over WooCommerce, må derfor selv ta seg av deduplisering før det kaller kassen.

#Semantiske Schema.org-data og sanntids lagersignaler

AI-agenter fatter kjøpsbeslutninger basert på strukturerte metadata i HTML-koden eller i dedikerte API-strømmer. Dersom nettsidens JSON-LD-skjema viser at en vare er på lager (ItemAvailability: https://schema.org/InStock), mens lageret i realiteten ble tømt for fem sekunder siden, sender boten en forgjeves bestilling som kaster bort serverressurser.

I moderne hodeløse eller hybride nettbutikker bør lagerstatus distribueres via toveis sanntidskanaler (som Server-Sent Events eller WebSockets), mens servergenererte JSON-LD-data alltid må reflektere det aktuelle hurtigminnet:

<?php
/**
 * Dynamisk Schema.org-tilgjengelighet basert pa sanntidstilstand i Redis
 */
declare(strict_types=1);

namespace WPPoland\StructuredDataNB;

final class RealtimeAvailabilitySchema
{
    private \Redis $redis;

    public function __construct(\Redis $redis)
    {
        $this->redis = $redis;
        add_filter('woocommerce_structured_data_product_offer', [$this, 'injectDynamicAvailability'], 20, 3);
    }

    public function injectDynamicAvailability(array $offer, \WC_Product $product): array
    {
        $productId = $product->get_id();
        $stockKey = sprintf('inventory:stock:product:%d', $productId);

        $realtimeStock = $this->redis->get($stockKey);
        $stockCount = $realtimeStock !== false ? (int) $realtimeStock : $product->get_stock_quantity();

        if ($stockCount !== null && $stockCount <= 0) {
            $offer['availability'] = 'https://schema.org/OutOfStock';
            unset($offer['priceValidUntil']);
        } elseif ($stockCount !== null && $stockCount < 5) {
            $offer['availability'] = 'https://schema.org/LimitedAvailability';
            $offer['inventoryLevel'] = [
                '@type' => 'QuantitativeValue',
                'value' => $stockCount,
                'unitCode' => 'C62' // Enhetskode for stykk
            ];
        } else {
            $offer['availability'] = 'https://schema.org/InStock';
        }

        return $offer;
    }
}

For bedrifter som bygger på frakoblede arkitekturer med Next.js eller Astro, kan lagerendringer strømmes reaktivt til klientsidene uten full sideinnlasting. Se våre spesialiserte leveranser innen hodeløs e-handel på /nb/tjenester/headless-wordpress/.

#Teknisk sjekkliste for å unngå oversalg

Før store salgskampanjer lanseres eller butikken åpnes for autonome AI-innkjøpere, bør det tekniske teamet verifisere følgende punkter:

1. Databaseoppsett og HPOS-konfigurasjon

   • Deaktiver bakoverkompatibilitet med wp_posts for ordrer i innstillingene for WooCommerce HPOS.
   • Kontroller sammensatte indekser i MySQL InnoDB for customer_id, status og date_created_gmt.
   • Juster innodb_lock_wait_timeout til en stram verdi (5-10 sekunder) for å unngå opphopning av låste PHP-prosesser.

2. Hurtigminnelag for reservasjoner (Redis / Redlock)

   • Etabler Redis Sentinel eller Redis Cluster med AOF-persistering (Append Only File).
   • Bruk atomiske Lua-skripter for kurvreservasjoner med automatisk tidsbegrensning (Cart TTL).
   • Skill Redis-instansen for lagerreservasjoner fysisk fra det generelle objektlageret i WordPress.

3. Idempotens og trafikkontroll

   • Krev Idempotency-Key på alle endepunkter som manipulerer ordrer eller handlekurver.
   • Konfigurer rate limiting på Cloudflare- eller Nginx-nivå tilpasset gjenkjennbare AI-roboter.
   • Returner HTTP 429 Too Many Requests med en forklarende Retry-After-header ved overbelastning.

4. Asynkron ERP-integrasjon

   • Mellomlagre transaksjoner i en meldingskø (RabbitMQ, Apache Kafka eller AWS SQS).
   • Sikre At-Least-Once-levering kombinert med duplikatkontroll i forretningssystemet.
   • Etabler nattlige avstemmingsrutiner (Reconciliation Cron Jobs) for å korrigere eventuelle avvik.

Å tilpasse WooCommerce til autonome AI-innkjøpsagenter krever en overgang fra tradisjonelle synkrone mønstre til distribuerte systemer. Nettbutikker som satser på atomiske minnelåser, idempotens og moderne meldingskøer beskytter marginene sine og eliminerer kostbart oversalg. Kontakt våre rådgivere på /nb/kontakt/ for en gjennomgang av din transaksjonsarkitektur.