Day 13: Decision Matrix - App vs. DB Boundaries & CPU Protection (การกำหนดขอบเขตสถาปัตยกรรมระหว่าง Application Layer และ Database Layer, การสร้าง Decision Matrix, และการปกป้อง CPU ของฐานข้อมูล)

ในอดีต ยุค Monolithic DB มักมีค่านิยมสุดโต่งเขียน Business Logic ทุกอย่างไว้ใน Stored Procedures จน DB กลายเป็น "Monolithic Brain" แต่ในยุค Cloud-Native ปัจจุบัน การหลับหูหลับตาโยนทุกอย่างลง DB ทำให้เซิร์ฟเวอร์ DB เกิด CPU Bottleneck 100% และค้างทั้งระบบ ในทางกลับกัน หากผลักทุกอย่างไปอยู่บน App ก็จะเกิดปัญหา Chatty Network RTT และขาดความปลอดภัยด้าน Data Integrity!

⚖️ แม่บทดรรชนีการตัดสินใจเชิงสถาปัตยกรรม (Architectural Decision Matrix)

การออกแบบระบบแบบ Clean Boundary เริ่มจากการมองเห็นจุดตัดการทำงานอย่างชัดเจน: ฝั่ง App ทำงานที่เป็น CPU-Bound / External I/O ให้เสร็จสิ้น แล้วส่งเฉพาะค่าที่จำเป็นมาให้ Stored Procedure ฝั่ง DB ทำงานที่เป็น Data-Bound / Atomic Mutation รวดเดียวจบ:

-- ❌ ANTI-PATTERN (Heavy CPU inside DB):
-- App ---> CALL pr_everything() ---> [ Hash Password ] -> [ Parse Large JSON ] -> [ Update Table ] -> [ Call External HTTP API ]

-- ✅ REFACTORED PATTERN (Clean Boundaries):
-- 1. App Server [ Hash Password (bcrypt) & Validate JSON ] (CPU-Bound บน Stateless App)
-- 2. App Server ---> CALL pr_atomic_save(hash, jsonb) ---> DB Server [ INSERT/UPDATE + Audit Trigger ] (Data-Bound บน DB)
-- 3. App Server <--- Return Success <--- DB Server (ปลด DB Connection ทันทีใน < 2ms)
-- 4. App Server ---> Call External Payment API / Send Email (External I/O บน App นอก DB Transaction!)

🏋️‍♂️ แบบฝึกหัดไต่ระดับการเขียนจริง (จากระดับเริ่มต้น ➔ Clean Boundary Architecture)

-- 🎯 โจทย์: วิเคราะห์ตรรกะ 3 ข้อนี้ ว่าควรจัดวางไว้ที่เลเยอร์ใดจึงจะถูกต้องตาม Decision Matrix?
-- ข้อ [1]: การทำ Password Hashing ด้วย bcrypt / Argon2
-- ข้อ [2]: การคำนวณยอดเงินคงเหลือสุทธิจากรายการโอน 1,000,000 แถวในตาราง
-- ข้อ [3]: การส่ง Email / SMS แจ้งเตือนลูกค้าหลังชำระเงินสำเร็จ

-- ✅ เฉลยและเหตุผลเชิงสถาปัตยกรรม:
-- ข้อ [1] ➔ Application Layer:
--     เหตุผล: เป็นงาน CPU-Bound มหาศาล ยิ่งตั้ง Work Factor สูงยิ่งกิน CPU การทำบน App ช่วยให้สเกลเครื่อง App Node เพิ่มได้ง่าย
-- ข้อ [2] ➔ Database Layer (PL/pgSQL):
--     เหตุผล: เป็นงาน Data-Bound ต้องอ่าน Data Pages ใน shared_buffers การทำบน DB ช่วยตัด Network RTT และลดเวลาเหลือเสี้ยววินาที
-- ข้อ [3] ➔ Application Layer:
--     เหตุผล: เป็น External I/O ห้ามเอาไปไว้ใน DB Trigger เด็ดขาด เพราะถ้าเมลเซิร์ฟเวอร์ช้า จะดึง DB Connection ค้างจนระบบล่ม!

-- db/migration/R__01_atomic_settlement.sql
-- 🎯 ฝั่ง DB เน้นเฉพาะ Atomic State Transition และ Data Integrity เท่านั้น!
-- รับพารามิเตอร์สำเร็จรูปที่ผ่านการคำนวณและตรวจสอบมาจาก App เรียบร้อยแล้ว

