Thú thật,mình cũng sử dụng AI rất nhiều, hằng ngày. Nó nhanh, nó tiện, nhưng nó khiến mình thấy... chán. Feature ship nhanh, UI đẹp nhưng không còn cảm thấy “đã cái nư” khi hoàn thành.

Cuối tuần vừa rồi, thay vì chạm cỏ, mình quyết tâm tìm lại cảm giác "chạm code”.

Tiêu chí đơn giản:
- Phải ngắn và dễ (mấy project vô thưởng vô phạt tốt nhất làm trong 1,2 ngày là đẹp, phức tạp quá là bỏ dở ngay. Kinh nghiệm sau khi mình đắp chiếu mấy con pet project 🪦)
- Gõ code thuần chay, tự tư duy, chỉ tra cú pháp (nói không với AI )
- Đủ thú vị nhưng phải "low-level" một chút để học được gì đó: no CRUD, task trên công ty quá đủ rồi 🤣

Rồi mình tìm được CodeCrafters.io. Họ cho phép build lại các công cụ kinh điển (Redis, Git, Docker...) và tháng này họ đang miễn phí khóa Build Your Own Shell. →Chân ái đây rồi. Quất!

Đây là những gì mình học được sau vài tiếng "vật lộn" với Python để tạo ra một chiếc Shell của riêng mình.

1. Shell thực chất là gì?

Đừng để cái terminal đen ngòm đánh lừa. Chả có gì cao siêu cả.

Làm theo hướng dẫn của app, mình mới thấy. Về bản chất, Shell cũng chỉ là một chương trình bình thường. Nó chạy một vòng lặp vô tận (REPL - Read-Eval-Print-Loop) để chờ đợi và xử lý input từ người dùng.

Cấu trúc cốt lõi chỉ đơn giản thế này:

while True:
    sys.stdout.write("\( ") # Dấu \) huyền thoại của shell, trên window sẽ là PS - Power Shell
    user_input = input() # Đọc input
    parse(user_input): # Kiểm tra input, xem user muốn làm gì
    execute() # Thực thi
    print() # in output ra màn hình

Ví dụ cách shell hoạt động khi nhận input: echo “hello world”

2. Bài toán tìm kiếm: Lệnh nằm ở đâu?

Nếu bạn giống mình, là 1 web developer, thì khoảnh khắc wow đầu tiên của mình là chính là:

Mở terminal → gõ “code .” → VS Code hiện lên 😮→ hacker 😎

Nhưng mình tin là ít nhất trong đời dev, bạn cũng từng vò đầu bứt tai với cái màn hình này:

Vậy có bao giờ bạn thắc mắc: “làm thế méo nào cái màn hình đen này nó hiểu được lệnh đó?”

Câu trả lời nằm ở một biến môi trường mang tên$PATH . Biến chứa list các folder mà Shell sẽ ưu tiên tìm kiếm file có thể execute được mỗi khi bạn gõ một lệnh bất kỳ.

ở window file execute là đuôi “.exe”, nôm na là double click thì chạy được. Ví dụ python.exe

Ví dụ, bạn gõ python —version , nếu $PATH không chứa folder dẫn tới python.exe, Shell sẽ chịu chết và trả về dòng lỗi "not recognized".

CodeCrafters.io bắt mình tự code chay logic tìm kiếm này. Từ đó mình mới hiểu từ gốc rễ tại sao có những lệnh chỉ cần gõ tên là chạy, còn có những lệnh lại không.

Muốn tái hiện lại màn hình “python not recognized” phía trên không? vào Environment Variables → Path → Delete bất kỳ lệnh nào bạn muốn rồi gõ lại vào terminal xem 😅: nodejs, vscode, jdk,….

Lý thuyết là thế thôi, tới lúc code cái logic tìm $PATH này, mình mới va phải những trải nghiệm "đau thương" !

Window vs Linux: Cuộc chiến Path Separator

Mình thì code trên window nhưng ông CodeCrafters.io lại chạy test trên? Linux.
App thì báo input để chạy test là /usr/bin/grep.
Nhưng window làm méo gì có folder này mà test ở local.
Mình lại phải vào biến $PATH copy folder python ra test: D:\apps\Scoop\apps\python\current (mình cài bằng Scoop)

Code xong mỗi bài, CodeCrafters.io sẽ chạy test trên môi trường Linux

Khổ nỗi tới khâu cộng chuỗi để tìm full path cho file .exe: D:\apps\Scoop\apps\python\current + “\python.exe”.

