4 ระบบในบทนี้เป็นแกนของ fintech ทุกเจ้า และทั้ง 4มีบทเรียนคนละข้อ — ความถูกต้องเหนือทุกอย่าง, การออกแบบรอบ dependency ที่คุณไม่ได้ควบคุม, การแยก priority lane, และระบบที่ไม่มีใครออกแบบแต่ทุกคนต้องมี

---

Scenario 1 · E-wallet transfer พร้อม ledger ที่ถูกต้อง#

ทำไมเริ่มที่นี่: มันเป็นแม่แบบของทุกอย่างที่ความถูกต้องสำคัญกว่าทุกสิ่ง ถ้าคุณออกแบบอันนี้ได้ดี ระบบ CRUD ที่เหลือจะง่าย

S1.1 · Clarify#

S1.2 · Assess scale#

1M DAU · 0.5 การเคลื่อนย้ายเงิน/คน/วัน = 500k txn/วัน ≈ 6 tps average
peak factor 10x ปกติ, 30x วันเงินเดือนออก -> design 300 tps, burst 1,000
ledger row: 500k x 5 = 2.5M/วัน ≈ 1 GB/วัน ≈ 365 GB/ปี (+ index)
การอ่านยอด: 3M/วัน ≈ 35/s avg, ~300/s peak

ข้อสรุป: ปริมาณเล็ก *ห้าม* build เผื่อ scale
ให้ build เพื่อ correctness, auditability และ retention
Postgres ที่ replicate 1 ตัวกับ schema ที่ออกแบบดีคือคำตอบที่ถูก
และการพูดข้อนี้ออกมาอย่างมั่นใจคือสิ่งที่ senior ทำ

S1.3 · Contracts#

ตามที่ออกแบบในบทที่ 4: POST /v1/transfers พร้อม Idempotency-Key ที่บังคับ, integer หน่วยย่อย, status เริ่มต้น PENDING, URL ให้ poll และ webhook — บวกอีก 3 อย่าง:

GET /v1/accounts/acc_123/balance

{
  "available_minor": 412300,
  "total_minor": 437300,
  "currency": "THB",
  "as_of_entry_id": "01J9ABCXYZ"
}

• GET /v1/accounts/{id}/transactions?limit=20&cursor=… → keyset pagination ไม่ใช่ OFFSET
• Event: TransferCreated, TransferSettled, TransferFailed, TransferReversed ทั้งหมด key ด้วย account_id

S1.4 · Data model#

accounts(account_id, customer_id, currency, status, created_at)
-- ไม่มีคอลัมน์ balance โดยเจตนา

transactions(
  transaction_id       TEXT PRIMARY KEY,        -- ULID
  idempotency_key      TEXT NOT NULL,
  request_fingerprint  TEXT NOT NULL,           -- hash ของ canonical body
  status               TEXT NOT NULL,           -- ดู state machine ด้านล่าง
  external_ref         TEXT,                    -- reference ของ rail
  response_body        JSONB,                   -- คำตอบที่เราส่งไปแล้ว
  created_at, updated_at,
  UNIQUE (idempotency_key)   -- ฐานข้อมูลเป็นตัวกันการ post ซ้ำ
);

ledger_entries(
  entry_id       BIGSERIAL PRIMARY KEY,
  transaction_id REFERENCES transactions(transaction_id),
  account_id, direction, amount_minor BIGINT CHECK (amount_minor > 0),
  currency CHAR(3), entry_type, created_at, effective_at
)
  INDEX (account_id, entry_id DESC)   -- ประวัติ + การคำนวณ delta
  PARTITION BY RANGE (created_at);    -- รายเดือน ทำให้ archive ราคาถูก

account_balances(                     -- snapshot ที่ตรวจสอบได้ ไม่ใช่ความจริง
  account_id, currency,
  balance_minor BIGINT, available_minor BIGINT,
  last_entry_id BIGINT, updated_at
);

