Integrity: Outbox, CDC & Ledger

ถ้าคุณทำงานสาย fintech บทนี้เป็นหน้าที่มีค่าที่สุดในคอร์ส ยอดเงินใน wallet ที่เก็บเป็นตัวเลขที่แก้ได้ในคอลัมน์เดียว คือความผิดพลาดเชิงออกแบบที่ร้ายแรงและพบบ่อยที่สุดในอุตสาหกรรมนี้

Dual-write problem — bug ข้อมูลกระจายที่พบบ่อยที่สุด#

// ดูสมเหตุสมผลทุกประการ และมันพัง
db.save(transfer);              // สำเร็จ
kafka.publish(transferCreated); // process ตายที่นี่ หรือ broker ล่ม

ผลลัพธ์: ฐานข้อมูลบอกว่ามี transfer นี้ แต่ไม่มีระบบปลายน้ำไหนรู้
notification ไม่เคยส่ง, read model ไม่เคย update, partner ไม่เคยรู้
และ *ไม่มี error เกิดขึ้นเลย* คุณรู้เรื่องจากลูกค้า

สลับลำดับก็ไม่ช่วย — กลายเป็น publish event ของ transfer
ที่ไม่เคยถูกบันทึก (phantom event)

ไม่มีลำดับใดของการเขียน 2 ที่แบบอิสระที่ปลอดภัย
คุณต้องมี *การเขียนที่ atomic 1 ครั้ง* บวก *relay ที่เชื่อถือได้*

System map

Transactional outbox — ทางแก้ และมันเรียบง่าย#

BEGIN;
  INSERT INTO transfers (...) VALUES (...);
  INSERT INTO ledger_entries (...) VALUES (...), (...);
  INSERT INTO outbox (event_id, aggregate_id, topic, payload, created_at)
       VALUES ($1, $2, 'payments.transfer.v1', $3, now());
COMMIT;   -- หน่วย atomic 1 หน่วย ฐานข้อมูลเดียว

-- Relay process แยก ทำงานต่อเนื่อง
SELECT event_id, topic, payload, aggregate_id
  FROM outbox
 WHERE published_at IS NULL
 ORDER BY created_at
 LIMIT 500
   FOR UPDATE SKIP LOCKED;      -- ให้ relay worker หลายตัวรันได้อย่างปลอดภัย

-- --> publish ไป broker
UPDATE outbox SET published_at = now() WHERE event_id = ANY($1);

หมายเหตุเชิง operational ที่ต้องมี#

Change data capture (CDC)#

แทนที่จะมีตาราง outbox ให้อ่าน replication log ของฐานข้อมูล แล้วเปลี่ยนการเปลี่ยนแปลงทุกแถวเป็น event (Debezium เป็นเครื่องมือมาตรฐาน)

Saga — transaction ข้าม service#

เมื่อ business operation หนึ่งกินหลาย service คุณใช้ database transaction ไม่ได้ Saga คือลำดับของ local transaction ที่แต่ละตัวมี compensating action ถ้าขั้นถัดไปล้ม

ORCHESTRATED SAGA — "ซื้อประกันด้วยยอดเงินใน wallet"

  1. reserve funds        (wallet)     comp: release reservation
  2. create policy        (insurance)  comp: void policy
  3. capture funds        (wallet)     comp: refund
  4. issue documents      (docs)       comp: revoke + notify

Orchestrator ถือ state machine เรียกแต่ละขั้น
และเมื่อล้มก็รัน compensation ย้อนกลับ

Choreography (แต่ละ service ตอบสนองต่อ event) เลี่ยง component กลางได้
แต่ทำให้ flow ทั้งหมด *มองไม่เห็น* — ไม่มีใครตอบได้ว่า
"ใบสมัครนี้ค้างอยู่ที่ขั้นไหน"

System map

กฎที่ได้มาด้วยความเจ็บปวด#

อ้างอิง: Saga pattern · Patterns of Distributed Systems

ออกแบบข้อมูลเงิน: ledger#

ผิด — balance เป็นคอลัมน์ที่แก้ได้#

accounts(account_id, balance_minor)
UPDATE accounts SET balance_minor = balance_minor - 30000;

