Monolith System Design (2/10): Scale 1 user — kiến trúc MVP ShortLink

Phần 2/10 · Trước: Phần 1 — Nền tảng · Sau: Phần 3 — ~100 user

Mục tiêu

Xây đúng hệ thống nhỏ nhất còn chạy được — không over-engineer.

---

Kiến trúc

User → Nginx (TLS) → Monolith App → PostgreSQL
                      ↓
                   log file local

Component	Vai trò
Nginx	HTTPS, reverse proxy, có thể serve static
Monolith	REST: POST /links, GET /:slug redirect
PostgreSQL	Source of truth
Log local	Debug; chưa centralized

---

API v1

Method	Path	Mô tả
POST	/api/links	Body: target_url → trả slug
GET	/:slug	302 redirect + tăng counter (sync)
GET	/api/links	List link (auth sau)

---

Schema

CREATE TABLE short_links (
  id BIGSERIAL PRIMARY KEY,
  slug VARCHAR(12) NOT NULL UNIQUE,
  target_url TEXT NOT NULL,
  click_count BIGINT NOT NULL DEFAULT 0,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_short_links_slug ON short_links(slug);

Chọn slug: base62 random 8 ký tự — collision thấp; retry nếu trùng.

---

Sequence: redirect

Client GET /abc
  → App SELECT target_url FROM short_links WHERE slug='abc'
  → UPDATE click_count = click_count + 1
  → 302 Location: target_url

Với 1 user, 2 query/request là chấp nhận được.

---

Failure mode (chưa scale)

1. SPOF — máy chết = hết service.
2. Deploy — restart = downtime vài giây.
3. Disk đầy — log + DB cùng disk.
4. Không backup — mất data irrecoverable.
5. Brute force slug — chưa rate limit.

Ghi lại list này — mỗi phần sau xóa một vài mục.

---

Bài tập

1. Vẽ sequence POST /api/links.
2. Ước lượng dung lượng DB nếu 1 user tạo 1000 link/năm, 5 năm.
3. Liệt kê 3 lý do chưa tách microservice ở giai đoạn này.

---

Điều hướng seri: ← Phần 1 · Phần 3 →