holds(hold_id, account_id, amount_minor, expires_at, status);
-- reservation สำหรับการเคลื่อนย้าย 2 เฟส *ต้อง* หมดอายุได้

outbox(event_id, aggregate_id, topic, payload, created_at, published_at)
  INDEX (created_at) WHERE published_at IS NULL;   -- partial: เล็กจิ๋วตลอด

S1.5 · Architecture และ write path#

System map

ขั้นตอนของ write path ทีละบรรทัด#

-- 1. Idempotency check ต้องมาก่อนทุกอย่าง
SELECT * FROM transactions WHERE idempotency_key = :key;
--    เจอ + fingerprint เหมือน  -> คืน response ที่เก็บไว้ (200)
--    เจอ + fingerprint ต่าง    -> 409 Conflict
--    ไม่เจอ                   -> ไปต่อ

-- 2. หน่วย atomic 1 หน่วย
BEGIN;
  INSERT INTO transactions (...) VALUES (... 'PENDING');
  -- unique key คือตัวกันจริง

  -- ล็อก account ตามลำดับ id เพื่อเลี่ยง deadlock
  SELECT * FROM accounts WHERE account_id IN (:a, :b)
   ORDER BY account_id FOR UPDATE;

  -- เช็ค limit กับแถวที่ materialize aggregate ไว้
  SELECT * FROM daily_limits WHERE account_id = :a
     AND limit_date = current_date FOR UPDATE;

  -- เช็คเงินพอจาก snapshot + delta
  INSERT INTO ledger_entries (...);  -- debit A, credit B, credit fee
  UPDATE account_balances ...;       -- ทั้ง 2 account, เลื่อน watermark
  UPDATE daily_limits ...;
  INSERT INTO outbox (...);          -- TransferCreated
COMMIT;

S1.6 · Deep dive#

(ก) Idempotency ที่ทำงานได้จริงตอน concurrent#

"SELECT แล้ว INSERT" แบบตรงไปตรงมามี race:
request 2 ใบที่มี key เดียวกันมาพร้อมกัน ทั้งคู่เห็นว่าไม่มี แล้ว insert ทั้งคู่
UNIQUE constraint ช่วยคุณไว้ — แต่ต้องจัดการ violation ให้ถูก:

  try:
      INSERT INTO transactions (idempotency_key, fingerprint, status)
           VALUES (:key, :fp, 'PENDING')      -- นี่คือ lock
  except UniqueViolation:
      row = SELECT * FROM transactions WHERE idempotency_key = :key
      if row.fingerprint != :fp:
          return 409                          -- bug ของ client
      if row.status == 'PENDING' and row.response_body is null:
          return 409 + Retry-After            -- ยังทำงานอยู่ ไม่ใช่เสร็จ
      return row.response_body                -- เล่นคำตอบเดิมซ้ำ

4 รายละเอียดที่แยก implementation ที่ใช้งานได้จาก demo:

1. เก็บ response ไม่ใช่แค่คำว่า "done" — การ retry ต้องได้ body ที่เหมือนกันเป๊ะ รวมถึง transfer_id ตัวเดิม ไม่อย่างนั้น client จะสร้าง record ที่ 2 ฝั่งตัวเอง
2. Fingerprint request — key เดิม + จำนวนต่าง คือ bug ของ client และต้องถูกปฏิเสธเสียงดัง ไม่ใช่ถูกมองเป็น replay อย่างเงียบๆ
3. จัดการกรณี "in flight" — request แรกอาจยังรันอยู่ คืน conflict ที่ retry ได้ ไม่ใช่เริ่มความพยายามที่ 2
4. ให้ key หมดอายุ (เช่น 24–72 ชม.) ด้วย retention job และระบุไว้ใน API doc — ตารางที่ไม่มีขอบเขตจะกลายเป็นปัญหาในที่สุด