Test local thì ngon ăn, nhưng subtmit và chạy test trên CodeCrafters thì fail. 🤡

Ra là ông Window thì dùng \, ông Linux thì dùng / . Hard code string thì đúng ăn hành luôn.
Bảo sao chạy test mãi ko qua.

Đọc comment thì thấy các pros bảo phải xử lý đặc biệt bằng thư viện os :
- os.pathsep : tự nhận path separator theo môi trường, khỏi lăn tăn \ hay /
- os.path.join: uỷ thác khâu join cho thư viện, nhàn.

Một bài học nhỏ thôi, nhưng nhắc nhở mình về tính tương thích của hệ thống.
Và đấy mới là thử thách dạo đầu thôi.

Cú lừa mang tên code.cmd

Vẫn là trong lúc code cái tìm $PATH. Thử lệnh python —version ngon rồi, mình hào hứng test thêm lệnh code.

Hí hửng tưởng mở được vscode trong cái shell tự chế thì ngon hơn HDPE luôn. Nhưng thứ nhận lại chỉ có Command not found 🤡

Hoá ra,trên Windows, khi tìm file thực thi, không phải lúc nào nó cũng là .exe.
Kiểm tra kỹ trong D:\apps\Microsoft VS Code\bin, mình mới thấy file thực thi thực chất tên code.cmd. Ok, giờ mới để ý có đuôi .cmd nữa.

Từ đó, mình rút ra logic: Khi tìm kiếm một lệnh, Shell phải check đồng thời cả bộ extension: [.exe, .bat, .cmd, ...]. List này dài lắm, mình ghi mấy cái phổ biến thôi.

Code trên Window thì đau đầu vậy, còn trên Linux thì đơn giản hơn. File có 3 quyền cơ bản: read, write, execute. Tương ứng rwx.

Muốn biết file nào chạy được thì chỉ cần gõ ls -la xem có quyền thực thi ( có chữ X) không:

3. "Wow Moment": Khi cái app biến thành Shell thật

Sau khi xong tính năng Execute, mình đọc được 1 comment ở dưới: “ê, sau bài này, chúng mày thử commit bằng chính cái Shell này đi, vì git nằm trong PATH mà. Đã lắm”

Ê hay nha, test thử git version và git status. Ngon! dính liền

Terminal gốc của mình là phần màu mè, còn sau khi chạy file main là lên hình con Shell $ rồi đó.

Đoạn này là phê nhất luôn. Mình chắc chắn là bạn cũng từng trải nghiệm cảm giác này: fix đc con bug khó, chạy đc feature lần đầu,...

Chứ giờ có AI rồi, có khi cảm giác này lại hơi xa xỉ😁.

4. Kết luận

Dành ra một cuối tuần để build "đồ cổ" như Shell không hề lãng phí. Nó giúp mình củng cố lại kiến thức về Process, PATH, và cách OS vận hành bên dưới.

Nếu bạn là real dev cũng đang thấy "ngán" dùng AI, mất lửa với code dần, hãy thử dành 1 buổi với CodeCrafters để tìm lại cảm giác nhé.

Repo của dự án: https://github.com/vanbeonhv/my-own-shell

Trong quá trình phát triển ứng dụng microservice, mình đã gặp phải một tình huống thú vị: tại sao cache hit rate lại thấp đến thế khi có nhiều request cùng lúc?
Câu chuyện này không chỉ giúp mình hiểu sâu hơn về Single Flight pattern, mà còn học được cách xử lý hot spot, thread-safe và race condition trong thực tế.

1. Use case thực tế:

App của mình nằm trong một hệ microservice. Do đặc thù của app, mọi API đều cần kiểm tra quyền truy cập bằng cách gửi request tới Auth service.

Vấn đề phát sinh: Khi lần đầu access app, sẽ có nhiều API cần gửi cùng một request kiểm tra "View" permission. Điều này tạo ra một hot spot - nhiều request cùng "săn đón" một resource.

Ngay lập tức mình nhớ tới blog của anh Quang Hoang: #6 - Điểm nóng, lần đầu tiên mình nghe về khái niệm Request Collapsing hay Singleflight. (btw, blog a này viết khá đỉnh, dễ đọc, recommend ae follow)

Ý tưởng cốt lõi: Thay vì mỗi request gửi riêng, ta gom tất cả các request giống nhau lại, chỉ gửi 1 request đi. Các request còn lại sẽ chờ response từ request "đại diện".

