@xdev-asia/xdev-knowledge-mcp 1.0.38 → 1.0.40

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/01-bai-9-postgresql-security-hardening.md

@@ -26,30 +26,17 @@ PostgreSQL là lựa chọn phổ biến cho hệ thống y tế nhờ tính lin
 
 ### 1.1. Các lớp bảo mật PostgreSQL
 
-```
-┌─────────────────────────────────────────────────────┐
-│                  Application Layer                   │
-│    Quarkus / Spring Boot + Connection Pool           │
-├─────────────────────────────────────────────────────┤
-│                  Network Layer                       │
-│    Firewall Rules + VPN/Private Network              │
-├─────────────────────────────────────────────────────┤
-│              Authentication Layer                    │
-│    pg_hba.conf + SSL/TLS + Client Certificates       │
-├─────────────────────────────────────────────────────┤
-│              Authorization Layer                     │
-│    Roles + Privileges + Row-Level Security           │
-├─────────────────────────────────────────────────────┤
-│                Encryption Layer                      │
-│    TDE + Column Encryption + Backup Encryption       │
-├─────────────────────────────────────────────────────┤
-│                  Audit Layer                         │
-│    pgAudit + Custom Triggers + Log Shipping          │
-├─────────────────────────────────────────────────────┤
-│              Operating System Layer                  │
-│    File Permissions + SELinux/AppArmor               │
-└─────────────────────────────────────────────────────┘
-```
+![7 lớp bảo mật PostgreSQL — từ Application đến OS Layer](/storage/uploads/2026/04/healthcare-postgresql-security-layers.png)
+
+| Layer | Tên | Thành phần |
+|-------|-----|------------|
+| 7 | Application | Quarkus / Spring Boot + Connection Pool |
+| 6 | Network | Firewall Rules + VPN/Private Network |
+| 5 | Authentication | pg_hba.conf + SSL/TLS + Client Certificates |
+| 4 | Authorization | Roles + Privileges + Row-Level Security |
+| 3 | Encryption | TDE + Column Encryption + Backup Encryption |
+| 2 | Audit | pgAudit + Custom Triggers + Log Shipping |
+| 1 | Operating System | File Permissions + SELinux/AppArmor |
 
 ### 1.2. Checklist bảo mật cần hoàn thành
 
