<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Cà Phê &amp; Code — Kiến trúc hệ thống</title>
    <link>https://coffeecode.vn/categories/kien-truc-he-thong</link>
    <description>Cà Phê &amp; Code là blog dành cho những người yêu công nghệ và lập trình. Nơi chia sẻ kiến thức coding, công cụ hữu ích, xu hướng công nghệ, kinh nghiệm phát triển phần mềm và những câu chuyện phía sau màn hình — tất cả được kể theo cách gần gũi, dễ hiểu, như một cuộc trò chuyện bên tách cà phê.</description>
    <language>vi</language>
    <atom:link href="https://coffeecode.vn/categories/kien-truc-he-thong/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Discord lưu hàng nghìn tỷ tin nhắn: chống hot partition, đo THẬT trên ScyllaDB</title>
      <link>https://coffeecode.vn/posts/htl-01-discord-nghin-ty-tin-nhan</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-01-discord-nghin-ty-tin-nhan</guid>
      <description>Discord chứa hàng nghìn tỷ tin nhắn. Bài toán khó: một kênh nóng biến thành một partition khổng lồ. Cách giải: khoá phân mảnh (channel_id, bucket). Bài này dựng THẬT trên ScyllaDB, tạo cả hai schema và dùng nodetool đo trực tiếp: partition nóng 315KB/14.237 cell với đọc 2.106µs, còn bucket chỉ 29KB/1.109 cell đọc 207µs.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Consistent hashing: cách Amazon Dynamo chia dữ liệu, dựng THẬT trên Redis Cluster</title>
      <link>https://coffeecode.vn/posts/htl-02-consistent-hashing-dynamo</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-02-consistent-hashing-dynamo</guid>
      <description>Chia khoá cho N node bằng hash%N nghe hợp lý — cho tới khi thêm một node và gần như MỌI khoá phải chuyển chỗ. Dynamo (2007) giải bằng consistent hashing. Bài này dựng THẬT một Redis Cluster 3 node (16384 hash slot), nạp 20.000 khoá, thêm node thứ 4 và đo trực tiếp: chỉ 24,9% khoá phải dời (~1/N) thay vì ~75% của modulo.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Kafka và log phân tán: chạy THẬT và đo 1,25 triệu message/giây trên một broker</title>
      <link>https://coffeecode.vn/posts/htl-03-kafka-log-phan-tan</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-03-kafka-log-phan-tan</guid>
      <description>Kafka ghi xuống đĩa mà vẫn ingest hàng triệu message/giây. Bí quyết là một lựa chọn cấu trúc: log chỉ-thêm-vào-cuối biến mọi ghi thành tuần tự, cộng page cache và zero-copy. Bài này chạy THẬT Kafka 3.8 và đo bằng chính công cụ perf của Kafka: producer 1.253.132 records/giây (119,51 MB/s), consumer 1.139.211 msg/giây.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Uber tìm tài xế gần bạn thế nào: geospatial index chạy THẬT trên Redis GEO</title>
      <link>https://coffeecode.vn/posts/htl-04-uber-geospatial-index</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-04-uber-geospatial-index</guid>
      <description>Ghép khách với tài xế không thể so khoảng cách tới cả triệu tài xế mỗi lần. Bài này dựng THẬT một chỉ mục không gian trên Redis GEO (dùng geohash), nạp 500.000 tài xế và đo trực tiếp: GEOSEARCH trả lân cận đã sắp theo khoảng cách, 13.368 truy vấn/giây p50 3,6ms, index 42MB. Và vì sao Uber tự xây H3 lục giác.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Dựng feed như Twitter/X trên Redis THẬT: fanout ghi vs đọc và bài toán người nổi tiếng</title>
      <link>https://coffeecode.vn/posts/htl-05-feed-fanout-twitter</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-05-feed-fanout-twitter</guid>
      <description>Timeline phải trả về tức thì dù bạn theo dõi hàng nghìn người. Bài này dựng feed THẬT trên Redis: push bằng LPUSH, đọc bằng LRANGE. Đo trực tiếp: một tweet của sao 50 triệu follower = 50 triệu LPUSH ~ 138 giây fanout cho MỘT tweet. Và cách hybrid push-người-thường / pull-người-nổi-tiếng cứu hệ thống.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Cloudflare giới hạn tần suất ở biên: dựng sliding window counter THẬT trên Redis</title>
      <link>https://coffeecode.vn/posts/htl-06-cloudflare-rate-limit</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-06-cloudflare-rate-limit</guid>
      <description>Rate limit ở biên phải chạy cho hàng triệu danh tính mà vừa chính xác vừa cực rẻ RAM. Fixed window cho lọt gấp đôi ở ranh giới; log chính xác ngốn RAM. Bài này dựng sliding window counter kiểu Cloudflare chạy THẬT trên Redis bằng script Lua nguyên tử — đo trực tiếp: fixed cho lọt 200, sliding chặn ở 102; và MEMORY USAGE thật 96 byte vs hơn 1 MB.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Stripe idempotency key: vì sao retry thanh toán không tính tiền bạn hai lần</title>
      <link>https://coffeecode.vn/posts/htl-07-stripe-idempotency</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-07-stripe-idempotency</guid>
      <description>Mạng chập chờn khiến client retry — và với thanh toán, retry ngây thơ nghĩa là tính tiền hai lần. Stripe giải bằng Idempotency-Key: lưu kết quả lần đầu, request trùng key trả lại kết quả cũ mà không thực thi lại. Bài này dựng THẬT trên Redis bằng Lua atomic và đo: có idempotency trừ tiền 1 lần, không có thì 5 lần.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Instagram sinh ID phân tán: 64 bit gói cả thời gian, shard và thứ tự</title>
      <link>https://coffeecode.vn/posts/htl-08-instagram-id-phan-tan</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-08-instagram-id-phan-tan</guid>
      <description>Ở quy mô sharded, cần ID duy nhất mà không có điểm sinh trung tâm (nút thắt). Instagram gói vào 64 bit: 41 bit timestamp + 13 bit shard + 10 bit sequence, sinh ngay trong Postgres bằng PL/pgSQL. Bài này dựng THẬT đúng scheme đó: ID tăng theo thời gian, 50.000 ID không trùng, và trích được shard từ chính con số ID.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Google Bigtable dùng bloom filter: cấu trúc tí hon cứu vô số lượt tra đĩa</title>
      <link>https://coffeecode.vn/posts/htl-09-bigtable-bloom-filter</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-09-bigtable-bloom-filter</guid>
      <description>Đọc một khoá không tồn tại trong LSM-store phải tra nhiều SSTable trên đĩa — rất phí. Bigtable đặt một bloom filter trong RAM cho mỗi SSTable để trả lời rẻ tiền &apos;khoá này chắc chắn không có&apos;. Bài này dựng THẬT bằng RedisBloom: 1 triệu khoá, dương giả 0,5%, không bao giờ âm giả, và nhỏ hơn SET ~41 lần.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Tìm kiếm toàn văn như Elasticsearch: inverted index đánh bại LIKE ~1000 lần</title>
      <link>https://coffeecode.vn/posts/htl-10-elasticsearch-inverted-index</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-10-elasticsearch-inverted-index</guid>
      <description>LIKE &apos;%từ%&apos; phải quét từng bản ghi — O(n), không index được. Elasticsearch (và Lucene) dùng inverted index: ánh xạ từ tới danh sách tài liệu chứa nó. Bài này dựng THẬT trong PostgreSQL bằng tsvector + GIN và đo EXPLAIN ANALYZE: cùng kết quả nhưng inverted index nhanh hơn ~1092 lần trên 500.000 tài liệu.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
    <item>
      <title>Stack Overflow cân bằng tải với HAProxy: chia tải và tự loại máy chủ chết</title>
      <link>https://coffeecode.vn/posts/htl-11-haproxy-load-balancing</link>
      <guid isPermaLink="true">https://coffeecode.vn/posts/htl-11-haproxy-load-balancing</guid>
      <description>Một máy chủ không chịu nổi tải, và máy chủ thì có lúc chết. HAProxy chia request ra nhiều backend và dùng health check tự loại backend hỏng mà không rớt request. Bài này dựng THẬT HAProxy + 3 backend: round-robin chia 4/4/4, giết một backend thì tự dồn 6/6 không lỗi 5xx, bật lại thì tự quay vào pool.</description>
      <pubDate>Tue, 22 Sep 2026 00:00:00 +0700</pubDate>
      <category>Kiến trúc hệ thống</category>
    </item>
  </channel>
</rss>
