Trang Tập: hôm nay là ngày gì + hướng dẫn buổi tập từng bước (data mẫu).
## 2. Build #1 — Đừng bao giờ test migration trên DB rỗng Khi tôi nâng cấp schema (thêm đa-user, rồi thêm thư viện kỹ thuật động tác), database **đã có nhiều tháng data thật của tôi**. Một migration sai = mất lịch sử tập, mất chỉ số. Đây là chỗ dễ mất data nhất. Quy tắc tôi tự đặt: **test migration trên bản copy của data prod thật, không phải DB rỗng.** Nghe hiển nhiên, nhưng cái bẫy nằm ở chỗ lấy bản copy. Data của SQLite ở chế độ WAL nằm phần lớn trong file `-wal`, không phải file chính. `cp tracker.db` đơn thuần sẽ ra một bản copy **thiếu data**. Cách đúng là [`VACUUM INTO`](https://www.sqlite.org/lang_vacuum.html) — lấy snapshot nhất quán ngay từ trong container đang chạy: ```bash # snapshot nhất quán từ container (KHÔNG cp tracker.db — data nằm trong WAL) docker exec dht-tracker node -e " const db = require('better-sqlite3')('/data/tracker.db', { readonly: true }); db.exec(\"VACUUM INTO '/data/snap.db'\"); " # rồi scp bản snap về máy, chạy migration trên ĐÓ, assert, mới deploy ``` Migration runner thì additive + idempotent + tự backup trước khi chạy (fail-closed: backup lỗi thì abort, không migrate). Rồi tôi chạy nó trên bản copy và assert từng thứ. Output thật của lần nâng lên schema mới nhất: ``` === RUN migration v6 → v7 === [migrate] pre-flight backup → tracker.db.bak-v6-1782630561118 [migrate] applied v7 ✓ user_version=7 ✓ daily_log preserved (10) ✓ workout_set preserved (19) ✓ protein preserved (8) ✓ inbody preserved (1) ✓ plan = 12 + 2 = 14 (no resurrection) ✓ exercise now 17 (14 + 3 abs) ✓ day_event table exists ✓ no duplicate token_hash ... 22/22 checks passed ``` Chỉ khi 22/22 pass + chạy lại lần 2 ra no-op (idempotent) tôi mới deploy lên prod. Deploy xong verify lại trên DB live: `user_version=7`, từng byte data còn nguyên. **0 dòng mất.** Quy tắc rút ra: "đã test rồi" mà test trên DB rỗng thì chưa test gì cả. Cái hỏng nằm ở tương tác với data thật. ## 3. Build #2 — Đa-tenant trên 1 file SQLite (khi đồng nghiệp xin xài ké) Vài người trong công ty + đối tác thấy tôi xài, xin dùng ké. Đây là *signal nhu cầu thật* — nên tôi mở thành closed pilot (invite-only, không marketing, không billing). Cám dỗ ở đây là nhảy lên Postgres + auth provider + multi-region. Tôi không. Pilot vài chục người thì SQLite single-writer dư sức. Tôi chỉ thêm `user_id` vào mọi bảng per-user + token cho mỗi người (`token_hash = sha256(token)`, không lưu plaintext). Phần khó: vài bảng cũ có PRIMARY KEY là `id` đơn, giờ cần thành composite `(user_id, id)`. SQLite **không** cho `ALTER` đổi primary key. Cách làm an toàn là **rename-trick** — đổi tên bảng cũ, để schema.sql tạo lại bảng đúng hình dạng mới, rồi bơm data cũ vào kèm `user_id`: ```js // đổi PK 'id' → '(user_id, id)' mà không mất data for (const t of toRebuild) db.exec(`ALTER TABLE ${t} RENAME TO ${t}__old`) db.exec(schemaSql) // tạo lại bảng đúng hình dạng mới (composite PK) for (const t of toRebuild) { const cols = oldCols[t].join(', ') db.exec(`INSERT INTO ${t} (user_id, ${cols}) SELECT 1, ${cols} FROM ${t}__old`) db.exec(`DROP TABLE ${t}__old`) // data cũ → của owner (user#1) } ``` Nhưng cái thật sự quyết định pass/fail không phải code chạy được — mà là **cách ly**. Một health app mà user B đọc được chỉ số của user A là thảm hoạ. Nên isolation test là *điều kiện chặn deploy*, không phải "nice to have": ``` ✓ user1 09:30 → thấy sự kiện của chính mình ✓ ISOLATION user2 KHÔNG thấy event của user1 ✓ ISOLATION user2 KHÔNG xoá được event của user1 (0 changes) ✓ owner mới xoá được event của mình ``` Mọi mutation theo `id` đều kèm `AND user_id = ?`. Query không có `user_id` = bug. Đơn giản, nhưng đây là dòng phân cách giữa "app cá nhân" và "app nhiều người dùng được". ```mermaid flowchart LR A[Bearer token] -->|sha256| B[lookup user] B -->|set userId| C[mọi query + WHERE user_id=?] C --> D[(1 file SQLite)] E[isolation test] -. pass/fail gate .-> F[deploy] ``` ## 4. Build #3 — Coach AI không được phép bịa Tôi nhúng một LLM coach: mỗi sáng nó đọc số liệu của tôi rồi nhắn 2-3 câu qua Telegram. Chạy bằng `claude -p` ngay trên VPS. Vấn đề: **một coach sức khoẻ mà bịa số liệu thì nguy hiểm.** "Đạm anh hôm nay 180g rồi, đủ" trong khi thật ra mới 40g — đó là tệ hơn im lặng. Ba lớp guardrail: - Grounded — chỉ được dùng số *có trong context*, cấm bịa. - Fence — bọc data người dùng trong `Kết quả encode vào app: mỗi bài có cue knee-safe + video form chuẩn + ô nhập reps/kg/RIR để tự tăng tải dần (data mẫu).
## Thành thật: app mới 2 ngày tuổi Tôi không viết bài này để khoe một hệ thống hoàn hảo. App mới chạy **2 ngày** — chưa tròn tuần nên chưa ai bị "phạt" stake lần nào :D Habit khó nhất với tôi lúc này là **cắt bia** — vì còn đi tiếp khách. Thiền, English, chơi đàn cũng chưa đều. Tôi sẽ cố thêm. Tôi để mấy thứ này lộ ra vì một bài "build hệ thống quản sức khoẻ" mà không thừa nhận chính tác giả còn đang vật lộn thì là quảng cáo, không phải kinh nghiệm. Và tôi không sống theo lịch cứng. Tôi kiểu **freestyle — rảnh là làm, không trì hoãn**. Hệ thống này không phải để biến tôi thành robot kỷ luật giờ giấc; nó để cái "rảnh là làm" đó khỏi rơi vào quên lãng giữa một ngày 200 quyết định. Lịch trong app là *gợi ý*, không phải nhà tù — tập lệch ngày vẫn được, miễn cả tuần đủ.Lịch tuần là gợi ý (3 tạ + 2 yoga + 1 bơi + 1 nghỉ), chèn được sự kiện ad-hoc — không phải nhà tù giờ giấc (data mẫu).
## Kết — sức khoẻ là một sản phẩm có roadmap Cái app này đang ở v5. Có version, có migration, có backlog, có "coach" — y như một sản phẩm nội bộ. Vì với tôi nó *là* một sản phẩm nội bộ, và "khách hàng" là cái cơ thể + cái đầu phải vận hành 3 công ty trong 10 năm tới. Bốn quyết định trên không phải để khoe kỹ thuật. Chúng trả lời đúng một câu hỏi: *làm sao để một hệ thống quản sức khoẻ trở nên đáng tin?* — đừng làm mất data của chính mình, đừng để lộ data người khác, đừng để AI bịa, và đừng code theo cảm tính. Founder nào cũng instrument doanh thu, pipeline, burn rate. Rất ít người instrument cái chạy tất cả những thứ đó. Tôi nghĩ đó là cái sai thứ tự ưu tiên lớn nhất của nghề này. ## FAQ ### CEO bận thì lấy đâu thời gian quản sức khoẻ? Không quản bằng thời gian, quản bằng hệ thống. Ý chí là tài nguyên cạn; cron nhắc + habit score + stake tiền thì không cạn. Tôi không track 'có khoẻ không' (mơ hồ) — tôi track habit thực thi (input) + chỉ số thân thể (output). ### Sao không xài app có sẵn như MyFitnessPal / Cronometer? App có sẵn track 1 mảng (calo) tốt nhưng không hiểu context riêng, không own data, không gộp được 5 mảng (thể chất, vận động, kỹ năng, ngôn ngữ, thiền) + 1 coach AI dí mình mỗi sáng. Tôi muốn 1 hệ thống của mình, không phải thuê. ### Tự build có phải over-engineering không? Stack cố tình nhỏ: 1 file SQLite, 1 container, deploy 1 lệnh. Không Postgres, không Kubernetes, không microservice. Over-engineering là khi anh thêm thứ không cần — ở đây mỗi quyết định trace về 1 rủi ro thật (mất data, leak data, AI bịa, advice sai). ### LLM coach tư vấn sức khoẻ có nguy hiểm không? Có nếu để nó bịa. Nên nó KHÔNG phải bác sĩ, không chẩn đoán, chỉ được dùng số có sẵn trong context, tôn trọng ràng buộc an toàn khớp gối, và có rule-based fallback khi parse fail. Guardrail là thiết kế, không phải lời hứa. ### Multi-tenant trên SQLite có đủ không? Cho closed pilot vài chục người thì dư. SQLite single-writer + WAL xử lý thừa tải này. Khi nào có signal thật cần scale (nghìn user, multi-region) mới tính Postgres — không bring-forward complexity vì 'sau này có thể'. --- Source: https://danghongtien.com/posts/2026-06-28-ceo-suc-khoe-la-infra-build-tracker/ Markdown export of canonical HTML article. License: CC BY 4.0 with attribution.