2. Triển khai ban đầu

Hiện Trạng Cache System

Trên server mình đã triển khai in-memory cache cho permission của từng user. Tuy nhiên, khi có nhiều request cùng access một key, tỉ lệ cache miss cực cao.

Flow ban đầu đơn giản như sau: ( viết dạng concept để dễ hình dung nhé )

public async Task<bool> CheckPermissions(string permission)
    // Tạo cache key từ user token + permission
    var cacheKey = userToken + "-" + permission

    // Kiểm tra cache trước
    IF cache.exists(cacheKey) THEN
        log("Thread ID - Cache hit - trả về kết quả từ cache")
        RETURN cache.get(cacheKey)
    END IF

    // Gọi API kiểm tra quyền
    apiUrl = "Http://api/permission-check"
    var response = await POST(apiUrl, {permission: permission})
    // Xử lý response và lấy kết quả
    var result = parseAuthResponse(response)
    // Lưu vào cache 1 phút
    cache.set(cacheKey, result, 1minute)

    RETURN result

Đây là kết quả mình nhận được với 7 request cùng lúc: 6 cache miss, 1 cache hit.
Tỉ lệ hit: 1/7 ~ 14% - quá thấp

Nguyên Nhân: Thundering Herd Problem

Hiện tượng này gọi là thundering herd - khi một key hết hạn và đồng thời nhiều request cùng truy cập vào DB/service, dẫn tới quá tải. Đôi khi là nhiều key cùng hết hạn 1 lúc do đặt chung TTL (Time to live). Giải pháp thường là đặt key có TTL random.

Trong case của mình, Auth service bị "tấn công" bởi hàng loạt request kiểm tra permission giống hệt nhau, tại thời điểm user access app lần đầu.

(nguồn: bytebytego)

3. Áp Dụng Single Flight Pattern

Để bảo kê cho Auth service khỏi quá tải, cùng triển khai Single flight nhé. Mình thích cái tên này vì rất dễ liên tưởng.

Giống như một nhóm anh em chiến hữu của bạn book vé máy bay tới Phú Quốc. Thay vì điều 1 chuyến bay riêng cho từng ông, Vietnam Airline chắc chắn sẽ gom hết cả đám lên cùng 1 chuyến bay rồi chờ 1 thể

“Chuyến bay” ở đây chính là request check permission gửi tới Auth service đó.
( Còn tại sao lại là Vietnam Airline? Vì lần trước chuyến bay Vietjet tới Phú Quốc của mình bị delay 2 tiếng lận, request thì ko được phép delay như thế 🤣)

Kiến Trúc Single Flight

Ta sẽ có 3 component chính ở đây:

• Request coordination: Nơi điều phối request. Khi 1 request tới, kiểm tra xem có request tương đương nào đang “bay” không?
  - Nếu có → xếp hàng chờ
  - Ngược lại → cho "cất cánh", gửi tới Auth service.