ทำไมมันพัง — ในทางปฏิบัติ ทุกครั้ง:
 - ไม่มีประวัติ "ทำไมยอดผมเหลือ 4,231" -> ตอบไม่ได้
 - ไม่มี audit trail auditor ขอที่มาของตัวเลข คุณไม่มีให้
 - 1 แถวต่อ 1 account = lock hot spot บน account ที่ยุ่งที่สุด
 - bug ที่เขียนค่าผิดกู้คืนไม่ได้ ความจริงก่อนหน้านั้นหายไปแล้ว
   ไม่มีอะไรให้ reconcile เทียบด้วย
 - เงินถูกสร้างหรือทำลายได้ด้วย transaction ที่ขาดไป 1 ใบ
   โดยไม่มีความไม่สมดุลที่ไหนให้ตรวจจับได้

ถูก — immutable double-entry ledger + balance ที่ derive มา#

-- ทุกการเคลื่อนย้ายคือ entry 2 ใบหรือมากกว่า ที่ *รวมกันได้ 0*
-- ไม่มีการ update และไม่มีการ delete การแก้ไขคือ entry ใบใหม่

CREATE TABLE ledger_entries (
  entry_id        TEXT        PRIMARY KEY,          -- ULID, immutable
  transaction_id  TEXT        NOT NULL,             -- จัดกลุ่ม entry ของการเคลื่อนย้ายเดียว
  account_id      TEXT        NOT NULL,
  direction       TEXT        NOT NULL CHECK (direction IN ('DEBIT','CREDIT')),
  amount_minor    BIGINT      NOT NULL CHECK (amount_minor > 0),
  currency        CHAR(3)     NOT NULL,
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  effective_at    TIMESTAMPTZ NOT NULL,             -- วันที่ทางธุรกิจต่างจากวันที่ระบบได้
  entry_type      TEXT        NOT NULL              -- TRANSFER|FEE|REVERSAL|ADJUSTMENT|SETTLEMENT
);

CREATE TABLE transactions (
  transaction_id  TEXT        PRIMARY KEY,
  idempotency_key TEXT        NOT NULL,
  status          TEXT        NOT NULL,             -- PENDING|SETTLED|REJECTED|UNKNOWN|REVERSED
  external_ref    TEXT,
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  CONSTRAINT transactions_idem UNIQUE (idempotency_key)
);

Invariant แกนกลาง ที่ตรวจได้ทุกเมื่อ#

-- ต้องคืน "0 แถว" เสมอ — รันเป็น monitor ต่อเนื่อง
SELECT transaction_id,
       SUM(CASE WHEN direction = 'DEBIT' THEN amount_minor
                ELSE -amount_minor END) AS imbalance
  FROM ledger_entries
 GROUP BY transaction_id
HAVING SUM(CASE WHEN direction = 'DEBIT' THEN amount_minor
                ELSE -amount_minor END) <> 0;

ตัวอย่าง: โอน 250.00 บาท จาก A ไป B พร้อมค่าธรรมเนียม 2.00#

DEBIT   A            25200
CREDIT  B            25000
CREDIT  fee_income     200
--> 25200 - 25000 - 200 = 0  รวมกันได้ 0

Balance — derive มา ไม่เคยเก็บเป็นความจริง#

-- นิยาม
balance(account) = SUM(credits) - SUM(debits)

-- ที่ scale จริง ห้าม sum entry ย้อนหลัง 10 ปีทุกครั้งที่อ่าน — ใช้ snapshot
CREATE TABLE account_balances (
  account_id     TEXT        NOT NULL,
  currency       CHAR(3)     NOT NULL,
  balance_minor  BIGINT      NOT NULL,   -- ณ ...
  last_entry_id  TEXT        NOT NULL,   -- ... entry นี้ (watermark)
  updated_at     TIMESTAMPTZ NOT NULL,
  PRIMARY KEY (account_id, currency)
);

-- Read path: snapshot + SUM(entry ที่ใหม่กว่า last_entry_id)

กฎของข้อมูลเงิน — บทเรียนที่อุตสาหกรรมจ่ายค่าเรียนไปแล้ว#

Data lifecycle, retention และ privacy by design#

Tiering — คำตอบของ "ฐานข้อมูลเรา 8 TB แล้ว"#

