Framework RADIO - Cách tiếp cận có hệ thống cho Front-end System Design

Mình mới đọc được một bài viết khá hay trên Linkedin về RADIO framework - được thiết kế riêng để trả lời các câu hỏi thiết kế hệ thống front-end (front-end system design) một cách có cấu trúc. Thú thực là trước đây mình hay bị lạc đề khi gặp những câu hỏi mở kiểu "Thiết kế Facebook" hay "Thiết kế YouTube", nhưng với framework này thì mọi thứ rõ ràng hơn nhiều.

RADIO Framework là gì?

RADIO là viết tắt của năm bước chính trong thiết kế hệ thống front-end:

• Requirements - Yêu cầu
• Architecture - Kiến trúc
• Data Model - Mô hình dữ liệu
• Interface - Giao diện (API)
• Optimizations - Tối ưu hóa

Ý tưởng chính của front-end system design framework này là: khi bạn có một cấu trúc tốt, bạn đã thắng một nửa trận đánh system design interview rồi.

1. Requirements Exploration - Hiểu rõ đề bài System Design

Thời gian khuyến nghị: Không quá 15% buổi phỏng vấn

Đây là bước quan trọng nhất trong front-end system design nhưng nhiều người hay bỏ qua. Các câu hỏi system design thường mơ hồ và thiếu thông tin nhất định. Bạn phải chủ động đặt câu hỏi để làm rõ requirements.

Đừng ngại hỏi trong System Design Interview

Hãy tưởng tượng interviewer bảo bạn "Thiết kế Facebook". Facebook thì có news feed, profile, bạn bè, nhóm, stories... Cái nào là trọng tâm của system design này? Nếu bạn không hỏi mà cứ lao vào thiết kế luồng kết bạn, có thể interviewer đang muốn bạn tập trung vào news feed thì bạn mất điểm ngay.

Một số câu hỏi nên đặt trong front-end system design:

Use case chính là gì?

Với Facebook thì là news feed, phân trang feed, và đăng bài mới. Với YouTube thì là trải nghiệm xem video. Đây là functional requirements quan trọng nhất.

Functional vs Non-functional requirements?

• Functional requirements: Những tính năng cơ bản không thể thiếu - user có thể hoàn thành các luồng chính đúng cách không.
• Non-functional requirements: Performance, scalability, UX tốt hơn - không bắt buộc nhưng làm sản phẩm tốt hơn.

Tính năng nào là core, nào là nice-to-have?

Ví dụ đăng bài thì có text, photo, video, poll, check-in... cái nào là bắt buộc trong system design này?

Một số câu hỏi khác cần hỏi trong front-end system design:

• Hỗ trợ nền tảng nào? Desktop/mobile/tablet?
• Cần offline support không?
• User chính là ai?
• Performance requirements?

Mẹo nhỏ cho System Design

Hãy ghi lại các yêu cầu đã thống nhất để có thể tham chiếu suốt bài thi và đảm bảo bạn đã cover hết requirements.

2. Architecture / High-level Design - Thiết kế kiến trúc Front-end

Thời gian khuyến nghị: Khoảng 20% buổi phỏng vấn

Khi đã hiểu rõ requirements, hãy vẽ sơ đồ kiến trúc. Mỗi component là một hình chữ nhật, mũi tên thể hiện luồng dữ liệu.

Các component thường gặp trong Front-end Architecture

• Server: coi như black box, assume có API để gọi qua HTTP/WebSockets
• View: những gì user thấy, có thể chứa subview nhỏ hơn
• Controller: xử lý tương tác user và chuẩn bị dữ liệu cho view (không phải lúc nào cũng cần)
• Model/Client store: nơi lưu dữ liệu, thường là app-wide

Ví dụ với News Feed Architecture

┌─────────────────────────────────────┐
│           Feed UI                   │
│  ┌────────────┐  ┌──────────────┐   │
│  │Feed Post   │  │Post Composer │   │
│  └────────────┘  └──────────────┘   │
└─────────────────────────────────────┘
                ↕
┌─────────────────────────────────────┐
│          Controller                 │
└─────────────────────────────────────┘
                ↕
┌─────────────────────────────────────┐
│         Client Store                │
└─────────────────────────────────────┘
                ↕
┌─────────────────────────────────────┐
│            Server                   │
└─────────────────────────────────────┘

Component responsibilities trong Front-end Architecture:

• Server: Cung cấp feed data qua HTTP API, cho phép tạo bài mới
• Controller: Điều phối luồng dữ liệu, gọi API
• Client Store: Lưu data dùng chung toàn app
• Feed UI: Chứa list posts và UI đăng bài
  • Feed Post: Hiển thị data một post, nút like/react/share/comment
  • Post Composer: UI để user tạo bài mới

