Distributed Transactions — xizmatlar aro izchillik

Monolitda bitta baza bilan tranzaksiya oson: BEGIN … COMMIT, ACID hammasini "yo hammasi, yo hech nima" qiladi. Lekin mikroservisda (database-per-service, 1-mavzu) bitta biznes amali bir necha xizmat va bazaga tegadi.

Avval nega oddiy tranzaksiya yetmasligini aniq tushunamiz:

ACID tranzaksiya — bitta baza ulanishining xususiyati. Uch xil bazada uch xil ulanish bor, ularni bitta BEGIN…COMMITga bog‘lab bo‘lmaydi. Demak: yo hammasini birlashtiruvchi koordinator kerak (2PC), yo butunlay boshqa model (Saga).

2PC qanday ishlaydi

Koordinator ikki fazada boshqaradi:

Faza 1 (prepare): koordinator hammadan "commit qila olasizmi?" deb so‘raydi, har biri tayyorlanadi va qulflaydi, "ha" deydi. Faza 2 (commit): hamma "ha" desa — koordinator "commit" buyuradi; kimdir "yo‘q" desa — hamma "abort" qiladi. Atomiklik kafolatlanadi.

Saga qanday ishlaydi

Har xizmat o‘z mahalliy ACID tranzaksiyasini bajaradi va keyingisini ishga tushiradi. Biror qadam muvaffaqiyatsiz bo‘lsa — oldingi qadamlarni teskari tartibda bekor qiluvchi (compensating) tranzaksiyalar ishga tushadi:

Muhim: bu ACID emas, eventual consistency. Oralig‘ida tizim vaqtincha nomuvofiq bo‘lishi mumkin (buyurtma bor, lekin hali tasdiqlanmagan), lekin oxir-oqibat izchil holatga keladi — yo hammasi bajariladi, yo hammasi bekor qilinadi.

Saga’ni muvofiqlashtirishning ikki uslubi bor:

1 · Orchestration — markaziy koordinator

Bitta orkestrator qadamlarni ketma-ket chaqiradi, holatni kuzatadi va xatolikda kompensatsiyani boshqaradi. Mantiq bir joyda — murakkab jarayonlar uchun aniqroq:

// ORCHESTRATION SAGA: markaziy koordinator qadamlar + kompensatsiyalarni boshqaradi
async placeOrder(dto: CreateOrderDto) {
  const undo: (() => Promise<void>)[] = [];       // kompensatsiya stack'i
  try {
    const order = await this.orders.create(dto);            // 1-qadam
    undo.push(() => this.orders.cancel(order.id));

    await this.inventory.reserve(order.id, dto.items);      // 2-qadam
    undo.push(() => this.inventory.release(order.id));

    await this.payment.charge(order.id, dto.amount);        // 3-qadam
    undo.push(() => this.payment.refund(order.id));         // refund = kompensatsiya

    await this.orders.confirm(order.id);                    // yakuniy
    return order;
  } catch (err) {
    for (const compensate of undo.reverse()) {              // TESKARI tartibda bekor qil
      await compensate();                                   // idempotent bo'lishi SHART
    }
    throw new SagaFailedException(err);
  }
}

2 · Choreography — markaziy koordinatorsiz

Koordinator yo‘q; har xizmat eventga reaksiya qilib, keyingi eventni chiqaradi (3-mavzu). Oddiy oqimlar uchun yengil, lekin mantiq tarqoq:

// CHOREOGRAPHY SAGA: markaziy koordinator YO'Q; har xizmat eventga reaksiya qiladi
@EventPattern("order.created")
async onOrderCreated(order: Order) {
  try {
    await this.reserve(order.items);
    this.client.emit("inventory.reserved", { orderId: order.id });  // keyingi qadam
  } catch {
    this.client.emit("order.failed", { orderId: order.id });        // kompensatsiya trigger
  }
}

Kompensatsiyaning qiyin tomonlari

• Kompensatsiya ham muvaffaqiyatsiz bo‘lishi mumkin: "inventarni bo‘shat" ham xato bersa? → retry + idempotency (14-mavzu) shart. Kompensatsiya qayta-qayta xavfsiz bajarilishi kerak.
• Ba’zi amallarni bekor qilib bo‘lmaydi: email yuborildi, SMS ketdi — "un-send" yo‘q. Yechim: bunday amallarni saga oxiriga qo‘y (hammasi tasdiqlangach), yoki "bekor qilindi" xabari yubor.
• Izolyatsiya yo‘q: saga davomida boshqa tranzaksiya oralig‘idagi holatni ko‘rishi mumkin (buyurtma yaratilgan, lekin hali tasdiqlanmagan). Bu — "dirty read"ga o‘xshash muammo.

• Bitta ACID tranzaksiya faqat bitta baza ichida ishlaydi. Mikroservisda (database-per-service) biznes amali ko‘p bazaga tegadi — oddiy tranzaksiya yetmaydi.
• 2PC (prepare + commit) atomiklik beradi, lekin bloklovchi, SPOF, sekin — mikroservisda qochiladi.
• Saga — standart yechim: ketma-ket mahalliy tranzaksiyalar + xatolikda kompensatsiya (rollback emas — refund kabi yangi teskari amal). Eventual consistency.
• Choreography (event, tarqoq — oddiy oqim) vs Orchestration (markaziy koordinator — murakkab oqim).
• Qiyin tomonlar: kompensatsiya ham fail bo‘lishi, bekor qilib bo‘lmaydigan amallar, izolyatsiya yo‘qligi. Har qadam idempotent bo‘lishi shart. Eng yaxshisi — to‘g‘ri chegaralar bilan taqsimlangan tranzaksiyani umuman keltirmaslik.