อ้างอิง: Implementing Stripe-like idempotency keys in Postgres — มีเทคนิค "recovery point" สำหรับ resume operation หลายขั้นตรงจุดที่มันหยุด

(ข) State machine ของ transaction รวมสถานะที่ซื่อสัตย์#

System map

(ค) อ่านยอดโดยไม่ scan ประวัติ#

-- snapshot + delta = 2 indexed read ที่เร็ว
SELECT balance_minor, last_entry_id
  FROM account_balances WHERE account_id = :a;

SELECT COALESCE(SUM(CASE WHEN direction = 'CREDIT' THEN amount_minor
                         ELSE -amount_minor END), 0) AS delta
  FROM ledger_entries
 WHERE account_id = :a AND entry_id > :last_entry_id;

-- ผลลัพธ์ = balance_minor + delta

Verification job (ทุกคืน): คำนวณทุกยอดใหม่จาก entry ที่ 1 แล้วเทียบกับ snapshot ความไม่ตรงกันใดๆ ปลุกคน — job นี้จับ bug จริงได้ในทุกระบบที่ผมเคยเห็นมันถูกเพิ่มเข้าไป

S1.7 · Failure mode#

---

Scenario 2 · QR payment gateway กับ external rail#

บทเรียน: การออกแบบรอบ dependency ที่คุณไม่ได้ควบคุม ซึ่งคืองาน integration จริงส่วนใหญ่

S2.1 · Clarify#

Flow: ลูกค้าสแกน QR ของร้าน → แอปแสดงชื่อร้านและจำนวน → ลูกค้ายืนยัน → รายการถูก authorize และ settle → ทั้ง 2 ฝ่ายได้ notification และใบเสร็จ

QR 2 แบบที่ต่างกันเชิงสถาปัตยกรรม:

Quality attribute หลัก: ร้านต้องไม่ได้รับเงิน 2 ครั้งจากการซื้อครั้งเดียว · ลูกค้าต้องไม่ถูกหักเงินโดยที่ร้านไม่ได้รับ · หน้าจอร้านต้อง update ภายใน ~3 s (นี่คือเคาน์เตอร์ที่มีคิวรออยู่ข้างหลัง) · settlement เข้าบัญชีร้านตามรอบของ scheme ไม่ใช่ทันที

Non-goal ของ v1: refund/refund บางส่วน, tip, โหมด offline, ข้ามประเทศ, ผ่อนชำระ

S2.2 · Assess scale#

200k ร้าน, 2M การจ่าย/วัน  -> 23 tps average
พีคของค้าปลีกคม: มื้อเที่ยง (11:30-13:00) และเย็น (17:00-20:00) บวกสิ้นเดือน
สมมติ 15x -> ~350 tps peak, burst 1,000 tps

งบ latency ตั้งแต่ "ลูกค้ายืนยัน" ถึง "ร้านเห็นว่าจ่ายแล้ว":
  app -> API ของเรา          50 ms
  งาน authorization ของเรา    50 ms
  RAIL round trip        300-3,000 ms   <-- ครอบงำ และไม่ใช่ของเรา
  post-processing ของเรา      30 ms
  push ถึงเครื่องร้าน       200-1,500 ms  <-- mobile network
  ------------------------------------
  p95 ที่เป็นจริง ~2-3 s, p99 แย่กว่านั้น

ผลที่ตามมา: หน้าจอลูกค้ารอทุกอย่างแบบ synchronous ไม่ได้
ออกแบบ UX 2 เฟส: "กำลังดำเนินการ" ทันที แล้วค่อยยืนยันแบบ push
และร้านต้องมี POLLING fallback เพราะการส่ง push ไม่มีการรับประกัน

S2.3 · Contracts#

POST /v1/payments
Idempotency-Key: <uuid>

{
  "qr_payload": "00020101...",
  "amount": { "currency": "THB", "minor_units": 15000 },
  "source_account_id": "acc_1",
  "device_id": "dev_9",
  "client_txn_ref": "app-ref-8891"
}

