E-ticaret: sepet, stok rezervasyonu ve sipariş akışı

Problem

"Büyük bir e-ticaret pazaryeri için sepet, stok ve sipariş oluşturma akışını tasarla. Binlerce satıcı, birden fazla depo, misafir ve üye kullanıcılar var. Kullanıcı sepetine ürün ekler, ödeme adımına geçer, sipariş verir. Stokta olmayan bir ürün satılmamalı (oversell), ama stok da gereksiz yere kilitlenip satış kaçırılmamalı. Kasım kampanyalarında trafik on katına çıkıyor."

Kitap Bölüm 20'de tek bir üründen 50.000 adetlik flash sale çözüldü: bekleme odası, Redis Lua ile atomik stok ve kovalar. Bu case gündelik e-ticaret akışıdır: milyonlarca farklı ürün, her biri birkaç adet ya da birkaç bin adet stokla, çok kalemli sepetler, satıcıların kendi sistemlerinden gönderdiği stok güncellemeleri ve sipariş-ödeme-stok arasındaki dağıtık akış. Mülakatçı burada en çok şu kararlara bakar: stok ne zaman ayrılır, ayırma nasıl atomik yapılır, rezervasyon nasıl geri verilir, sepet neden rezervasyon değildir ve sipariş akışı yarıda kalırsa ne olur.

Netleştirme soruları ve varsayımlar

Kapsam dışı: flash sale (Kitap Bölüm 20), arama ve öneri, kargo takibi, iade süreci.

Kapasite tahmini

Kullanıcı              : 20M DAU
Sepet işlemleri        : kişi başı 5 (ekle, çıkar, görüntüle) = 100M/gün ≈ 1.160 /s
                         Kasım tepesi (x10)                    ≈ 11.600 /s, çoğu okuma
Sipariş                : normal gün 2M ≈ 23 /s
                         Kasım günü 10M, en yoğun saatte %15 = 1,5M/saat ≈ 420 /s
                         en yoğun dakikalarda ~1.000 /s
Rezervasyon satırı     : sipariş başına ortalama 2,5 kalem -> Kasım günü 25M satır

Aktif sepet            : 30M sepet x ~2 KB ≈ 60 GB
Stok satırı            : 50M SKU x ortalama 1,5 depo = 75M satır x ~100 B ≈ 7,5 GB (+ index)

Teşhis:

• Sepet okuma ağırlıklıdır ve kullanıcı bazında izoledir: iki kullanıcı aynı sepete yazmaz. Bu, sepeti kullanıcı id'siyle bölünen basit bir anahtar-değer erişimine çevirir.
• Stok tablosu küçüktür (index'lerle on GB mertebesi), tek bir PostgreSQL kümesine sığar. Sorun boyut değil, sıcak satırlardır: kampanyadaki popüler bir ürünün (sku, depo) satırına saniyede yüzlerce rezervasyon gelir ve satır kilidinde sıraya girer. Kitap Bölüm 22'deki ölçümde tek bir sıcak satıra yazan tam bir transaction, satırlar dağınıkken ~2.270 tps olan hızın ~400 tps'ye düştüğü görüldü.
• Sipariş akışı birden fazla servise dokunur (stok, ödeme, sipariş). Asıl zorluk tek bir yazmanın hızı değil, yarıda kalan akışın tutarlı şekilde tamamlanması ya da geri alınmasıdır.

API

GET    /api/v1/cart
PUT    /api/v1/cart/items/{skuId}         { "sellerId": 42, "quantity": 2 }    # idempotent: miktarı ayarla
DELETE /api/v1/cart/items/{skuId}
POST   /api/v1/cart/merge                 { "guestCartToken": "..." }          # girişten sonra

POST   /api/v1/checkout/preview
-> 200 { "items": [...], "total": "1249.90", "priceVersion": "pv_9f..",
         "warnings": [ { "skuId": 77, "code": "PRICE_CHANGED", "old": "199.90", "new": "219.90" },
                       { "skuId": 81, "code": "LOW_STOCK", "available": 1 } ] }

POST   /api/v1/orders
Idempotency-Key: 3c1f...
{ "priceVersion": "pv_9f..", "addressId": 5, "paymentMethodToken": "tok_..." }
-> 201 { "orderId": 98213, "status": "PENDING_PAYMENT", "payment": { "status": "REQUIRES_ACTION", "redirectUrl": "..." } }
-> 409 { "code": "OUT_OF_STOCK", "items": [ { "skuId": 81, "requested": 2, "available": 1 } ] }
-> 409 { "code": "PRICE_CHANGED", "priceVersion": "pv_a1.." }

GET    /api/v1/orders/{orderId}

# Satıcı entegrasyonu
PUT    /seller-api/v1/stocks          [ { "sku": "S-77", "warehouseId": 3, "quantity": 50, "sourceUpdatedAt": "..." } ]

• Sepete ekleme POST yerine PUT miktar ayarlama olarak modellenir: mobil istemci tekrar gönderirse miktar iki katına çıkmaz.
• priceVersion, kullanıcının onayladığı fiyatları temsil eder; sipariş anında fiyat değişmişse sipariş oluşmaz, kullanıcı yeni fiyatı görür. Kullanıcıya görmediği bir fiyatı ödetmemek hem ürün hem hukuk kuralıdır.
• Sipariş oluşturma idempotency key ister: çift tıklama ya da timeout sonrası tekrar ikinci sipariş yaratmamalı (Kitap Bölüm 18).

Veri modeli

Sepet (kullanıcı id'siyle bölünmüş anahtar-değer ya da doküman deposu; örneğin Couchbase, ya da PostgreSQL'de JSONB):

{ "cartId": "u:7", "version": 18, "updatedAt": "...",
  "items": [ { "skuId": 77, "sellerId": 42, "quantity": 2, "addedAt": "...", "priceAtAdd": "199.90" } ] }

priceAtAdd sadece "fiyatı düştü/yükseldi" göstermek içindir; sipariş fiyatı her zaman fiyat servisinden yeniden hesaplanır. version alanı aynı kullanıcının iki cihazdan eşzamanlı güncellemesinde optimistic locking içindir.

Stok ve rezervasyon (PostgreSQL):

CREATE TABLE inventory (
    sku_id        BIGINT NOT NULL,
    warehouse_id  INT    NOT NULL,
    on_hand       INT    NOT NULL CHECK (on_hand >= 0),          -- fiziksel stok (satıcının bildirdiği)
    reserved      INT    NOT NULL DEFAULT 0 CHECK (reserved >= 0),-- ödeme bekleyen siparişlere ayrılmış
    version       BIGINT NOT NULL DEFAULT 0,
    source_updated_at TIMESTAMPTZ,                                  -- satıcının son güncellemesinin kaynak zamanı
    PRIMARY KEY (sku_id, warehouse_id),
    CONSTRAINT inventory_reserved_le_on_hand CHECK (reserved <= on_hand)
);

CREATE TABLE stock_reservations (
    id            BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    order_id      BIGINT      NOT NULL,
    sku_id        BIGINT      NOT NULL,
    warehouse_id  INT         NOT NULL,
    quantity      INT         NOT NULL CHECK (quantity > 0),
    status        VARCHAR(16) NOT NULL DEFAULT 'ACTIVE',          -- ACTIVE, CONFIRMED, RELEASED
    expires_at    TIMESTAMPTZ NOT NULL,
    created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
    CONSTRAINT stock_reservations_status_valid CHECK (status IN ('ACTIVE','CONFIRMED','RELEASED')),
    CONSTRAINT stock_reservations_order_sku_uq UNIQUE (order_id, sku_id, warehouse_id)
);
CREATE INDEX stock_reservations_expiry_idx ON stock_reservations (expires_at) WHERE status = 'ACTIVE';

Satılabilir stok on_hand - reserved'dir. on_hand ile reserved'in ayrı tutulması, satıcının stok güncellemesi ile bizim rezervasyonlarımızın birbirini ezmemesini sağlar (aşağıda).

Sipariş: orders(id, user_id, status, total, price_version, idempotency_key, ...), order_items(order_id, sku_id, seller_id, warehouse_id, quantity, unit_price) ve olaylar için outbox.

Yüksek seviye tasarım

flowchart LR
    C[Mobil ve web] --> GW[API gateway]
    GW --> CART[Sepet servisi]
    CART --> CS[(Sepet deposu)]
    CART --> PRICE[Fiyat ve kampanya servisi]
    GW --> CO[Sipariş servisi ve saga orkestratörü]
    CO --> ODB[(Sipariş DB ve outbox)]
    CO --> INV[Stok servisi]
    INV --> IDB[(Stok DB)]
    CO --> PAY[Ödeme servisi]
    ODB -->|outbox relay| K[(Kafka)]
    IDB -->|stok değişikliği CDC| K
    K --> SRCH[Arama indeksi ve ürün sayfası projeksiyonu]
    K --> NOTIF[Bildirim servisi]
    SELLER[Satıcı ERP sistemleri] --> SAPI[Satıcı stok API'si]
    SAPI --> INV
    SW[Rezervasyon süpürücüsü] --> IDB

• Sepet servisi stoğa dokunmaz; sadece "ürün şu an satılabilir görünüyor mu" diye projeksiyondan okur.
• Stok servisi satılabilir stoğun tek doğruluk kaynağıdır; rezervasyon, onay ve iade sadece onun API'leriyle yapılır.
• Sipariş servisi saga'nın orkestratörüdür: stok rezervasyonu, ödeme provizyonu, onay ve telafi adımlarını sırayla ve kalıcı durumla yürütür.
• Ürün sayfası ve arama stok bilgisini asenkron bir projeksiyondan okur (CDC ya da outbox ile güncellenir); birkaç saniyelik gecikme kabul edilir.

Derinlemesine

Stok ne zaman ayrılır?

Seçim: sipariş anında, süreli rezervasyon. Sepet bir alışveriş listesidir, rezervasyon değildir. Sipariş verildiğinde stok 15 dakikalığına ayrılır; ödeme tamamlanınca rezervasyon onaylanır, tamamlanmazsa süresi dolunca stoğa geri döner. Sepette gösterilen "son 2 ürün" uyarıları kullanıcıyı checkout'a yönlendirir ama bir söz değildir. Flash sale gibi talebin stoğu çok aştığı durumlarda farklı bir yapı gerekir (Kitap Bölüm 20).

Oversell'i önlemek: koşullu güncelleme ve son savunma

Rezervasyon, kontrol ve değişikliği tek ifadede birleştiren koşullu bir UPDATE'tir; rezervasyon satırıyla aynı transaction'da yazılır:

BEGIN;
WITH r AS (
    UPDATE inventory
       SET reserved = reserved + :qty, version = version + 1
     WHERE sku_id = :sku AND warehouse_id = :wh
       AND on_hand - reserved >= :qty
    RETURNING sku_id, warehouse_id
)
INSERT INTO stock_reservations (order_id, sku_id, warehouse_id, quantity, expires_at)
SELECT :orderId, sku_id, warehouse_id, :qty, now() + interval '15 minutes' FROM r;
COMMIT;

UPDATE satırı kilitler; aynı satırı güncellemek isteyen ikinci transaction bekler ve READ COMMITTED'da birinci commit olunca satırın güncel halinde WHERE koşulunu yeniden değerlendirir (Kitap Bölüm 10 ve 22). Koşul tutmazsa etkilenen satır 0'dır ve rezervasyon satırı da eklenmez.

Beklenen davranış (gerçek PostgreSQL'de, ör. Testcontainers ile eşzamanlı bir testle doğrulanmalı): stoğu 100 olan tek bir ürüne 50 eşzamanlı istemciden toplam 2.000 rezervasyon denemesi gönderilirse tam olarak 100 rezervasyon oluşur, reserved 100'de kalır ve hiçbir transaction hata almaz; başarısız denemeler koşul tutmadığı için 0 satır döner.

CHECK (reserved <= on_hand) son savunmadır: uygulamadaki bir hata koşulu atlasa bile veritabanı fazla rezervasyonu reddeder. Ama Kitap Bölüm 22'deki uyarı burada da geçerlidir: constraint lost update'i yakalamaz; asıl doğruluk koşullu güncellemededir.

Çok kalemli sipariş. Sepette 5 farklı ürün varsa ya hepsi ayrılır ya hiçbiri. Stok tablosu tek bir veritabanındaysa beş koşullu güncelleme tek transaction'da yapılır; herhangi biri 0 satır dönerse transaction geri alınır ve hangi kalemin yetmediği kullanıcıya döner. İki önemli detay:

• Kilit sırası: İki sipariş aynı iki ürünü ters sırada kilitlerse deadlock olur. Kalemler her zaman (sku_id, warehouse_id) sırasına göre işlenir.
• Stok tablosu bölünmüşse (SKU'ya göre shard), çok kalemli rezervasyon dağıtık hale gelir: her shard'da ayrı rezervasyon, biri başarısız olursa diğerlerinin iadesi (saga içinde telafi). Tek veritabanı yetiyorsa bu karmaşıklıktan kaçınmak bilinçli bir tercihtir.

Depo seçimi

Ürün birden fazla depoda varsa rezervasyon belirli bir depodan yapılır. Basit kural: kullanıcıya en yakın, stoğu yeten depo; yetmezse kalemi ikinci depodan tamamlamak (bölünmüş gönderi) ya da bütün kalemi tek depodan karşılayabilecek depoyu seçmek. Seçim mantığı stok servisinin içindedir ve rezervasyon kaydı hangi depodan yapıldığını taşır; kargo ve depo operasyonları bu bilgiye göre çalışır.

Rezervasyonun yaşam döngüsü

ACTIVE ──ödeme onaylandı──────> CONFIRMED   (on_hand -= q, reserved -= q; ardından tahsilat)
ACTIVE ──süre doldu / iptal───> RELEASED    (reserved -= q)

Her geçiş kaynak durumu koşul olarak taşır (WHERE status = 'ACTIVE'); böylece aynı rezervasyonun iki kez iade edilmesi ya da iade edilmiş bir rezervasyonun onaylanması imkansızdır. Süpürücü ile ödeme onayı yarışırsa sadece biri kazanır. Ödeme onayı rezervasyonu ACTIVE bulamazsa (süresi dolmuş ve iade edilmiş) ödeme provizyonu iptal edilir ve sipariş başarısız olur; para alınıp ürün verilmemesi durumu oluşmaz (aynı sıra Kitap Bölüm 20'de).

Süresi dolanları iade etmek. Birden fazla süpürücü pod'u aynı satırları işlemesin diye FOR UPDATE SKIP LOCKED kullanılır:

WITH expired AS (
    SELECT id FROM stock_reservations
     WHERE status = 'ACTIVE' AND expires_at < now()
     ORDER BY expires_at
     LIMIT 100
       FOR UPDATE SKIP LOCKED
), released AS (
    UPDATE stock_reservations r SET status = 'RELEASED'
      FROM expired e WHERE r.id = e.id
    RETURNING r.sku_id, r.warehouse_id, r.quantity
), agg AS (
    SELECT sku_id, warehouse_id, sum(quantity) AS qty
      FROM released GROUP BY sku_id, warehouse_id
)
UPDATE inventory i SET reserved = i.reserved - agg.qty
  FROM agg WHERE i.sku_id = agg.sku_id AND i.warehouse_id = agg.warehouse_id;

PostgreSQL dokümantasyonu SKIP LOCKED'ın tutarsız bir görünüm verdiğini, bu yüzden genel amaçlı sorgular için uygun olmadığını ama kuyruk benzeri tablolarda birden fazla tüketicinin kilit çekişmesini önlemek için kullanılabileceğini söyler; bu tam o kullanımdır. Örneğin 30 süresi dolmuş rezervasyon varken LIMIT 20 ile iki süpürücü eşzamanlı çalışırsa birincisi 20 kaydı kilitleyip işlerken ikincisi onları atlar ve kalan 10'u iade eder; toplam 30, çift iade yok. Partial index (WHERE status = 'ACTIVE') süpürücünün sorgusunu küçük tutar.

Neden Redis TTL'i ile değil? Redis keyspace bildirimleri kaybolabilir ve expired olayı zamanında üretilmeyebilir (Kitap Bölüm 20); para değerinde bir iade buna bağlanmaz.

Sipariş saga'sı

sequenceDiagram
    participant U as Kullanıcı
    participant O as Sipariş servisi
    participant I as Stok servisi
    participant P as Ödeme servisi
    U->>O: POST /orders ve Idempotency-Key
    O->>O: sipariş PENDING ve saga durumu kaydedilir
    O->>I: kalemleri rezerve et, 15 dk
    I-->>O: rezervasyon tamam
    O->>P: provizyon iste
    P-->>O: AUTHORIZED veya 3DS gerekli
    O-->>U: 201 PENDING_PAYMENT
    Note over O,P: 3DS tamamlanınca ödeme servisi event yayınlar
    O->>I: rezervasyonları onayla
    I-->>O: onaylandı
    O->>P: tahsilat
    O->>O: sipariş CONFIRMED ve outbox event

Telafi adımları:

Saga'nın kendi durumu sipariş veritabanında saklanır; orkestratör pod'u çökse bile başka bir pod kaldığı adımdan devam eder. Her adım idempotent'tir (rezervasyon (order_id, sku_id, warehouse_id) unique, ödeme idempotency key'li), bu yüzden bir adımı tekrar çalıştırmak güvenlidir. Sipariş durumu değişiklikleri outbox ile Kafka'ya yayınlanır (Kitap Bölüm 13).

Satıcı stok güncellemeleri: dışarıdaki doğruluk kaynağı

Pazaryerinde fiziksel stoğu satıcı bilir; kendi ERP'sinden "S-77 ürünü, 3 numaralı depoda 50 adet" diye mutlak değer gönderir. Bu, bizim rezervasyonlarımızla çakışabilir:

• Güncelleme sadece on_hand'i değiştirir; reserved'e dokunmaz. Satıcının "50" demesi, "ödeme bekleyen 5 rezervasyon dahil fiziksel stoğum 50" anlamına gelir; satılabilir stok 45 olur.
• Sırasız güncellemeler: Satıcının iki güncellemesi ters sırayla gelirse eski değer yenisini ezer. Her güncelleme satıcı tarafındaki zaman damgasını veya sıra numarasını taşır; daha eski bir güncelleme yok sayılır (WHERE source_updated_at < :incoming).
• Stok rezervasyonun altına düşerse: Satıcı mağazada sattı ve yeni stok 3, ama 5 adetlik aktif rezervasyon var. CHECK (reserved <= on_hand) bu güncellemeyi reddeder. Sessizce reddetmek yanlış (satıcının fiziksel gerçeği bu); sessizce kabul etmek de yanlış (oversell). İş kuralı açıkça seçilir: güncelleme kabul edilir, satılabilir stok sıfırlanır, fazla rezervasyonlar en yeniden başlayarak iptal edilir ve kullanıcılara bildirilir, olay satıcı performans metriğine yazılır. Bu bir mülakatta "constraint son savunmadır ama iş kuralının yerini tutmaz" demenin somut örneğidir.

Okuma yolu: ürün sayfasındaki stok bilgisi

Milyonlarca ürün sayfası görüntülemesi stok veritabanına gitmez. Stok değişiklikleri (CDC ya da outbox ile) Kafka'ya, oradan arama indeksine ve ürün sayfası cache'ine yayılır; birkaç saniye geriden gelir. "Stokta var" bilgisi bu yüzden bir ipucudur; karar checkout'ta stok servisinden verilir. Düşük stoklu ürünlerde "son 3 ürün" gibi gösterimler de projeksiyondan gelir. Sepet sayfası açıldığında sepetteki kalemler için toplu ve hafif bir uygunluk sorgusu yapılır (cache'lenmiş projeksiyondan), checkout önizlemesinde ise stok servisinden.

Sepet tasarımı

• Depolama: Sepet kullanıcı başına tek bir dokümandır, erişim anahtarla. Kullanıcılar sepetin cihazlar arası ve haftalarca kalmasını bekler; bu yüzden kalıcı bir depo (doküman deposu ya da PostgreSQL JSONB) + önünde cache. Sadece Redis'te tutmak, eviction ya da failover'da sepet kaybı demektir.
• Eşzamanlılık: Aynı kullanıcı iki cihazdan aynı anda değiştirirse version ile optimistic locking; çakışmada sepet yeniden okunup değişiklik uygulanır.
• Misafir sepeti ve birleştirme: Misafir sepeti cihaz token'ıyla tutulur. Girişte üye sepetiyle birleşir: aynı ürün iki sepette varsa miktarlar toplanır ama ürün başına satış limiti ve makul bir üst sınırla kırpılır; birleştirme idempotent olmalıdır (aynı misafir token'ıyla ikinci kez çağrılırsa miktarlar tekrar toplanmaz; birleştirilen misafir sepeti işaretlenir).
• Fiyat: Sepette gösterilen fiyat fiyat servisinden okunur (kampanya ve kupon kuralları dahil); checkout önizlemesi priceVersion üretir ve sipariş bu versiyonla doğrulanır.
• Limitler: Sepet kalem sayısı ve ürün başına adet sınırı (botların devasa sepetleri ve kötüye kullanım için).
• Ömür: Dokunulmayan sepetler 60-90 gün sonra silinir; terk edilen sepet hatırlatması bildirim sistemine bir olaydır.

Sıcak ürün: kampanyadaki çok satan

Normal bir kampanyada popüler bir ürünün tek (sku, depo) satırına saniyede yüzlerce rezervasyon gelebilir. Kademeli çözümler:

1. Önce ölç. Koşullu güncelleme kısa bir transaction'dır; saniyede birkaç yüz rezervasyonu tek satırda karşılayabilir. Kampanya öncesi yük testi bu sınırı gösterir.
2. Depolara bölünmüş stok: Ürün zaten birden fazla depodaysa rezervasyonlar depolar arasında dağılır; doğal bir kovalama.
3. Mantıksal kovalar: Tek depodaki stok N alt satıra bölünür (bucket kolonu); rezervasyon rastgele bir kovadan denenir, boşsa diğerine geçilir.
4. Redis önyüzü: Talebin stoğu çok aştığı durumlarda Redis'te atomik bir sayaç ön filtre olur ve veritabanı son savunma kalır (Kitap Bölüm 20). Bu, karmaşıklık getirdiği için sadece ölçüm gerektirdiğinde.

Kasım hazırlığı

Önceden ölçekleme (HPA tepki süresi dalgayı yakalayamaz), kampanya profiliyle yük testi, kritik olmayan özelliklerin (öneriler, "bunu alanlar şunu da aldı") yük altında kapatılabilmesi (feature flag), stok ve sipariş veritabanında connection havuzu ve index kontrolü, ve sipariş akışı için ayrı bir dashboard: rezervasyon başarı/başarısızlık oranı, aktif rezervasyon sayısı, süpürücü gecikmesi, saga'da bekleyen siparişler, ödeme UNKNOWN sayısı.

Darboğazlar, hatalar ve trade-off'lar

Trade-off'lar:

• Sipariş anında rezervasyon: Stok kilitlenmez; bedeli sepette görünen ürünün checkout'ta tükenebilmesi.
• Tek stok veritabanı: Çok kalemli rezervasyon tek transaction'da atomik; bedeli yazma ölçeğinin tek kümeyle sınırlı olması (75M satırlık tablo için yeterli).
• Asenkron stok projeksiyonu: Okuma yolu ucuz; bedeli birkaç saniyelik bayatlık.
• Orkestrasyonlu saga: Akış tek yerde görünür ve izlenir; bedeli orkestratörün kendi durumunu yönetmesi.

Üç seviyede cevap

Soru: "Stoğu ne zaman düşersin: sepete eklerken mi, sipariş verirken mi, ödeme alınınca mı?"

Soru: "Aynı ürünün son adedini iki kişi aynı anda sipariş ederse ne olur?"

Soru: "Satıcı ERP'sinden 'stok 3' güncellemesi geldi ama o ürün için 5 adet aktif rezervasyon var. Ne yaparsın?"

Mülakatçı için

Takip soruları:

• Kupon ve kampanya kuralları sipariş anında nasıl doğrulanır; tek kullanımlık bir kuponun iki siparişte kullanılması nasıl engellenir?
• Kullanıcı ödeme sayfasında 14. dakikada. Rezervasyonu uzatır mısın?
• Ürün sayfasındaki "stokta" bilgisinin gecikmesini nasıl ölçersin?
• Siparişin bir kalemi kargoya çıkamadı (depoda hasarlı). Hangi servisler, hangi sırayla etkilenir?

Seviye beklentisi: Mid seviyede süreli rezervasyon, koşullu güncelleme, süpürücü ve saga'nın ana hatları beklenir. Senior'dan veri modelinde on_hand/reserved ayrımı, çok kalemli atomiklik ve kilit sırası, yarışların kapatılması, satıcı stok entegrasyonu gibi pazaryeri gerçekleri ve sıcak ürün için ölçüme dayalı kademeli çözüm beklenir.

Hızlı tekrar

Kaynaklar

• Alex Xu, Sahn Lam, System Design Interview: An Insider's Guide (Cilt 2): "Hotel Reservation System" bölümündeki envanter ve eşzamanlılık tartışması.
• Martin Kleppmann, Designing Data-Intensive Applications: Bölüm 7 (transaction'lar, lost update, write skew).
• PostgreSQL: SELECT, The Locking Clause: NOWAIT ve SKIP LOCKED'ın davranışı ve kuyruk benzeri tablolarda kullanımı.
• PostgreSQL: Explicit Locking: Satır kilitleri, deadlock'lar ve advisory lock'lar.