Privacy และ retention เป็นสถาปัตยกรรม#

Data minimisation — ไม่เก็บสิ่งที่ไม่ต้องใช้ ไม่ copy มันไปอีก 3 ระบบ ทุกสำเนาคือพื้นที่ข้อมูลรั่วและภาระการลบ ภายใต้ PDPA ของไทย ภาระผูกพันเดินตามข้อมูลไปทุกที่ที่มันไป — รวมถึง data lake, log, backup และ vendor ด้าน analytics ของคุณ

การลบยากกว่าที่คิด — คำขอลบข้อมูลต้องไปถึง primary store, read model, search index, cache, message backlog, analytics warehouse, log และ backup

แนวทางที่ใช้กันจริง:
  ระบบที่ยังใช้งาน     -> hard delete
  ชั้นที่ immutable/backup -> crypto-shredding
                          (เข้ารหัสข้อมูลของแต่ละ subject ด้วย key ของ subject นั้น
                           แล้วทำลาย key)

Card data — วิธีที่ถูกที่สุดในการปฏิบัติตามกฎของ card scheme คือ ไม่เก็บ PAN เลย · tokenize ที่ขอบเขต, เก็บข้อมูลบัตรไว้ในขอบเขตที่แคบและแยกออกมา, และทำให้มันไปถึง log, trace, error report และ analytics ของคุณไม่ได้

Encryption — TLS ทุกที่รวม hop ภายใน · encryption at rest ด้วย managed key · field-level encryption สำหรับ attribute ที่อ่อนไหวที่สุด (เลขบัตรประชาชน, เลขบัญชี) เพื่อให้ database dump เพียงอย่างเดียวไม่พอที่จะเปิดเผยมัน

Test data — ข้อมูลส่วนบุคคลจาก production ห้าม copy ลง development หรือ test ใช้ข้อมูลสังเคราะห์หรือข้อมูลที่ mask แบบย้อนกลับไม่ได้ — เป็นทั้งข้อกำหนด compliance ในระบอบกฎหมายส่วนใหญ่ และเป็นมาตรการป้องกันการรั่วที่แท้จริง

Schema migration แบบไม่ต้องปิดระบบ#

Pattern expand–migrate–contract ที่คุณจะใช้ไปตลอดอาชีพ

1. EXPAND    เพิ่มคอลัมน์/ตารางใหม่ ให้เป็น nullable ยังไม่ใส่ constraint
             deploy โค้ดที่ *เขียนทั้งเก่าและใหม่* แต่ *อ่านของเก่า*

2. BACKFILL  copy ข้อมูลย้อนหลังเป็น batch เล็กๆ แบบมี throttle
             และมีตาราง progress เพื่อให้ resume ได้
             *ห้าม UPDATE ก้อนเดียวใหญ่ๆ* — มันล็อก, ทำให้บวม, และหยุดกลางทางไม่ได้

3. VERIFY    เทียบเก่ากับใหม่ ตัวอย่างก่อน แล้วทั้งหมด
             shadow-read: serve จากของเก่า, คำนวณจากของใหม่, log ความต่าง
             *ห้ามไปต่อขณะที่ยังมีความต่าง*

4. SWITCH    deploy โค้ดที่ *อ่านของใหม่* แต่ยังเขียนทั้งคู่
             นี่คือจุดที่ย้อนกลับได้ — flag พลิกกลับได้

5. CONTRACT  หยุดเขียนของเก่า แล้ว (อีกนานหลังจากนั้น) ค่อยลบ

กฎของ migration#

-- Header ของทุก migration
SET lock_timeout = '3s';
SET statement_timeout = '30s';

-- และสำหรับ index บนตารางใหญ่
CREATE INDEX CONCURRENTLY IF NOT EXISTS ...;   -- รันนอก transaction

Lab 16 — สร้าง ledger ที่ถูกต้อง (สำคัญที่สุดในคอร์ส)#

ใช้ Postgres และภาษาอะไรก็ได้ ทำตามลำดับ ห้ามข้าม

Deliverable: repository พร้อมเอกสาร 1 หน้าที่มี ยอดที่ผิดจากขั้นที่ 2, ตัวเลข throughput ทั้ง 4จากขั้นที่ 3, และ invariant query