• In-flight Registry: Dictionary lưu trữ các "chuyến bay".
  - Key: user_token + permission
  - Value: Task(C#)/Promise(JS), đại diện cho async request function tới Auth service

• Clean Up: Xoá khai báo “chuyến bay” khỏi Registry bên trên sau khi request hoàn thành.

Flow sẽ như này. Chỉ gồm flow mới, code cũ đã được đơn giản hoá

//In-flight Registry mình nhắc bên trên đây. Chú ý value là 1 Task nhé.
Dictionary<string, Task<bool>> _inFlightRequests;

public async Task<bool> CheckPermissions(string permission) {
    var cacheKey = userToken + "-" + permission

    if (cache.Hit) return cachedValue;
    // NEW: Nếu request đang "bay"
    if (_inFlightRequests.ContainsKey(key))
        log("ThreadId - Permission - Cache in-flight hit") 
        return await _inFlightRequests[key]; // Chờ request "bay" về

    // Tạo request mới và đăng ký. Nhớ là mình chỉ tạo 1 async function,
    // chứ chưa await nó nhé. Request chưa thực sự chạy đâu. 
    var task = ExecuteActualRequest(permissions); 
    _inFlightRequests[key] = task;

    try { 
        var result = await task; // Tới đây mới await, cho request "bay"
        return result; 
    } finally { 
        _inFlightRequests.Remove(key); // Bay về rồi thì clean đi 
    }
}

Kết quả cải thiện

Với 7 request đồng thời: 4 cache hit, 2 cache miss, 1 cache in-flight.
Bingo! Từ 6/7 request miss xuống chỉ 2/7 request miss - giảm 60-70%! (Vẫn còn race condition cần xử lý)
Giả sửa nếu ko phải 7 mà là 100, 200, 1k request, lượng giảm còn nhiều hơn nhiều.

Vấn Đề Còn Tồn Tại: Race Condition

Tại sao vẫn có 2 cache miss? Đó là race condition - các thread đồng thời kiểm tra cache:

ThreadId: 17 - cache in-flight hit    // Thread đầu tiên, tìm thấy in-flight request
ThreadId: 14 - cache miss            // Race: chưa kịp add vào in-flight registry  
ThreadId: 24 - cache miss            // Race: chưa kịp add vào in-flight registry

Với quy mô app của mình thì thực ra dừng ở đây là cũng oke. Nhưng tới đây rồi, tại sao lại không tối ưu thêm để với 1 key chỉ có đúng 1 in-flight request thôi nhỉ?

4. Giải Pháp Thread-Safe Hoàn Chỉnh

Nhắc tới giải quyết vấn đề truy cập đồng thời cao, phải nhắc tới lock. Ở đây để đơn giản, mình sẽ sử dụng 1 local lock, được C# built-in.
Với mỗi key sẽ tạo ra 1 lock object . Chỉ key nào acquire được lock mới cho “bay”.

Dictionary<string, object> _lock;

public async Task<bool> CheckPermissions(string permission) {
    var cacheKey = userToken + "-" + permission
    if (cache.Hit) return cachedValue;
    //Tạo lock theo từng key
    var lockKey = _lock.GetOrAdd(cacheKey)

    var task;
    // Chỉ 1 thread lấy được lock
    lock (keyLock) {
        // double check vì cache có thể hit khi thread trước đó vừa ghi cache
        if (cache.Hit) return cachedValue;

    // Đem nguyên đống logic cũ bỏ vào trong này
        if (_inFlightRequests.ContainsKey(key)) 
            task = _inFlightRequests[key]
        else
            var task = ExecuteActualRequest(permissions); 
            _inFlightRequests[key] = task;
    }

    try { 
        return await task;
    } finally { 
        _inFlightRequests.Remove(cacheKey);
        _lock.Remove(lockKey); // Nhớ nhả lock đó ae 
    }
}

Kết quả: Perfect! Với lock mechanism, giờ đây chỉ có duy nhất 1 request được gửi tới Auth service cho mỗi key cache, bất kể có bao nhiều request đồng thời.

Test với 7 request đồng thời: Chỉ 1 request thực sự "bay", 6 request còn lại đều chờ và nhận kết quả từ request đầu tiên.

Lưu ý:
- Trong bài mình khai báo Dictionary đơn giản cho In-flight Request và Lock. Nhưng thực tế đây là các object cần share state giữa các request, nên các bạn nhớ khai báo dạng Static hoặc scope Singleton (.net) nhé.
- C# có 1 builtin type là ConcurrentDictionary chuyên để support thread-safe. Nên sử dụng type này.
- Bài viết tập trung vào triển khai pattern. Còn về kiến trúc thì ko phải là best practise, nên sử dụng API Gateway cho việc authen.

Kết

1. Single Flight Pattern giúp đạt được perfect deduplication - chỉ 1 request duy nhất cho mỗi key

2. Thread safety với lock mechanism là then chốt để loại bỏ hoàn toàn race condition

Bạn đã từng gặp phải thundering herd problem chưa? Chia sẻ experience của bạn trong comments nhé!

Reference:

1. #6 - Điểm nóng - by Qreuang Hoang

2. Bytebytego - Caching Pitfalls Every Developer Should Know

3. Cách Discord Lưu Trữ Hàng Nghìn Tỷ Tin Nhắn Với ScyllaDB | 200Lab Blog (quá trình migrate db của discord cũng sử dụng pattern này)

4. https://discord.com/blog/how-discord-stores-trillions-of-messages (link gốc)

• Lần đầu biết pg_dump là gì và vì sao DBeaver cần nó khi backup

• Biết vì sao Flatpak gây lỗi khi app cần truy cập trực tiếp file hệ thống

• Tránh mất thời gian debug khi dùng tool dev với Flatpak

Mình mới chuyển sang dùng Fedora (linux) được 1 tháng. Hôm nay cần backup data, nên mở Dbeaver lên để backup nhưng gặp lỗi này: "Local client is not specified for connection.”

Local client là gì cơ? Search 1 lúc, mình hiểu Local client là chương trình dòng lệnh đi kèm với PostgreSQL, như pg_dump để backup hoặc psql để query.

Theo như Dbeaver, mình cần thêm dẫn path tới pg_dump.

Hóa ra trước giờ mình toàn connect tới database ở cloud chứ máy local không hề cài Postgres. Bây giờ từ cloud mà cần thao tác với local disk (backup/restore) thì cần cài Postgres là hiển nhiên rồi 😂.
Sau khi cài, mình kiểm tra path của pg_dump

Got it: /usr/bin/pg_dump .Giờ thêm path này vào Local client là xong. Khoan, trên page của Dbeaver có cho mình 1 tip, cài package libpq có thể giúp Dbeaver tìm được client tự động.

Nào thì thử cài:

Cái kết là không work. Đọc kỹ mới thấy hóa ra chỉ áp dụng cho macOS thôi. 😑 Cho chừa thói hấp tấp.

Giờ thì mình đoán thêm path của pg_dump là xong: .
Hmm, sao rõ ràng thêm đúng path rồi /usr/bin/pg_dump.
Mà Dbeaver hiển thị path lạ thế nhỉ: /run/user/1000/doc/3de82b55/bin - 1 path “ảo”.
Phải chăng do môi trường nào đó tạo ra?

Lúc đó mình nghĩ chắc lỗi hiển thị gì đó thôi. Cứ bấm Ok xem sao.

Nope. Không work.
Sau đó mình thử đi thử lại,từ paste thẳng tới bấm browse để chọn path → Vẫn ra như cũ.
Follow từng bước trên Dbeaver Wiki → cũng không chạy được!!
Hẳn là vấn đề ở đâu đó chứ ko phải tại Dbeaver. Vì trước đó chạy trên Window ko bị. Mình đã nghĩ tới dùng pg_dump ở cli. Vì đúng bản chất của nó mà.
Nhưng, thử cố tìm vấn đề xem. Chắc liên quan tới linux rồi 🤔

Cuối cùng, không ngờ tới là vấn đề lại nằm ở Flatpak. Đây là 1 kho ứng dụng trên Linux, giống như Microsoft Store hay CH Play vậy. Mình có tải Dbeaver từ đây, cứ nghĩ là Store bình thường giống như apt trên Ubuntu vậy thôi.

Flatpak lại chạy kiêu khác. Thông thường các file .exe, .deb, .rpm , để cài được thì phải đúng hệ điều hành (.dev với Ubuntu, Debian, .rpm với Fedora, Centos ).
Flatpak đóng gói app lại, chạy trong sandbox*, bị “bọc” trong môi trường riêng*. Nghe quen quen đúng không? Đúng, giống y như Docker vậy 😉. Tức là chả cần biết bạn chạy distribution nào: Ubuntu, Fedora, Centos,… chạy được hết.

Quay lại vấn đề, vì chạy trong sandbox, cơ bản thì app trên Flatpak ko thể đọc (đúng hơn là không có quyền đọc) path của hệ thống. Lý giải cho việc dù mình nhập /usr/bin/pg_dump , Dbeaver lại đọc thành /run/user/1000/doc/3de82b55/bin - 1 path ảo.

Vậy cách fix như nào? Linux cho phép quản lý phân quyền rất chi tiết cho từng folder. Cấp quyền cho Flatpak đọc folder đó là được.

Nhưng mình ko muốn mỗi khi có vấn đề lại phải cấp quyền, nên chọn giải pháp đơn giản hơn: “Tải file .rpm từ trang chủ Dbeaver” 😅 . Nhanh gọn, dễ dàng đọc path bên ngoài.

Qua trải nghiệm này, mình rút ra một số nguyên tắc nhỏ khi làm việc với GUI app trên Linux:

• Nếu app cần tương tác trực tiếp với file hệ thống (như pg_dump), hãy tránh cài qua Flatpak vì sandbox sẽ gây lỗi khó đoán.

• Với PostgreSQL, các thao tác như backup/restore cần công cụ CLI (pg_dump, psql...) — nên đảm bảo cài đầy đủ và biết nó nằm ở đâu.

• Flatpak rất tiện, nhưng không phải lúc nào cũng hợp với tool dành cho dev.

Reference:
https://dbeaver.com/docs/dbeaver/Local-Client-Configuration/
https://flathub.org/