@@ -145,7 +132,8 @@ hostssl all             all               0.0.0.0/0            reject
 sudo -u postgres psql
 ```
 
-**Rule 4 - `hostssl` + `scram-sha-256`**: 
+**Rule 4 - `hostssl` + `scram-sha-256`**:
+
 - `hostssl` = bắt buộc SSL/TLS
 - `scram-sha-256` = password hashing mạnh nhất PostgreSQL hỗ trợ
 
@@ -273,28 +261,13 @@ WHERE usename IS NOT NULL;
 
 ### 4.1. Nguyên tắc Least Privilege cho Healthcare
 
-```
-┌──────────────────────────────────────────────────────┐
-│              PostgreSQL Role Hierarchy                │
-│                                                      │
-│  postgres (superuser) ← CHỈ dùng cho maintenance    │
-│      │                                               │
-│      ├── dba_admin (CREATEDB, CREATEROLE)            │
-│      │       └── Quản lý schema, backup, monitoring  │
-│      │                                               │
-│      ├── app_roles (LOGIN, limited privileges)       │
-│      │       ├── app_patient_svc                     │
-│      │       ├── app_lab_svc                         │
-│      │       ├── app_pharmacy_svc                    │
-│      │       └── app_gateway_svc                     │
-│      │                                               │
-│      ├── readonly_role (SELECT only)                 │
-│      │       ├── readonly_analytics                  │
-│      │       └── readonly_reporting                  │
-│      │                                               │
-│      └── monitoring_user (pg_monitor)                │
-└──────────────────────────────────────────────────────┘
-```
+![PostgreSQL Role Hierarchy cho hệ thống y tế](/storage/uploads/2026/04/healthcare-postgresql-role-hierarchy.png)
+
+- **postgres** (superuser) ← CHỈ dùng cho maintenance
+  - **dba_admin** (CREATEDB, CREATEROLE) — Quản lý schema, backup, monitoring
+  - **app_roles** (LOGIN, limited privileges) — app_patient_svc, app_lab_svc, app_pharmacy_svc, app_gateway_svc
+  - **readonly_role** (SELECT only) — readonly_analytics, readonly_reporting
+  - **monitoring_user** (pg_monitor)
 
 ### 4.2. Tạo Role Hierarchy
 
@@ -570,33 +543,13 @@ WHERE rolcanlogin = true
 ### 6.1. Tại sao cần PgBouncer
 
 Trong hệ thống microservices, mỗi service instance tạo connection pool riêng. PgBouncer giúp:
+
 - Giảm tổng số connections tới PostgreSQL
 - Thêm một lớp authentication
 - Rate limiting
 - Connection routing
 
-```
-┌─────────────────────────────────────────────────────┐
-│  Microservices (mỗi cái 20 connections)             │
-│  ┌──────────┐ ┌──────────┐ ┌──────────┐            │
-│  │ Patient  │ │ Lab      │ │ Pharmacy │            │
-│  │ Service  │ │ Service  │ │ Service  │            │
-│  │ x3 pods  │ │ x2 pods  │ │ x2 pods  │            │
-│  └────┬─────┘ └────┬─────┘ └────┬─────┘            │
-│       │ 60 conn     │ 40 conn    │ 40 conn          │
-│       └─────────────┼────────────┘                  │
-│                     │ 140 total                     │
-│              ┌──────┴───────┐                       │
-│              │  PgBouncer   │                       │
-│              │  Pool: 50    │ ← Giảm từ 140 → 50   │
-│              └──────┬───────┘                       │
-│                     │ 50 conn                       │
-│              ┌──────┴───────┐                       │
-│              │  PostgreSQL  │                       │
-│              │  max: 200    │                       │
-│              └──────────────┘                       │
-└─────────────────────────────────────────────────────┘
-```
+![PgBouncer connection pooling — giảm 140 connections xuống 50](/storage/uploads/2026/04/healthcare-pgbouncer-connection-pooling.png)
 
 ### 6.2. PgBouncer Configuration
 
@@ -1011,6 +964,7 @@ Trong bài học này, chúng ta đã triển khai **PostgreSQL Security Hardeni
 8. **OS-Level** - File permissions và systemd hardening
 
 Các nguyên tắc cốt lõi:
+
 - **Defense in Depth**: Nhiều lớp bảo mật chồng chéo
 - **Least Privilege**: Mỗi role chỉ có quyền tối thiểu cần thiết
 - **Encrypt Everything**: SSL/TLS cho mọi connection

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/02-bai-10-ma-hoa-du-lieu-postgresql.md

@@ -23,37 +23,18 @@ course:
 
 ![4 lớp mã hóa dữ liệu y tế: Disk, TDE, Column, Application](/storage/uploads/2026/04/healthcare-encryption-layers.png)
 
-
 Dữ liệu y tế (PHI) yêu cầu mã hóa ở **hai trạng thái**: at-rest (khi lưu trữ) và in-transit (khi truyền). HIPAA Security Rule §164.312(a)(2)(iv) và §164.312(e)(2)(ii) quy định cụ thể về encryption requirements.
 
 ### 1.1. Encryption Layers
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                    Data Lifecycle                        │
-│                                                         │
-│  Application ──── In-Transit ────► Database              │
-│                   (TLS 1.3)                              │
-│                                                         │
-│  ┌─────────────────────────────────────────────────┐    │
-│  │              At-Rest Encryption                  │    │
-│  │                                                  │    │
-│  │  Level 1: Full Disk Encryption (LUKS/dm-crypt)  │    │
-│  │     └── Bảo vệ khi disk bị đánh cắp            │    │
-│  │                                                  │    │
-│  │  Level 2: Transparent Data Encryption (TDE)     │    │
-│  │     └── Encrypt data files, WAL, temp files     │    │
-│  │                                                  │    │
-│  │  Level 3: Column-Level Encryption (pgcrypto)    │    │
-│  │     └── Encrypt từng field PHI riêng biệt       │    │
-│  │                                                  │    │
-│  │  Level 4: Application-Level Encryption          │    │
-│  │     └── Encrypt trước khi gửi tới database      │    │
-│  └─────────────────────────────────────────────────┘    │
-│                                                         │
-│  Backup ──── Encrypted Backup ────► S3 (SSE-KMS)       │
-└─────────────────────────────────────────────────────────┘
-```
+![Các lớp mã hóa dữ liệu y tế — In-Transit, At-Rest (4 levels), Backup](/storage/uploads/2026/04/healthcare-encryption-layers.png)
+
+- **In-Transit**: TLS 1.3 giữa Application và Database
+- **At-Rest Level 1**: Full Disk Encryption (LUKS/dm-crypt) — bảo vệ khi disk bị đánh cắp
+- **At-Rest Level 2**: Transparent Data Encryption (TDE) — encrypt data files, WAL, temp files
+- **At-Rest Level 3**: Column-Level Encryption (pgcrypto) — encrypt từng field PHI riêng biệt
+- **At-Rest Level 4**: Application-Level Encryption — encrypt trước khi gửi tới database
+- **Backup**: Encrypted Backup → S3 (SSE-KMS)
 
 ### 1.2. So sánh các phương pháp mã hóa
 