{
  "payment_id": "pay_01J9XYZ",
  "status": "PROCESSING",
  "merchant": { "name": "ร้านกาแฟหน้าปากซอย", "id": "mch_7" },
  "poll_after_ms": 500,
  "expires_at": "2026-08-08T04:12:00Z"
}

S2.4 · Data model ที่สำคัญ#

payments(payment_id, idempotency_key UNIQUE, merchant_id,
         customer_account_id, amount_minor, currency, status,
         rail_ref, qr_hash, created_at, expires_at, terminal_at)
  INDEX (merchant_id, created_at DESC)                    -- รายการของร้าน
  INDEX (status) WHERE status IN ('PROCESSING','UNKNOWN'); -- hot set

qr_codes(qr_id, merchant_id, type, amount_minor NULL,
         reference, expires_at, status);   -- type = STATIC | DYNAMIC

rail_attempts(attempt_id, payment_id, attempt_no, request_hash,
              rail_ref, sent_at, response_code, response_at,
              raw_response JSONB);
-- ทุกการเรียก rail ถูกบันทึก ทั้ง request และ response

-- ledger_entries / transactions -- เหมือน Scenario 1 เป๊ะ

S2.5 · Architecture#

System map

S2.6 · Deep dive#

(ก) เรียก external rail อย่างปลอดภัย — 7 ข้อ#

1. สร้าง reference ที่ idempotent ของเราเองสำหรับ rail
   derive จาก payment_id ของเรา และ *ใช้ตัวเดิมทุกครั้งที่ retry*
   -> ห้ามสร้าง reference ใหม่ตอน retry นั่นคือวิธีสร้างการจ่ายซ้ำที่ rail

2. TIMEOUT จาก p99 ที่ rail ระบุไว้ในเอกสาร ไม่ใช่จากเลขกลม
   แยก connect (สั้น) จาก read timeout

3. RETRY เฉพาะ connection error และ code ที่ retryable เท่านั้น
   พร้อม backoff + full jitter, จำกัดจำนวนครั้ง, และมี retry budget
   *ห้าม retry การปฏิเสธเชิงธุรกิจ*

4. CIRCUIT BREAKER ต่อ rail
   ตอนเปิด: เข้าคิว payment ใหม่แล้วบอกลูกค้าตามจริง
   ("ธนาคารนี้ใช้งานไม่ได้ชั่วคราว") หรือ route ไป rail สำรอง
   ถ้ามีและร้านรองรับ

5. BULKHEAD: rail adapter มี connection pool และ worker pool ของตัวเอง
   rail ที่ช้าต้องไม่กิน thread ที่ใช้ serve การอ่านยอด

6. RESPONSE VALIDATION: ตรวจว่า response ของ rail อ้างถึง
   *reference ของเรา* และ *จำนวนของเรา* ก่อนจะเชื่อมัน
   ที่ไม่ตรงให้ไป quarantine ไม่ใช่ไป ledger

7. UNKNOWN: ตอน timeout ห้ามเดา
   mark UNKNOWN, ให้ status reconciler ปิดสถานะ,
   และ *ถือเงินลูกค้าไว้เป็น hold ไม่ใช่ debit* จนกว่าจะปิดสถานะ
   เพื่อให้เงินไม่ถูกใช้ซ้ำและไม่ดูเหมือนถูกยึดไป

(ข) 6 ฉากของการจ่ายซ้ำ และการป้องกันของแต่ละฉาก#

(ค) Refund ไม่ใช่ "undo"#

S2.7 · Failure mode#

---

Scenario 3 · OTP และ notification service#

บทเรียน: priority lane และการที่ dependency ระดับรองต้องไม่อยู่ใน critical path

S3.1 · Assess scale#

1M DAU: login 400k/วัน, ยืนยันธุรกรรม 500k/วัน
ปริมาณ OTP ~500k/วัน -> 6/s average
แต่ LOGIN พีคที่ 08:00-09:00 และ 19:00-21:00: สมมติ 20x -> ~120/s

