Base.vn Prep

1. REST API Design · HTTP verbs + status codes + idempotency

Why care: Interview hay hỏi "PUT vs PATCH?" hoặc "tại sao 201 không 200?". Trả lời đúng thể hiện thinking về idempotency + semantic clarity.

HTTP Verb Cheat:

Status Code Cheat:

PUT vs PATCH — phrase nhớ:

// PUT — Replace toàn bộ. Field nào không gửi → set null/default.
PUT /users/42  { name: 'Alice', email: 'a@x.com', age: 30 }
// Server: ghi đè toàn bộ row.

// PATCH — Update các field gửi lên. Field không gửi → giữ nguyên.
PATCH /users/42  { age: 31 }
// Server: chỉ update age.

Idempotency tại tầng HTTP (khác idempotency tầng business):

• HTTP idempotent = gọi N lần cho cùng side-effect cuối cùng. GET/PUT/DELETE idempotent theo spec.
• Business idempotent = không tạo duplicate (xem BE Async #3). Cần Idempotency-Key header + log table.

⚠️ Pitfalls:

• Trả 200 cho POST create (đúng là 201) → client không biết được URI của resource mới
• Trả 401 khi đáng lý 403 → confuse client logic (401 = login lại, 403 = bị deny dù đã login)
• Trả 200 + { error: '...' } trong body → anti-pattern. Status code phải reflect kết quả.
• PUT để partial update → vi phạm spec, gây confusion

2. JWT Lifecycle · Access + Refresh + Rotation + Storage

Why 2 token? Access token short-lived (15min) → nếu leak thì attacker hết quyền nhanh. Refresh token long-lived (7-30 ngày) → renew access mà không bắt user re-login.

Flow chuẩn (4 bước):

Refresh Token Rotation — tại sao MUST:

• Mỗi lần refresh → server cấp refresh token mới + invalidate cũ
• Nếu attacker dùng refresh cũ → server detect (vì cũ đã invalidated) → revoke toàn bộ session
• Đây gọi là reuse detection, recommend bởi OWASP

Storage trade-offs:

Standard 2026: Access trong memory, Refresh trong cookie httpOnly + Secure + SameSite=Strict. Best of both worlds.

JWT structure (3 phần ngăn bằng dấu .):

// header.payload.signature
// header: { alg: 'HS256', typ: 'JWT' }
// payload: { sub: userId, role: 'admin', exp: 1715000000 }
// signature: HMAC(base64(header) + '.' + base64(payload), SECRET)

// ⚠️ Payload CHỈ base64-encoded, KHÔNG mã hoá!
// → KHÔNG bao giờ để password, PII, credit card trong JWT.

⚠️ Pitfalls:

• Để PII (CMND, phone) trong payload → ai có token cũng đọc được
• JWT không revoke được giữa chừng (stateless) → nếu cần logout-all-devices thì phải blacklist refresh trong DB/Redis
• Algorithm none bug — kiểm tra alg server-side, đừng trust header
• Đặt access expiry quá dài (1 ngày) → leak là chết. Stick với 15-30 phút.

3. Prisma N+1 Problem · Fix bằng include + DataLoader

Why care: N+1 là perf bug phổ biến nhất với ORM. Page list 100 user × mỗi user 1 query lấy posts = 101 query. Latency tăng tuyến tính → app chậm khi data scale.

❌ N+1 anti-pattern (visualization):

→ 1 query users + 100 query posts = 101 query. Latency O(n).

const users = await prisma.user.findMany();          // 1 query
for (const user of users) {
  user.posts = await prisma.post.findMany({           // N query (1 mỗi user)
    where: { authorId: user.id }
  });
}
// Total: 1 + N query. 100 user → 101 query.

✅ Fix với include (visualization):

→ 1 query duy nhất. Latency O(1).

✅ Fix 1: include (Prisma tự JOIN):

const users = await prisma.user.findMany({
  include: { posts: true }   // Prisma tự gen 1 query SQL có JOIN
});
// 1 query duy nhất. Done.

✅ Fix 2: select (chỉ field cần):

// Cẩn thận: include = lấy TẤT CẢ field của relation
// → tốn bandwidth nếu post có column lớn (content blob)
const users = await prisma.user.findMany({
  select: {
    id: true, name: true,
    posts: { select: { id: true, title: true } }  // chỉ lấy id + title
  }
});

Khi nào cần DataLoader pattern?

DataLoader = batch các call lại trong cùng 1 tick rồi gọi 1 lần. Pattern này sinh ra cho GraphQL (resolver chạy độc lập cho từng field → không biết về nhau → dễ N+1).

// GraphQL resolver — không có include sẵn
const userLoader = new DataLoader(async (userIds: number[]) => {
  // Batch: tất cả userIds dồn vào 1 query
  const users = await prisma.user.findMany({
    where: { id: { in: userIds } }
  });
  // Trả về theo đúng thứ tự input → DataLoader map lại
  return userIds.map(id => users.find(u => u.id === id));
});

// Resolver gọi loader, KHÔNG gọi DB trực tiếp
postResolver = {
  author: (post) => userLoader.load(post.authorId)
};
// 100 post.author trong 1 tick → 1 query DB.

⚠️ Pitfalls:

• Quên xét nested N+1 (user.posts.comments) → include phải nested theo
• Bật query logging Prisma (log: ['query']) → phát hiện N+1 ngay khi dev
• REST endpoint thường KHÔNG cần DataLoader — chỉ cần include/select đúng
• Include quá tham (deep nested) → query nặng, nên cap depth + dùng select

Interview phrase: "N+1 em phát hiện qua Prisma query log. Fix bằng include hoặc select. Nếu là GraphQL thì pattern DataLoader để batch resolver calls."

4. Prisma Transactions · Batch vs Interactive + Isolation

Why transaction: Nhiều DB write phải all-succeed-or-all-fail (atomicity). VD: chuyển tiền — trừ A, cộng B. Nếu cộng B fail mà A đã trừ → tiền biến mất.

Atomicity flow (success vs rollback):

2 mode của Prisma $transaction:

A. Batch (array form) — khi các op độc lập:

// Gửi 1 lượt, all-or-nothing. Không có logic giữa các op.
const [user, post] = await prisma.$transaction([
  prisma.user.create({ data: { name: 'Alice' } }),
  prisma.post.create({ data: { title: 'Hi', authorId: 1 } })
]);
// ✅ Đơn giản, nhanh
// ❌ Không dùng được nếu post.authorId cần lấy từ user vừa tạo

B. Interactive (callback) — khi có logic phụ thuộc:

await prisma.$transaction(async (tx) => {
  // tx là Prisma client trong transaction context
  const user = await tx.user.create({ data: { name: 'Alice' } });

  // Có thể dùng kết quả user.id ở đây
  await tx.post.create({
    data: { title: 'Hi', authorId: user.id }
  });

  if (someCondition) throw new Error('rollback');  // throw → rollback toàn bộ
}, {
  timeout: 10_000,         // mặc định 5s, tăng nếu cần
  isolationLevel: 'Serializable',
});

Isolation Levels (Postgres):

Trade-off: level càng cao → an toàn càng cao + conflict càng nhiều (PG có thể throw serialization failure → app phải retry).

⚠️ Pitfalls:

• Để API call (Stripe, Email) BÊN TRONG transaction → giữ DB lock quá lâu, deadlock. Rule: chỉ DB op trong tx.
• Transaction timeout mặc định 5s — query nặng phải tăng timeout + maxWait
• Không throw → Prisma không rollback. Phải throw để abort.
• Dùng client gốc (prisma.user...) thay vì tx.user... trong callback → op đó KHÔNG nằm trong transaction

Interview phrase: "Multi-table write phải atomic em dùng Interactive Transaction. Default Read Committed đủ cho hầu hết case, chỉ Serializable cho payment/critical."

5. Multi-tenancy · 3 patterns + trade-offs

Why care: Base.vn là SaaS B2B — mỗi company là 1 tenant, data phải isolate. Lựa chọn pattern ảnh hưởng tới cost, scale, isolation, ops effort.

3 Patterns (architecture visualization):

→ A: cost thấp / isolation yếu · B: trung gian · C: cost cao / isolation mạnh

A. Shared DB + Shared Schema + tenantId column:

-- Tất cả tenant cùng 1 bảng, phân biệt qua tenantId
CREATE TABLE tasks (
  id        SERIAL PRIMARY KEY,
  tenant_id INT NOT NULL,         -- ← key isolation
  title     TEXT,
  ...
);
CREATE INDEX idx_tasks_tenant ON tasks(tenant_id);

-- MỌI query phải có WHERE tenant_id = ?
SELECT * FROM tasks WHERE tenant_id = $1 AND id = $2;

• ✅ Cost thấp nhất, scale tốt nhất (1 DB cho 10000 tenant)
• ✅ Migration đơn giản (1 schema)
• ❌ Quên WHERE tenant_id → leak data giữa tenant (security thảm hoạ)
• ❌ Khó isolate noisy neighbor (1 tenant query nặng làm chậm cả app)

B. Shared DB + Schema-per-tenant (Postgres schema):

-- Mỗi tenant có schema riêng trong cùng DB
CREATE SCHEMA tenant_acme;
CREATE TABLE tenant_acme.tasks (id, title, ...);

CREATE SCHEMA tenant_globex;
CREATE TABLE tenant_globex.tasks (id, title, ...);

-- App set search_path mỗi connection
SET search_path TO tenant_acme;
SELECT * FROM tasks;  -- thực tế đọc tenant_acme.tasks

• ✅ Isolation mạnh hơn (không leak nhờ search_path)
• ✅ Backup/restore per tenant dễ hơn
• ❌ Migration cực phức tạp (1000 tenant × N schema)
• ❌ Prisma không support tốt — phải multi-client hoặc raw SQL

C. DB-per-tenant:

// App giữ map tenantId → connection string
const pool = getPoolForTenant(tenantId);
const result = await pool.query('SELECT * FROM tasks');
// Mỗi tenant 1 DB instance hoặc 1 DB logical

• ✅ Isolation cao nhất (compliance enterprise, GDPR)
• ✅ Restore/migrate per tenant rất dễ
• ❌ Cost cao (DB instance × N)
• ❌ Cross-tenant analytics khó (phải aggregate riêng)

Decision matrix:

⚠️ Pitfalls (cho Pattern A — phổ biến nhất):

• Quên WHERE tenant_id → đại hoạ security. Mitigate: Prisma middleware tự inject, hoặc Postgres Row-Level Security (RLS).
• Index thiếu tenant_id ở vị trí đầu → query tenant nhỏ phải scan toàn bảng
• JOIN sang bảng khác quên check tenant_id → leak
• UNIQUE constraint phải composite với tenant_id (vd: UNIQUE(tenant_id, email) chứ không phải UNIQUE(email))

Interview phrase: "Default em chọn shared schema + tenantId vì cost + scale. Enforce isolation qua Prisma middleware hoặc Postgres RLS. Khi có khách enterprise đòi data isolation, em mở tier riêng dùng DB-per-tenant."