Một số điểm cần lưu ý trong Front-end System Design

• Separation of concerns: Mỗi component có mục đích rõ ràng
• Nơi xử lý computation: Nên xử lý trên server hay client? Tùy context và sản phẩm

3. Data Model - Mô hình dữ liệu cho Front-end

Thời gian khuyến nghị: Khoảng 10% buổi phỏng vấn

Bây giờ hãy nghĩ xem có những trường dữ liệu nào trên client. Có hai loại chính:

Server-originated data

Dữ liệu từ server, thường lưu trong database và nhiều người xem hoặc truy cập từ nhiều devices.

Ví dụ: user data (name, profile picture), user-generated data (feed posts, comments).

Client-only data

Dữ liệu chỉ sống trên client, không cần gửi về server.

Data cần persist: User input như form fields - cần gửi về server và lưu vào database.

Ephemeral data: Trạng thái tạm thời - form validation state, tab hiện tại, section có đang expand không... có thể accept khi mất data khi đóng browser.

Ví dụ Data Model cho News Feed

Entity	Belongs to	Fields
Post	Feed Post	id, created_time, content, image, author, reactions
Feed	Feed UI	posts (list), pagination metadata
User	Client Store	id, name, profile_photo_url
NewPost	Feed Composer	message, image

Note: Tùy tiến độ bài thi và yêu cầu phát triển, bạn có thể thêm fields sau. Đây là quá trình động và lặp lại.

4. Interface Definition - Định nghĩa API cho Front-end

Thời gian khuyến nghị: Khoảng 15% buổi phỏng vấn

Định nghĩa interface giữa các components. API có thể là:

• Server-client: HTTP/WebSocket APIs
• Client-client: JavaScript functions

Mọi API đều có ba phần:

Phần	Server-client	Client-client
Tên và chức năng	HTTP path	JavaScript function
Parameters	GET query, POST params	Function parameters
Return Value	HTTP response (JSON)	Function return value

Ví dụ Server-client API: Lấy Feed

Request:

GET /feed

Parameters:
{
  "size": 10,
  "cursor": "=dXNlcjpXMDdRQ1JQQTQ"
}

Response:

{
  "pagination": {
    "size": 10,
    "next_cursor": "=dXNlcjpVMEc5V0ZYTlo"
  },
  "results": [
    {
      "id": "123",
      "author": {
        "id": "456",
        "name": "John Doe"
      },
      "content": "Hello world",
      "image": "https://www.example.com/feed-images.jpg",
      "reactions": {
        "likes": 20,
        "haha": 15
      },
      "created_time": 1620639583
    }
  ]
}

5. Optimizations and Deep Dive - Tối ưu hóa Front-end

Thời gian khuyến nghị: Khoảng 40% buổi phỏng vấn

Đây là phần chiếm nhiều thời gian nhất trong front-end system design. Không đủ thời gian để cover hết mọi thứ, nên hãy chọn khéo.

Chiến lược chọn topic trong System Design Interview

Tập trung vào phần quan trọng của sản phẩm: E-commerce thì nói về performance, collaborative editor thì nói về race conditions và concurrent modifications.

Chơi sở trường: Nếu bạn giỏi accessibility thì nói sâu về nó, giỏi performance thì nói về các optimization techniques.

Các chủ đề có thể nói trong Front-end System Design

• Performance: Load time, interaction speed
• User Experience: Responsive, feedback, error handling
• Network: Caching, compression, CDN
• Accessibility (a11y): Keyboard navigation, screen reader support
• Multilingual Support: i18n, l10n
• Multi-device Support: Responsive design, Progressive Enhancement
• Security: XSS protection, CSRF tokens, content security policy

Tóm tắt Framework RADIO cho System Design

Step	Objective	Duration
Requirements	Hiểu rõ đề và xác định scope	<15%
Architecture	Xác định components và quan hệ	~20%
Data Model	Mô tả entities và fields	~10%
Interface	Định nghĩa API giữa components	~15%
Optimizations	Discuss optimization opportunities	~40%

Framework này giúp mình có một cấu trúc rõ ràng khi đối mặt với các câu hỏi front-end system design. Quan trọng nhất là bước Requirements - nếu bạn không hiểu rõ đề từ đầu, có thể thiết kế sai hoàn toàn hướng đi trong system design interview.

Kết luận về Front-end System Design

Hy vọng RADIO framework này giúp ích được cho các bạn đang chuẩn bị cho các buổi phỏng vấn system design front-end! Đừng quên luyện tập với các câu hỏi thực tế và làm quen với các công cụ vẽ diagram như Excalidraw hoặc diagrams.net.