Cheat Sheet & Checklists

บทนี้ไม่มีเนื้อหาใหม่ — มันคือหน้าที่คุณเปิดค้างไว้ตอนออกแบบ และคือ checklist ที่คุณรันกับ design ของตัวเองก่อนที่คนอื่นจะรันให้

A · Cheat sheet 1 หน้า#

CADENCE
  Clarify · Assess scale · Define contracts · Entities/data ·
  Nail architecture · Critical deep dives · Examine failures

MENTAL MATH
  1 วัน ≈ 86,400 s (ใช้ 100k)       1 M/วัน ≈ 12/s
  100 M/วัน ≈ 1,200/s               peak = average × 5-30 (ต้องรู้ว่าเท่าไหร่)
  1 M row × 500 B = 500 MB          index บวก 1.5-3×

LATENCY
  memory 100 ns · SSD read 100 µs · same-AZ RTT 0.5 ms
  BKK↔SG ~30 ms · BKK↔US ~240 ms · mobile TTFB 50-150 ms

AVAILABILITY
  99.9% = 43 นาที/เดือน      99.99% = 4.4 นาที/เดือน
  dependency แบบอนุกรม *คูณกัน*: 0.999^5 = 99.5%
  L = λW (Little's Law): concurrency = อัตรา × latency

RESILIENCE CHECKLIST (ทุกการเรียกข้ามเครื่อง)
  timeout · retry ที่มี backoff+jitter+budget · idempotency key ·
  circuit breaker · bulkhead · queue ที่มีขอบเขต · fallback ที่นิยามไว้ ·
  metric + alert · trace propagate · deadline propagate

DATA RULES
  เงิน = integer หน่วยย่อย + currency ห้าม float
  ledger = append-only double-entry, balance derive มา
  atomic write เดียว + outbox — ห้าม dual write
  at-least-once + consumer ที่ idempotent = effectively once
  normalize ความจริง, denormalize read model
  เลือก partition key ก่อนที่จะต้องใช้
  ตอน write ให้ delete cache key ห้าม update
  keyset pagination ห้าม OFFSET

เมื่อไม่แน่ใจ
  component น้อยลง · Postgres ตัวเดียว · async ตรงที่อนุญาต ·
  fail closed เรื่องเงิน · ประกาศสมมติฐาน · เขียน ADR

B · Design review checklist#

Requirement และ scope#

• Non-goal เขียนไว้ไหม — และ ลบ component ไหนได้ไหมโดยไม่ละเมิด requirement
• Quality attribute เป็นตัวเลข ไม่ใช่คำคุณศัพท์ ทุกข้อไหม
• ทุกกล่องใน diagram ไล่กลับไปหา requirement ได้ไหม

Data#

• มี access pattern table ไหม และ ทุก index serve pattern ที่อยู่ในลิสต์ไหม
• มี dual write ที่ไหนไหม — ถ้ามี ใช้ outbox หรือ CDC แทนได้ไหม
• Consumer ทุกตัว idempotent ไหม dedupe key คืออะไร
• Partition/shard key เขียนไว้ไหม แม้จะยังไม่ใช้
• Read-your-writes — มีเส้นทาง read-after-write ไหนที่ไปที่ replica ไหม
• Pagination ใช้ keyset ไม่ใช่ OFFSET ไหม
• Invariant สำคัญอยู่ใน database constraint ไหม

Reliability#

• Availability แบบอนุกรมของ critical path เท่าไหร่ และ dependency ตัวไหนถอดออกจาก critical path ได้
• ทุกการเรียกข้ามเครื่อง: timeout, retry policy, idempotency, circuit breaker, fallback
• เกิดอะไรที่ 10× โหลด · ที่ 0 โหลด (cache เย็น, cold start) · ระหว่าง deploy
• Queue, pool, buffer มีขอบเขตทุกตัวไหม
• Failure table ครบ พร้อมสัญญาณตรวจจับทุกแถว ไหม
• มีแถว "คน" ใน failure table ไหม

Observability และ operations#

• SLO นิยามต่อ user journey พร้อม burn-rate alert ไหม
• มี alert ที่ business outcome และที่ สิ่งที่ควรเกิดแล้วไม่เกิด ไหม
• Runbook สำหรับ alert 3 อันดับแรกไหม · kill switch สำหรับเส้นทางเสี่ยงไหม
• Rollout: flag, ขั้นการ ramp, metric ที่เป็น gate, เงื่อนไข rollback, และใครอนุมัติการ release ขึ้น production
• Backup: มีอยู่จริง, แยกจาก credential ของ production, และ ทดสอบ restore แล้วพร้อมเวลาที่วัดได้

Privacy และ security#

• Retention และการลบ: ระยะเวลาเท่าไหร่, ใครยืนยัน, และเป็น automated ไหม
• PII: minimize แล้ว, mask ใน log, encrypted, มี audit การเข้าถึงไหม
• มี secret ในโค้ดหรือใน config ที่อยู่ใน git ไหม
• Trust boundary อยู่ใน diagram ไหม

การตัดสินใจ#

• เขียน ADR สำหรับทุกการตัดสินใจที่เป็น one-way door ไหม
• ทุกตัวเลขในเอกสารกำกับว่า verified / estimated / assumed ไหม
• รายการ การตัดสินใจที่ต้องการจากคนอื่น พร้อมชื่อและวันที่ ไหม

C · Fintech-specific checklist#

เงินและ ledger#

• เงินเป็น integer พร้อม currency ทุกที่ รวมถึงในรายงานและใน event ไหม
• Ledger append-only, double-entry, และ monitor zero-sum ต่อเนื่อง ไหม
• มี monitor debit รวม = credit รวมทั้งระบบ ต่อสกุลเงินรันอยู่ไหม
• ค่าธรรมเนียมมี fee account — เงินไม่หายไปในค่าธรรมเนียมไหน
• Snapshot ของยอดมี job คำนวณใหม่จากศูนย์แล้วเทียบ ไหม

Idempotency และสถานะ#

• Idempotency key required บนทุก endpoint ที่เปลี่ยนแปลงเงิน และบังคับด้วย unique constraint ไหม
• เก็บ response ที่เคยส่งไป เพื่อเล่นซ้ำได้ไหม (ไม่ใช่เก็บแค่ "done")
• มี request fingerprint เพื่อตอบ 409 เมื่อ key เดิม body ต่างไหม
• มี สถานะ UNKNOWN ที่ชัดเจน ไหม และ ไม่มีอะไรออกจากสถานะนั้นด้วยการเดาหรือด้วย timer ใช่ไหม
• ข้อความที่ลูกค้าเห็นเมื่อผลลัพธ์ไม่ทราบ พูดว่า "กำลังดำเนินการ" ไม่ใช่ "ล้มเหลว" ใช่ไหม

Reconciliation และ control#

• Reconciliation ออกแบบเข้าไปแล้ว: source, cutoff, matching pass, การจัดหมวด break, เจ้าของ, SLA, alert
• มี alert ที่ "ไม่ได้รับไฟล์ settlement" และ "งาน reconciliation ไม่จบ" ไหม
• มี job อัตโนมัติตัวไหนเปลี่ยนยอดเงินลูกค้าได้โดยไม่มีคนอนุมัติไหม — ต้องไม่มี
• Fail-open กับ fail-closed ถูกตัดสินโดย Risk สำหรับทุก control (fraud, limit, sanctions screening) และมีเอกสารไหม
• Limit (ต่อรายการ, ต่อวัน, velocity) ถูกบังคับที่จุดที่ request พร้อมกันข้ามไม่ได้ (แถวที่ materialize conflict หรือ SERIALIZABLE) ไหม

ข้อมูลและการเข้าถึง#

• ข้อมูลบัตร: ไม่เก็บ PAN เลย และ ขอบเขต scope วาดอยู่ใน diagram ไหม
• Audit trail ครบว่าใครทำอะไรกับเงินของใคร, immutable, เก็บตามนโยบาย ไหม
• Production access, การแก้ข้อมูล และ operation ที่ destructive อยู่หลัง least privilege และการอนุมัติ 4 ตา ไหม
• ข้อมูล production ไม่ถูก copy ลง dev/test ใช่ไหม

Dependency ภายนอก#

• มี 2 provider สำหรับทุก dependency ภายนอกที่ critical หรือมี เอกสารว่ายอมรับความเสี่ยงของการมีรายเดียว ไหม
• รู้ maintenance window และ cutoff time ของแต่ละ rail ไหม
• Subscribe status page ของ provider แบบ programmatic ไหม (ไม่ใช่ต้องจำไปเปิดดู)
• มี rail_attempts หรือเทียบเท่าที่บันทึกทุกการเรียกภายนอกเป็นข้อมูล ไหม

D · แผนฝึก 12 สัปดาห์#

E · Reading list#

หนังสือ#

• Designing Data-Intensive Applications — Kleppmann · หนังสือที่จำเป็นเล่มเดียว อ่าน 2 รอบ
• Site Reliability Engineering + The SRE Workbook — Google, ฟรี
• Patterns of Distributed Systems — Joshi/Fowler, ฟรี · กลไก: write-ahead log, leader election, quorum, lease, HLC
• Fundamentals of Software Architecture — Richards & Ford · คำศัพท์เรื่อง trade-off และการมองแบบ architecture characteristics ที่ใช้ในบทที่ 17
• Microservices Patterns — Richardson · saga, outbox, API composition, CQRS อย่างเข้มงวด

Essay ฟรี (คุ้มค่าต่อชั่วโมงสูงสุด)#

• Amazon Builders' Library — เริ่มที่: timeout & retry with jitter · using load shedding to avoid overload · implementing health checks · avoiding fallback in distributed systems · caching challenges and strategies
• Marc Brooker's blog — queueing, scaling และสัญชาตญาณเรื่อง distributed system จาก principal engineer ของ AWS
• Netflix Tech Blog · Discord Engineering · Shopify Engineering · Slack Engineering · Stripe blog · Monzo Technology
• รายการ postmortem สาธารณะ — อ่านสัปดาห์ละหนึ่ง
• Awesome Scalability — index ของบทความวิศวกรรมจากโลกจริง แยกตามหัวข้อ

Paper ที่ควรอ่านให้จบ#

• The Tail at Scale — Dean & Barroso
• Dynamo — ต้นกำเนิดของ consistent hashing + quorum + eventual consistency ในทางปฏิบัติ
• Scaling Memcache at Facebook
• Spanner — global strong consistency มีราคาเท่าไหร่จริงๆ
• Jepsen: consistency models — บวกการวิเคราะห์ Jepsen ของฐานข้อมูลที่คุณใช้

Primary source สำหรับ fintech และบริบทไทย#

F · Glossary#

---