@@ -490,35 +471,15 @@ public class SslVerificationService {
 
 ### 5.1. Vault Transit Secrets Engine
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              Envelope Encryption Pattern                 │
-│                                                         │
-│  ┌──────────┐      ┌──────────┐      ┌──────────┐     │
-│  │ Quarkus  │      │  Vault   │      │ HSM/KMS  │     │
-│  │ App      │      │ Transit  │      │          │     │
-│  └────┬─────┘      └────┬─────┘      └────┬─────┘     │
-│       │                  │                  │           │
-│  1. Generate DEK         │                  │           │
-│  (Data Encryption Key)   │                  │           │
-│       │                  │                  │           │
-│  2. Encrypt data         │                  │           │
-│     with DEK             │                  │           │
-│       │                  │                  │           │
-│  3. ─── Encrypt DEK ──►│                  │           │
-│       │                  │ 4. Wrap DEK     │           │
-│       │                  │    with KEK ────►│           │
-│       │  ◄── Wrapped ───│                  │           │
-│       │      DEK         │                  │           │
-│       │                  │                  │           │
-│  5. Store encrypted      │                  │           │
-│     data + wrapped DEK   │                  │           │
-│     in PostgreSQL        │                  │           │
-│                                                         │
-│  DEK = Data Encryption Key (per-record hoặc per-table) │
-│  KEK = Key Encryption Key (master key trong Vault)     │
-└─────────────────────────────────────────────────────────┘
-```
+![Envelope Encryption Pattern với Vault Transit — DEK + KEK](/storage/uploads/2026/04/healthcare-vault-envelope-encryption.png)
+
+**Quy trình Envelope Encryption:**
+
+1. Generate DEK (Data Encryption Key) — per-record hoặc per-table
+2. Encrypt data with DEK
+3. Gửi DEK tới Vault Transit để wrap
+4. Vault wrap DEK với KEK (Key Encryption Key) qua HSM/KMS
+5. Lưu encrypted data + wrapped DEK trong PostgreSQL
 
 ### 5.2. Vault Configuration
 
@@ -895,30 +856,13 @@ echo "Restore completed from: ${BACKUP_FILE}"
 
 ### 8.1. Quy trình Key Rotation
 
-```
-┌─────────────────────────────────────────────────────┐
-│              Key Rotation Timeline                   │
-│                                                      │
-│  Day 0          Day 90         Day 180               │
-│  ├──────────────┼──────────────┤                     │
-│  │   Key v1     │   Key v2     │   Key v3            │
-│  │  (active)    │  (active)    │  (active)           │
-│  │              │              │                     │
-│  │  Encrypt     │  RE-encrypt  │  RE-encrypt         │
-│  │  new data    │  old data    │  old data           │
-│  │  with v1     │  with v2     │  with v3            │
-│  │              │              │                     │
-│  │              │  v1 still    │  v1 retired         │
-│  │              │  can decrypt │  v2 can decrypt     │
-│  └──────────────┴──────────────┴─────────────────────│
-│                                                      │
-│  Vault tự động:                                      │
-│  - Rotate KEK mỗi 90 ngày                           │
-│  - OLD versions vẫn decrypt được                     │
-│  - NEW data encrypt bằng latest version              │
-│  - Rewrap: re-encrypt DEK với new KEK version        │
-└─────────────────────────────────────────────────────┘
-```
+![Key Rotation Timeline — v1 → v2 → v3 mỗi 90 ngày với Vault auto-rotation](/storage/uploads/2026/04/healthcare-key-rotation-timeline.png)
+
+- **Day 0–90**: Key v1 active — encrypt new data
+- **Day 90–180**: Key v2 active — re-encrypt old data, v1 vẫn decrypt được
+- **Day 180+**: Key v3 active — v1 retired, v2 vẫn decrypt được
+- Vault tự động rotate KEK, OLD versions vẫn decrypt, NEW data encrypt bằng latest
+- **Rewrap**: re-encrypt DEK với new KEK version
 
 ### 8.2. Batch Re-encryption Script
 
@@ -1004,6 +948,7 @@ Trong bài học này, chúng ta đã triển khai **mã hóa toàn diện** cho
 9. **Key Rotation**: Automated DEK rewrapping khi KEK rotate
 
 Nguyên tắc quan trọng:
+
 - **Never store encryption keys cùng với encrypted data**
 - **Always use authenticated encryption** (AES-GCM)
 - **Implement key rotation** với zero-downtime

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/03-bai-11-row-level-security-column-encryption.md

@@ -23,7 +23,6 @@ course:
 
 ![Row-Level Security Pipeline — JWT Claims → SET LOCAL → RLS Policy](/storage/uploads/2026/04/healthcare-rls-request-flow.png)
 
-
 Row-Level Security (RLS) cho phép PostgreSQL kiểm soát **hàng nào** trong bảng mà user có thể nhìn thấy hoặc thao tác. Đây là tính năng critical cho healthcare vì:
 
 - **Bác sĩ A** chỉ thấy bệnh nhân của mình
@@ -33,63 +32,35 @@ Row-Level Security (RLS) cho phép PostgreSQL kiểm soát **hàng nào** trong
 
 ### 1.1. RLS vs Application-Level Filtering
 
-```
-┌─────────────────────────────────────────────────────────┐
-│         Application-Level Filtering (KHÔNG AN TOÀN)      │
-│                                                          │
-│  SELECT * FROM patients WHERE doctor_id = :currentDoctor │
-│                                                          │
-│  Vấn đề:                                                │
-│  - Developer quên WHERE clause → data leak               │
-│  - SQL injection bypass WHERE clause                     │
-│  - Direct DB access bypass application logic             │
-│  - Reporting tools bypass application                    │
-└─────────────────────────────────────────────────────────┘
-
-┌─────────────────────────────────────────────────────────┐
-│         Row-Level Security (AN TOÀN)                     │
-│                                                          │
-│  SELECT * FROM patients;  ← Trả về CHỈ rows allowed    │
-│                                                          │
-│  Ưu điểm:                                               │
-│  - Database enforce, không bypass được                   │
-│  - Transparent cho application                           │
-│  - Works với mọi tool (psql, reporting, BI)             │
-│  - Defense in depth layer                               │
-└─────────────────────────────────────────────────────────┘
-```
+![So sánh Application-Level Filtering vs Row-Level Security trong PostgreSQL](/storage/uploads/2026/04/healthcare-rls-vs-app-filtering.png)
+
+**Application-Level Filtering (KHÔNG AN TOÀN):**
+
+- `SELECT * FROM patients WHERE doctor_id = :currentDoctor`
+- Developer quên WHERE clause → data leak
+- SQL injection bypass WHERE clause
+- Direct DB access bypass application logic
+- Reporting tools bypass application
+
+**Row-Level Security (AN TOÀN):**
+
+- `SELECT * FROM patients;` — Trả về CHỈ rows allowed
+- Database enforce, không bypass được
+- Transparent cho application
+- Works với mọi tool (psql, reporting, BI)
+- Defense in depth layer
 
 ### 1.2. RLS Architecture cho Healthcare
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                  Request Flow                            │
-│                                                          │
-│  Quarkus App                                             │
-│      │                                                   │
-│      │ 1. Extract JWT claims                             │
-│      │    (user_id, role, department, hospital_id)       │
-│      │                                                   │
-│      │ 2. SET LOCAL session variables                    │
-│      │    SET LOCAL app.current_user_id = 'uuid';       │
-│      │    SET LOCAL app.current_role = 'doctor';        │
-│      │    SET LOCAL app.current_dept = 'cardiology';    │
-│      │    SET LOCAL app.hospital_id = 'uuid';           │
-│      │                                                   │
-│      │ 3. Execute query                                  │
-│      │    SELECT * FROM patients;                        │
-│      ▼                                                   │
-│  PostgreSQL                                              │
-│      │                                                   │
-│      │ 4. RLS Policy evaluates                           │
-│      │    current_setting('app.current_role')            │
-│      │    current_setting('app.current_dept')            │
-│      │                                                   │
-│      │ 5. Return ONLY allowed rows                       │
-│      ▼                                                   │
-│  Results (filtered by RLS)                               │
-└─────────────────────────────────────────────────────────┘
-```
+![RLS Request Flow — JWT → Session Variables → Policy Evaluation → Filtered Results](/storage/uploads/2026/04/healthcare-rls-request-flow.png)
+
+**Request Flow:**
+
+1. **Quarkus App** — Extract JWT claims (user_id, role, department, hospital_id)
+2. **SET LOCAL** session variables (`app.current_user_id`, `app.current_role`, `app.current_dept`, `app.hospital_id`)
+3. **Execute query** — `SELECT * FROM patients;`
+4. **PostgreSQL RLS Policy** evaluates `current_setting('app.current_role')`, `current_setting('app.current_dept')`
+5. **Return ONLY allowed rows** — Results filtered by RLS
 
 ## 2. Thiết lập RLS cơ bản
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/03-phan-3-data-layer-postgresql/lessons/04-bai-12-audit-logging-cdc-pgaudit.md

@@ -23,61 +23,43 @@ course:
 
 ![Kiến trúc Audit Logging — pgAudit, Debezium CDC, Fluent Bit, ELK](/storage/uploads/2026/04/healthcare-audit-logging-stack.png)
 
-
 HIPAA Security Rule §164.312(b) yêu cầu **hardware, software, and/or procedural mechanisms that record and examine activity** trong hệ thống chứa ePHI. Audit logging không chỉ là compliance requirement mà còn là công cụ **phát hiện intrusion, forensics, và accountability**.
 
 ### 1.1. Audit Requirements cho Y Tế
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              Healthcare Audit Requirements               │
-│                                                          │
-│  WHO?     ──► User identity (Keycloak subject)          │
-│  WHAT?    ──► Action performed (SELECT, INSERT, UPDATE)  │
-│  WHEN?    ──► Timestamp (with timezone)                  │
-│  WHERE?   ──► Source IP, application, service            │
-│  WHICH?   ──► Object accessed (table, column, row)       │
-│  HOW?     ──► Query text, parameters                     │
-│  RESULT?  ──► Success/failure, rows affected             │
-│                                                          │
-│  Additional Healthcare Requirements:                     │
-│  - PHI access tracking                                   │
-│  - Break-the-glass audit                                 │
-│  - Before/After values cho data changes                  │
-│  - Immutable audit trail (no tampering)                  │
-│  - 6-year retention (HIPAA minimum)                      │
-└─────────────────────────────────────────────────────────┘
-```
+| Yêu cầu | Mô tả |
+|---------|--------|
+| **WHO?** | User identity (Keycloak subject) |
+| **WHAT?** | Action performed (SELECT, INSERT, UPDATE) |
+| **WHEN?** | Timestamp (with timezone) |
+| **WHERE?** | Source IP, application, service |
+| **WHICH?** | Object accessed (table, column, row) |
+| **HOW?** | Query text, parameters |
+| **RESULT?** | Success/failure, rows affected |
+
+**Yêu cầu bổ sung cho Healthcare:**
+
+- PHI access tracking
+- Break-the-glass audit
+- Before/After values cho data changes
+- Immutable audit trail (no tampering)
+- 6-year retention (HIPAA minimum)
 
 ### 1.2. Audit Architecture
 
-```
-┌─────────────────────────────────────────────────────────┐
-│                      Audit Stack                         │
-│                                                          │
-│  ┌──────────┐     ┌──────────┐     ┌──────────┐        │
-│  │ Quarkus  │     │PostgreSQL│     │ Debezium │        │
-│  │ App Logs │     │ pgAudit  │     │ CDC      │        │
-│  └────┬─────┘     └────┬─────┘     └────┬─────┘        │
-│       │                │                 │               │
-│       │ JSON logs      │ CSV/syslog     │ Kafka events  │
-│       │                │                 │               │
-│       └────────────────┼─────────────────┘               │
-│                        │                                 │
-│                   ┌────▼─────┐                           │
-│                   │ Fluent   │                           │
-│                   │ Bit      │                           │
-│                   └────┬─────┘                           │
-│                        │                                 │
-│              ┌─────────┼─────────┐                       │
-│              │         │         │                       │
-│         ┌────▼───┐ ┌───▼────┐ ┌──▼──────┐              │
-│         │OpenSear│ │ S3     │ │PostgreSQ│              │
-│         │ch/ELK  │ │Archive │ │L Audit  │              │
-│         │(Query) │ │(7 yrs) │ │DB       │              │
-│         └────────┘ └────────┘ └─────────┘              │
-└─────────────────────────────────────────────────────────┘
-```
+![Audit Stack — Quarkus + pgAudit + Debezium CDC → FluentBit → OpenSearch/S3/PostgreSQL](/storage/uploads/2026/04/healthcare-audit-architecture.png)
+
+**Audit Sources:**
+
+- **Quarkus App Logs** → JSON logs
+- **PostgreSQL pgAudit** → CSV/syslog
+- **Debezium CDC** → Kafka events
+
+**Pipeline:** Tất cả → **FluentBit** → phân phối tới:
+
+- **OpenSearch/ELK** — Query & visualization
+- **S3 Archive** — Lưu trữ 7 năm
+- **PostgreSQL Audit DB** — Structured query
 
 ## 2. pgAudit - Installation & Configuration
 
@@ -179,6 +161,7 @@ SELECT * FROM patient_schema.patients;
 ```
 
 Audit log output (CSV format):
+
 ```
 2025-01-15 10:30:45.123 ICT [12345] user=app_patient_svc,db=healthcare_db,app=patient-service,client=10.0.1.10
 AUDIT: SESSION,1,1,WRITE,INSERT,,patient_schema.patients,
@@ -240,6 +223,7 @@ ORDER BY relname;
 ## 4. Custom Audit Trigger Functions
 
 pgAudit ghi lại **SQL statements**, nhưng không capture:
+
 - **Before/After values** (old vs new data)
 - **Application-level context** (JWT user, IP)
 - **Business-level events** (who viewed which patient record)
@@ -524,38 +508,20 @@ $$ LANGUAGE plpgsql SECURITY DEFINER;
 
 ### 5.1. CDC Architecture
 
-```
-┌─────────────────────────────────────────────────────────┐
-│              CDC với Debezium + Kafka                    │
-│                                                          │
-│  PostgreSQL                                              │
-│  ┌──────────┐                                            │
-│  │ WAL      │ ← Write-Ahead Log (logical replication)   │
-│  │ (changes)│                                            │
-│  └────┬─────┘                                            │
-│       │ Logical Decoding                                 │
-│       ▼                                                  │
-│  ┌──────────┐                                            │
-│  │ Debezium │ ← Kafka Connect Source Connector           │
-│  │Connector │                                            │
-│  └────┬─────┘                                            │
-│       │ JSON change events                               │
-│       ▼                                                  │
-│  ┌──────────────────────────────────────────┐            │
-│  │              Apache Kafka                 │            │
-│  │  Topics:                                  │            │
-│  │  ├── healthcare.patient_schema.patients   │            │
-│  │  ├── healthcare.patient_schema.records    │            │
-│  │  └── healthcare.audit_schema.changes      │            │
-│  └────┬─────────────┬───────────┬───────────┘            │
-│       │             │           │                        │
-│  ┌────▼───┐   ┌─────▼──┐  ┌────▼────┐                  │
-│  │OpenSear│   │ Audit  │  │ Alert   │                  │
-│  │ch Sink │   │ S3     │  │ Engine  │                  │
-│  │Connect │   │Archive │  │(KSQL)   │                  │
-│  └────────┘   └────────┘  └─────────┘                  │
-└─────────────────────────────────────────────────────────┘
-```
+![CDC Pipeline — PostgreSQL WAL → Debezium → Kafka → OpenSearch/S3/KSQL](/storage/uploads/2026/04/healthcare-cdc-pipeline.png)
+
+**CDC Flow:**
+
+1. **PostgreSQL WAL** — Write-Ahead Log (logical replication)
+2. **Logical Decoding** → **Debezium Connector** (Kafka Connect Source)
+3. **JSON change events** → **Apache Kafka** Topics:
+   - `healthcare.patient_schema.patients`
+   - `healthcare.patient_schema.records`
+   - `healthcare.audit_schema.changes`
+4. **Consumers:**
+   - **OpenSearch Sink Connect** — Full-text search
+   - **Audit S3 Archive** — Long-term retention
+   - **Alert Engine (KSQL)** — Real-time anomaly detection
 
 ### 5.2. PostgreSQL Configuration cho CDC
 
@@ -1200,13 +1166,11 @@ Trong bài học này, chúng ta đã xây dựng **hệ thống Audit Logging t
 9. **Monitoring**: Prometheus alerting cho replication lag, trigger health, access anomalies
 
 Architecture tổng thể:
-```
-App Audit (Quarkus)  ──► Kafka  ──► OpenSearch (real-time query)
-                              └──► S3 (archive 7+ years)
-DB Audit (pgAudit)   ──► CSV   ──► Fluent Bit ──► OpenSearch
-Custom Triggers      ──► audit_schema tables ──► Compliance Reports
-CDC (Debezium)       ──► Kafka  ──► KSQL (anomaly detection)
-```
+
+- **App Audit (Quarkus)** → Kafka → OpenSearch (real-time query) + S3 (archive 7+ years)
+- **DB Audit (pgAudit)** → CSV → Fluent Bit → OpenSearch
+- **Custom Triggers** → `audit_schema` tables → Compliance Reports
+- **CDC (Debezium)** → Kafka → KSQL (anomaly detection)
 
 ## Bài tập