Marketing campaign: push 1 ล้านใบในครั้งเดียว
ถ้าส่งผ่าน pipeline เดียวกับ OTP ค่า p95 ของ OTP จะกลายเป็นหลายนาที
--> นี่คือ incident จริงที่พบบ่อยที่สุดในระบบนี้
--> PRIORITY LANE ที่แยกกันเป็น REQUIREMENT ไม่ใช่ optimization

ค่า SMS ครอบงำงบประมาณ: ที่ประมาณ 0.25-0.75 บาท/ข้อความ (illustrative)
500k/วัน เป็นบรรทัดค่าใช้จ่ายรายเดือนที่ใหญ่มาก
การควบคุมต้นทุนจึงเป็น requirement เชิงสถาปัตยกรรม:
  - push ก่อน SMS เป็น fallback (push แทบฟรี)
  - OTP 1 ใบต่อ (user, purpose) ต่อ 60 s
  - เพดานแข็งต่อวันต่อ user และต่อ IP
  - alert ที่ความผิดปกติของต้นทุนต่อวัน ไม่ใช่รอตอนได้ใบแจ้งหนี้

S3.2 · Contracts#

POST /v1/otp/request
{ "user_id": "usr_1", "purpose": "LOGIN", "channel_hint": "PUSH" }

{
  "otp_id": "otp_01J9XYZ",
  "expires_at": "2026-08-08T04:05:00Z",
  "resend_after_s": 60,
  "masked_destination": "08X-XXX-1234"
}

POST /v1/otp/verify
{ "otp_id": "otp_01J9XYZ", "code": "482913" }

{ "code": "INVALID_OR_EXPIRED", "attempts_remaining": 2 }

S3.3 · Data model#

otp_requests(
  otp_id, user_id, purpose, channel, destination_hash,
  code_hash,            -- HASH พร้อม salt ต่อ record ห้ามเก็บ plaintext
  expires_at,           -- 3-5 นาที
  attempts INT,         -- สูงสุด 3-5 แล้ว invalidate
  consumed_at,          -- ใช้ครั้งเดียว บังคับแบบ atomic
  created_at, ip_hash, device_id
)
  INDEX (user_id, purpose, created_at DESC);  -- resend + velocity check

notifications(notification_id, user_id, channel, template, priority,
              dedupe_key, status, provider, provider_msg_id, attempts,
              created_at, sent_at, delivered_at, failed_reason)
  UNIQUE (dedupe_key)                          -- กันการส่งซ้ำ
  INDEX (status, priority, created_at) WHERE status = 'QUEUED';

user_channel_prefs(user_id, channel, consent, consent_source,
                   consent_at, quiet_hours, locale);
-- consent เป็น compliance artefact: บันทึกว่าเขายินยอม *อะไร*, *เมื่อไหร่*,
-- และผ่าน flow ไหน · การส่งเชิง marketing *ต้อง* เช็คมัน

S3.4 · Architecture: priority lane#

System map

S3.5 · Deep dive#

2 SMS provider ตั้งแต่วันแรก — การส่ง SMS ในทุกตลาดแปรผันตามผู้ให้บริการมือถือ, เวลาของวัน และ routing ของ provider เอง ให้คะแนน provider แต่ละรายอย่างต่อเนื่องด้วย delivery rate และ latency ต่อ prefix ของ operator แล้ว route ตามนั้น เมื่อ delivery rate ของ A ไปยัง operator หนึ่งตก ให้ย้าย traffic อัตโนมัติ — นี่คือการลงทุนทางวิศวกรรมที่ให้ผลตอบแทนสูงสุดใน service นี้ และเป็นคำตอบของคำถาม "ถ้า provider ล่มจะทำอย่างไร"

