Nguyễn Đức An

Một chút suy nghĩ về view First Principle Thinking mình nghĩ là mình sẽ học cách apply vào lĩnh vực Technical và mình chia sẻ ở đây.

Đầu tiên, thì First Principle Thinking bạn có thể tìm hiểu trên mạng thì đại ý của nó là hãy đặt càng nhiều câu hỏi “Why” để break 1 system lớn thành từng atomic block nhỏ nhất có thể. Đại loại thì thế giới vận hành như 1 khối lego lớn, thì khi bạn break nó sang thành từng mảnh lego nhỏ đến bản chất atomic nhất của vấn đề ⇒ bạn có thể dùng các mảnh lego nhỏ đó để build 1 thứ mới.

Nếu bạn tìm hiểu về MBTI, thì nó khá giống cơ chế của Ti (Thinking Introverted) function. Mình là 1 Ne-Ti user, mình dùng Ne để collect 1 lượng lớn rời rạc knowledge base. Cách consume thông tin của mình là 1 cách always xảy ra, không phải by intentional, nói ngắn gọn là mình consume liên tục những kiến thức rời rạc chứ không phải là có goal rồi mới đọc.

Ví dụ 1 cái mình đọc nha, mình có đọc về “Building Blocks” trong System Design, khi mình đọc tới block “DNS” trong System Design, mình đọc rất sâu về thuật toán BGP routing của DNS với 1 câu hỏi là ví dụ mình ở Việt Nam bật VPN 1.1.1.1 thì làm sao nó route mình tới server Singapore gần nhất hay server Mỹ ntn ? Nhưng mình đọc cái này chỉ vì câu hỏi tò mò khi mình đang học về DNS thôi, thường mấy cái cloud nó default mindset cho các bạn về mặt này rồi, nó sẽ không đóng góp quá nhiều khi các bạn đang đặt goal là hoàn thành 1 dự án, nên cái động lực để mình đọc mấy cái vô tri này là vì tò mò với ham kiến thức thôi.

Nên là nó dẫn đến là, mình có thể là 1 knowledge base di động, kho thông tin bất chấp, nhưng mình sẽ không biết dùng cái mình có như thế nào. Vì nó xuất phát hoàn toàn từ sự tò mò, không phải mục đích.

Đại loại thì đối với 1 System Design lớn, thường các bạn sẽ tiếp cận theo “Pattern thinking”, “template”, nghĩa là cứ đối với public api các bạn lại phải có “Redis caching”, đối với high-write throughput thì các bạn lại phải dùng “Kafka”, nhưng suy nghĩ kiểu này thì nó sẽ vô tình limited lại cái suy nghĩ của các bạn luôn nghĩ về “problem” theo “template”, nó work most use cases, nhưng khi va vào thực tế sẽ xảy ra những cái “uncertain” hay điểm mù khác.

Thì cái First Principle Thinking này nó ra đời để mình “dùng” được cái kho kiến thức khổng lồ này của mình. Đối với mỗi System Design lớn, hãy mang 1 tư duy là “Building Blocks”, vấn đề có thể xảy ra ở đâu ? Có thể xảy ra ở “Server”, “Database”, “Redis”, “Kafka” với xác suất 90% như các bài System Design đang hiện có, nhưng 10% còn lại có thể xảy ra ở “DNS”, “Load Balancing”, “API Gateway”. Thế thì phân biệt các problem pattern phổ biến thì khác gì giam cầm cái suy nghĩ của mình vào “90% problems” ở trên à ?

Cái First Principle Thinking này ngắn gọn là tư duy “Building Blocks” ⇒ “Hãy giải quyết tất cả các vấn đề ở tất cả các blocks của System đó”, từ đầu cổng vào: API Gateway, Load Balancing đến phần process và lưu trữ data quan trọng như: Server, Database, Cache,… thậm chí ở mọi block hay third-party liên quan, không bị bias theo template có sẵn.

Thay vì hỏi: “Design Twitter”, xong đi coi các mẫu template pattern trên mạng.

Bạn hãy hỏi với mindset “Seeking the truth”

• What problem am I actually solving?
• What are the physical constraints? (latency, memory, network, CPU)
• What must be true for this to work?
• What can be removed?

Đây là tất cả những gì 1 distributed system hoặc “problem thực tế” mà “System Design bạn đang làm” phải giải quyết, nơi mà khi giải quyết sâu từng block thì kho “kiến thức rời rạc” của mình sẽ có tác dụng để mình cover hết được nó.

Mà không thể là chỉ nói về “implement và design”, bạn có thể hỏi sâu hơn như:

• Stakeholder liên quan làm dự án này là vì sao ?
• Chiến lược của sếp làm cái này là đúng không ?
• Nếu sếp sai thì sao ?
• Khi deploy lên, lỡ khi cách này failed, thì m sẽ reverse lại bước trước đó bằng cách nào ?

Anyway miễn là hỏi đến khi nào bạn không còn câu hỏi nữa, hoặc vượt quá ngưỡng “emotional overwhelmed” của bạn thôi ? Vì các câu hỏi “không thuộc block này cũng thuộc block khác thôi”.