CREATE OR REPLACE PROCEDURE pr_execute_settlement_atomic(
    p_account_id BIGINT,
    p_amount     NUMERIC,
    p_auth_hash  VARCHAR -- รับ Hash ที่คำนวณเสร็จแล้วมาจาก App
)
LANGUAGE plpgsql
AS $$
BEGIN
    -- [1] ตรวจสอบและล็อกแถวแบบ Atomic (Data Integrity Boundary)
    PERFORM 1 FROM accounts WHERE account_id = p_account_id FOR UPDATE;

    -- [2] อัปเดตยอดเงินใน DB (รันติดชิด RAM Buffer ในเสี้ยววินาที)
    UPDATE accounts
    SET balance = balance - p_amount
    WHERE account_id = p_account_id;

    -- [3] บันทึก Audit Log ทันที
    INSERT INTO transaction_logs(account_id, amount, auth_hash, type)
    VALUES (p_account_id, -p_amount, p_auth_hash, 'SETTLEMENT');

    -- [4] ยืนยัน Transaction และปลด Lock ทันที ไม่ค้างคา
    COMMIT;
END $$;

🔴 Level 3: Refactoring Flawed Code (ย้ายงาน CPU-Bound ออกจาก PL/pgSQL สู่ App Layer)

เปรียบเทียบโค้ดเดิมที่นำ Hashing และ String Manipulation มายัดใน Stored Procedure จน DB CPU 100% กับโค้ดใหม่ที่แบ่งขอบเขตการทำงานอย่างถูกต้อง:

-- ❌ Flawed Code: เอา Hashing และ String Manipulation มาทำใน PL/pgSQL
CREATE OR REPLACE PROCEDURE pr_process_user_registration_flawed(
    p_username TEXT,
    p_raw_password TEXT,
    p_json_payload TEXT
)
LANGUAGE plpgsql
AS $$
DECLARE
    v_hashed_pw TEXT;
    v_parsed_data JSONB;
BEGIN
    -- ❌ CPU Bottleneck #1: คำนวณ Hash หนักๆ ใน DB (เผา CPU บน DB)
    v_hashed_pw := digest(p_raw_password || 'salt_secret', 'sha256');

    -- ❌ CPU Bottleneck #2: Parse และ Clean String ขนาดใหญ่ใน DB RAM
    v_parsed_data := p_json_payload::jsonb;

    INSERT INTO users(username, password_hash, profile_data)
    VALUES (p_username, v_hashed_pw, v_parsed_data);

    COMMIT;
END $$;

-- db/migration/R__02_user_registration_optimized.sql
-- 🎯 ฝั่ง App ทำการ Hash Password และ Parse JSON มาให้เสร็จเรียบร้อยแล้ว
-- ฝั่ง DB มีหน้าที่รับค่าสำเร็จรูปมาทำ INSERT แบบ Lightning Fast!

-- [Statement 1] สร้าง Stored Procedure ที่เน้นเฉพาะ Data Persistence
CREATE OR REPLACE PROCEDURE pr_process_user_registration_optimized(
    p_username      VARCHAR,
    p_hashed_pw     VARCHAR, -- รับ Hash จาก App (App ใช้ CPU ของตัวเอง)
    p_profile_data  JSONB    -- รับ JSONB ที่ Validate มาแล้วจาก App
)
LANGUAGE plpgsql
AS $$
BEGIN
    -- [บรรทัดที่ 1-2] บันทึกข้อมูลลงตารางทันที ไม่เสียเวลาคำนวณ CPU
    INSERT INTO users(username, password_hash, profile_data)
    VALUES (p_username, p_hashed_pw, p_profile_data);

    -- [บรรทัดที่ 3] ยืนยัน Transaction
    COMMIT;
END $$;

แบบทดสอบวัดระดับความเข้าใจ Day 13: Decision Matrix - App vs. DB Boundaries & CPU Protection (CPU-Bound vs Data-Bound, Scale-Out vs Scale-Up, Zero-Bypass Compliance) และข้อสอบสะสมทบทวนครบทั้ง Days 1–12 คลิกเลือกคำตอบ ก, ข, ค, หรือ ง เพื่อดูผลลัพธ์และคำอธิบายอย่างละเอียดทันที

🎉 ยินดีด้วยครับ! คุณเข้าใจการกำหนดขอบเขตสถาปัตยกรรม App vs. DB อย่างลึกซึ้งแล้ว

บทเรียน Day 13: Decision Matrix - App vs. DB Boundaries & CPU Protection ได้สร้างกรอบความเข้าใจเชิงสถาปัตยกรรมในการแบ่งแยกภาระงานระหว่าง Application Layer และ Database Layer อย่างเป็นระบบ โดยกำหนดให้นำงานประเภท CPU-Bound (Hashing, Crypto, String Parsing) และ External I/O ไปไว้ที่ฝั่ง App เพื่อเปิดทางให้ Scale-Out ได้ง่าย และปกป้อง CPU ของฐานข้อมูล ให้ทำเฉพาะงาน Data-Bound และ Atomic Transactions อย่างมีประสิทธิภาพสูงสุด