Push ก่อน SMS เป็น fallback — ถ้าผู้ใช้มีอุปกรณ์ที่ลงทะเบียนและสุขภาพดี ส่ง in-app approval push ถ้าไม่ตอบรับใน ~10 s ให้ตกไป SMS วิธีนี้ลดต้นทุนได้มากและปลอดภัยกว่า ต้องมี device registry ที่แม่นและจัดการ token ที่หมดอายุ — token หมดอายุได้และ provider จะบอกคุณ ถ้าไม่ประมวลผล callback นั้น delivery rate ของคุณจะเน่าอย่างเงียบๆ

Delivery receipt เป็น asynchronous และไม่น่าเชื่อถือ — "ส่งแล้ว" ไม่ใช่ "ถึงแล้ว" ติดตามทั้งคู่, alert ที่ช่องว่างระหว่าง 2 ค่า, และห้ามบอกผู้ใช้ว่า "เราส่งไปแล้ว" เมื่อ provider คืน error ให้มีเส้นทาง "ไม่ได้รับรหัส?" ที่ซื่อสัตย์และมี rate limit

Quiet hours และ consent บังคับใน pipeline สำหรับ bulk และข้ามอย่างชัดแจ้งสำหรับ critical

Template rendering และ localization อยู่ที่เดียว พร้อมบันทึก template ID และ version บนทุก message ที่ส่ง — เมื่อมีคนถามว่า "เราส่งอะไรให้ลูกค้าคนนี้วันที่ 3 มีนาคม" คุณต้องตอบด้วย เนื้อหาที่ render แล้ว ไม่ใช่ชื่อ template

S3.6 · Failure mode#

---

Scenario 4 · Reconciliation และ reporting#

บทเรียน: ระบบที่ไม่มีใครออกแบบ ทุกคนต้องมี และ auditor ถามทุกครั้ง ถ้าคุณทำงาน fintech การเชี่ยวชาญเรื่องนี้ทำให้คุณดู senior อย่างเห็นได้ชัด

S4 · Requirements#

• ทุกวัน พิสูจน์ว่า record ของเราตรงกับ record ของคู่ค้าภายนอกแต่ละราย (แต่ละ bank rail, แต่ละ card scheme, แต่ละ partner) และ record ภายในของเราตรงกันเอง
• ทุกความต่าง ("break") ต้องถูกตรวจพบ, จัดหมวด, มอบเจ้าของ, และแก้ไขพร้อม audit trail ตรวจพบภายในวันเดียวกัน มี SLA การแก้ต่อหมวด
• ผลิตรายงานรายวันและรายเดือนที่ธุรกิจและ regulator ต้องการ จาก snapshot ที่คงที่

S4 · Architecture#

System map

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

---

Lab 18 — Scenario sprint (ครึ่งวัน)#

รูปแบบ: 3 รอบ รอบละ 60 นาที สลับบทบาท ในแต่ละรอบมี architect 1 คน, business stakeholder 1 คน (ถือ constraint ที่ซ่อนไว้ ซึ่งจะเปิดเผยเฉพาะเมื่อถูกถามคำถามที่ถูก), และ reviewer 1 คน (ต้องหารูให้ได้ 3 รู)

Brief (เลือก 3 อัน):

Constraint ที่ซ่อนไว้ ให้ stakeholder เปิดเผยเฉพาะเมื่อถูกถาม (เลือก 1 ข้อต่อรอบ):

• ธนาคาร partner มี maintenance window 4 ชั่วโมงทุกวันอาทิตย์
• Regulator ต้องการรายงานเฉพาะภายใน 24 ชั่วโมงหลังสิ้นเดือน
• Merchant รายเดียวคิดเป็น 40% ของปริมาณ
• แอปมือถืออัปเดตไม่ได้เป็นเวลา 6 สัปดาห์
• ข้อมูลต้องไม่ออกนอกประเทศ

Deliverable ต่อรอบ: ตาราง requirement, estimation, diagram 1 ใบ, failure table, และ ADR 1 ฉบับ