#sach
81 bài viết về chủ đề này
Monitoring Microservices — Log, Metric & Correlation ID (BMS)
Giám sát microservices: ba trụ quan sát (log, metric, tracing) và correlation ID để theo dõi request xuyên nhiều service.
Communication Implementation — REST, gRPC & Message Brokers (BMS)
Chọn công nghệ giao tiếp giữa microservices: so sánh REST, gRPC và message broker, tiêu chí lựa chọn và schema evolution.
Microservices không phải lựa chọn mặc định (Building Microservices)
Afterword Building Microservices: khi nào nên và không nên dùng microservices, cạm bẫy tách nhỏ quá sớm và khởi đầu an toàn với monolith.
Evolutionary Architect — Vai trò kiến trúc sư thời microservices
Vai trò kiến trúc sư trong kỷ nguyên microservices: governance bằng principles, fitness functions, paved road và quản lý tech debt.
Conway's Law & Team Topologies — Tổ chức team theo dòng chảy (BMS)
Conway's Law: cấu trúc team quyết định kiến trúc hệ thống. Stream-aligned teams, platform teams, cognitive load và cách tổ chức team cho microservices.
User Interfaces & Micro Frontends — Chia UI theo team (BMS)
UI composition cho microservices: page-level, server-side (SSI/ESI), client-side — micro frontends và cách tránh UI monolith.
Scaling Microservices — 4 trục scale: vertical & horizontal (BMS)
Scaling microservices qua 4 trục: vertical, horizontal duplication, data partitioning và functional decomposition — khi nào dùng trục nào, kèm caching và CQRS.
Resiliency — CAP, Circuit Breaker & Chaos Engineering (BMS)
CAP theorem, circuit breaker, bulkhead và chaos engineering — cách xây dựng microservices phục hồi được khi sự cố xảy ra.
Zero Trust, mTLS & OAuth — Bảo mật microservices hiện đại (BMS)
Zero Trust, mTLS, OAuth 2.0 và mã hoá dữ liệu — các lớp bảo mật thiết yếu cho hệ thống microservices.
Testing Microservices — Test Pyramid & E2E (Building Microservices)
Test pyramid, consumer-driven contract test và E2E — cách giữ cho microservices deploy độc lập mà vẫn an toàn.
Container & Deployment Microservices — K8s & Progressive Delivery
Tổng quan deployment microservices: container Docker, Kubernetes orchestration, progressive delivery (canary, blue-green, feature flags).
Build & CI/CD Pipeline cho Microservices — Từ code đến deploy (BMS)
CI/CD, monorepo vs multirepo, build artifact — cách quản lý build pipeline cho hệ thống microservices hiệu quả.
End-to-End Correctness & Đạo đức dữ liệu — Tương lai data systems
Phân tích chương cuối DDIA: làm sao đảm bảo tính đúng đắn end-to-end trong distributed systems, và trách nhiệm đạo đức khi xây dựng data systems.
Thiết kế Workflow cho Microservices — Orchestration vs Choreography
Phân biệt orchestration vs choreography trong microservices workflow, cách implement Saga pattern với compensating transactions.
Data Integration & Unbundling Databases — Tách database thành những chuyên gia nhỏ (DDIA)
Tìm hiểu khái niệm unbundling databases của Martin Kleppmann: thay vì database monolithic, hãy tách thành các chuyên gia riêng biệt kết nối qua stream
Stream Joins & Fault Tolerance — Join và xử lý lỗi stream (DDIA)
Tìm hiểu 3 kiểu stream join (stream-stream, stream-table, table-table) và cơ chế fault tolerance — checkpointing, exactly-once trong streaming (DDIA).
Communication Styles — Giao tiếp Microservices(Building Microservices)
Khám phá 3 kiểu giao tiếp microservices: Request/Response (REST, gRPC), Event-Driven (message broker), và Service Discovery. Hiểu ưu nhược điểm từng pattern.
Event Streams, CDC & Event Sourcing — Cốt lõi stream processing (DDIA)
Tìm hiểu về Event Streams, Change Data Capture (CDC) và Event Sourcing — ba khái niệm quan trọng trong stream processing được trình bày trong DDIA chương 11.
Branch by Abstraction & Saga — Split Monolith (Building Microservices)
Branch by Abstraction, Saga, UI Composition — ba pattern thực tế để chia nhỏ monolith an toàn, từng bước, không đau đớn.
DDD & Bounded Context — Tách Microservices (Building Microservices)
Tìm hiểu cách ứng dụng Domain-Driven Design và Bounded Context để phân định ranh giới microservices — từ lý thuyết đến thực hành.
Xử lý dữ liệu theo lô — Unix Philosophy & MapReduce (Designing Data-Intensive Applications)
Unix pipes và MapReduce — từ sort/grep/awk trên một máy đến MapReduce chạy trên cả cluster. Tìm hiểu triết lý xử lý dữ liệu theo lô trong DDIA.
Splitting the Monolith — Chiến lược & pattern (Building Microservices)
Chiến lược chia nhỏ monolith: Strangler Fig, bounded context, tách database, xử lý transaction trong hệ phân tán.
Beyond MapReduce — Spark, Flink và thế hệ data processing mới (DDIA)
MapReduce ghi intermediate state ra disk giữa mỗi phase — đây là điểm yếu chí tử. Spark, Flink, Tez thay thế bằng DAG pipeline, xử lý trong memory, hỗ trợ cả batch lẫn streaming.
Model Microservices — DDD & Bounded Context (Building Microservices)
Domain-Driven Design là chìa khóa để xác định ranh giới microservices. Chapter 2 nói về bounded context, ubiquitous language và cách áp dụng DDD vào thực tế.
Unix Philosophy & MapReduce — Xử Lý Batch Trong Hệ Phân Tán (DDIA)
Unix pipes là nguồn cảm hứng cho MapReduce — cách các hệ thống batch processing xử lý dữ liệu quy mô lớn với triết lý đơn giản
Microservices — Khái niệm, lợi ích & cạm bẫy (Building Microservices)
Giới thiệu microservices: định nghĩa, key concepts, so sánh với monolith, pain points và khi nào nên dùng từ cuốn Building Microservices.
Ordering Guarantees & Consensus — Total Order, 2PC, Raft và ZooKeeper (DDIA)
Khám phá các cơ chế ordering guarantees và consensus trong distributed systems: total order broadcast, 2PC, Raft consensus algorithm, và ZooKeeper.
Linearizability — Mô hình đồng nhất dữ liệu mạnh nhất (DDIA)
Linearizability là mô hình consistency mạnh nhất trong distributed systems. Tìm hiểu cách nó hoạt động, khi nào cần, và cái giá phải trả.
Unreliable Clocks & Byzantine Faults — Khi thời gian trong máy tính không còn đáng tin (DDIA)
Khám phá vấn đề đồng hồ không đáng tin và Byzantine faults trong distributed systems — hai thử thách lớn khi xây dựng hệ thống phân tán
Partial Failures & Unreliable Networks — Khi hệ thống phân tán gặp sự cố (DDIA)
Chương 8 DDIA phân tích bản chất của partial failure trong distributed systems — từ network faults, timeouts đến cách thiết kế hệ thống chịu lỗi.
Serializable Isolation — 2PL và SSI cho Distributed Systems (DDIA)
So sánh Two-Phase Locking (pessimistic) và Serializable Snapshot Isolation (optimistic) — hai cơ chế đạt Serializable isolation trong cơ sở dữ liệu phân tán.
Algorithm Speed — Đừng chỉ code, hãy biết code chạy nhanh thế nào (Pragmatic Programmer #39)
Cảm nhận về Topic 39 'Algorithm Speed' trong sách The Pragmatic Programmer — Big O notation, ước lượng tốc độ thuật toán, và cách áp dụng vào thực tế coding hằng ngày.
ACID & Weak Isolation Levels — Transactions trong hệ thống (DDIA)
Tìm hiểu ACID và weak isolation levels — Read Committed, Snapshot Isolation — trong cơ sở dữ liệu quan hệ.
Programming by Coincidence — Đừng để may mắn quyết định chất lượng code (Pragmatic Programmer #38)
Topic 38 từ The Pragmatic Programmer: Programming by Coincidence — lập trình dựa vào sự tình cờ, tại sao nó nguy hiểm và làm sao để lập trình một cách có chủ đích.
Rebalancing Partitions & Request Routing — Hệ thống phân tán (DDIA)
Rebalance partition khi thêm/bớt node: consistent hashing, dynamic partitioning, fixed partitions và request routing trong distributed systems.
Listen to Your Lizard Brain — Lắng nghe trực giác khi code (Pragmatic Programmer #37)
Khám phá Topic 37: Listen to Your Lizard Brain từ The Pragmatic Programmer. Học cách lắng nghe trực giác và 'lizard brain' để code hiệu quả hơn.
Partitioning Strategies — Hash & Key-Range Partitioning, Secondary Indexes (DDIA)
Phân tích hai chiến lược partitioning chính: key-range và hash partitioning, kèm cách xử lý secondary indexes, skewed workloads trong hệ thống phân tán.
Blackboards — Khi Code Nói Chuyện Qua Một Cái Bảng Đen (Pragmatic Programmer #36)
Topic 36 'Blackboards' từ 'The Pragmatic Programmer' dạy chúng ta về mô hình blackboard — nơi các module trao đổi dữ liệu ẩn danh và bất đồng bộ, giống như các thám tử cùng phá án trên một cái bảng đen.
Multi-Leader & Leaderless Replication — Hai mô hình replication mở rộng (DDIA)
Multi-leader và leaderless replication là hai mô hình replication cho hệ thống phân tán. Tìm hiểu về quorum, CRDT, conflict resolution, read repair, sloppy quorum và khi nào dùng chúng.
Actors và Processes — Khi concurrency không cần shared state (Pragmatic Programmer #35)
Cảm nhận về Topic 35 'Actors and Processes' — cách xây dựng hệ thống concurrent không shared memory, không lock, không deadlock nhờ actor model.
Leaders, Followers & Replication Lag — Cơ chế replication (DDIA)
Single-leader replication trong distributed systems — cách leader ghi dữ liệu, follower đồng bộ, và những vấn đề replication lag gây ra.
Shared State Is Incorrect State — Trạng thái dùng chung là trạng thái sai (Pragmatic Programmer #34)
Topic 34 từ cuốn The Pragmatic Programmer: Shared State Is Incorrect State — giải thích về race condition, nonatomic updates, semaphore/mutex, và cách tránh shared state trong lập trình đồng thời.
Dataflow — DB, REST/RPC, Message-Passing: Ba cách dữ liệu di chuyển giữa các hệ thống (DDIA)
Khám phá ba mode dataflow trong distributed system — qua database, qua REST/RPC, và qua message-passing — và cách schema evolution ảnh hưởng đến từng mode (Designing Data-Intensive Applications Chương 4)
Breaking Temporal Coupling — Phá Vỡ Sự Phụ Thuộc Theo Thời Gian (Pragmatic Programmer #33)
Cảm nhận về Topic 33 trong chương Concurrency của The Pragmatic Programmer: Temporal Coupling là gì, tại sao nó nguy hiểm và cách break nó để code linh hoạt hơn.
Encoding & Schema Evolution — Thrift, Protobuf, Avro và bài toán tương thích dữ liệu (DDIA)
Binary encoding formats — Thrift, Protocol Buffers, Avro — giúp giải quyết vấn đề gì so với JSON/XML? Làm sao để schema evolution an toàn khi deploy microservices?
Topic 32. Configuration — Đừng Hard-code, Hãy Cấu Hình! (Pragmatic Programmer #32)
Một trong những bài học đắt giá nhất: tách rời code khỏi cấu hình. Học cách viết phần mềm linh hoạt, dễ thay đổi mà không cần sửa code.
OLAP & Column-Oriented Storage — Khi phân tích dữ liệu cần tốc độ (DDIA)
Tìm hiểu sự khác biệt giữa OLTP và OLAP, kiến trúc data warehouse, và cách column-oriented storage tối ưu hoá truy vấn phân tích hàng terabyte dữ liệu (Designing Data-Intensive Applications Chương 3)
Topic 31. Inheritance Tax — Đừng trả 'thuế' kế thừa nữa (Pragmatic Programmer #31)
Inheritance là coupling, và coupling là kẻ thù của sự thay đổi. Tìm hiểu 3 alternatives mạnh mẽ thay thế inheritance từ 'The Pragmatic Programmer'.
Hash Indexes, SSTables, LSM-Trees & B-Trees — Cấu trúc dữ liệu đằng sau storage engine (DDIA)
Khám phá các cấu trúc dữ liệu nền tảng của database: hash indexes, SSTables, LSM-Trees và B-Trees qua lăng kính DDIA
Transforming Programming — Biến Đổi Dữ Liệu Trong Code (Pragmatic Programmer #30)
Cảm nhận về Topic 30 trong The Pragmatic Programmer: cách nhìn lập trình như chuỗi transformation dữ liệu giúp code sạch và dễ maintain hơn.
Graph Data Models — Cypher, SPARQL, Datalog: Ba cách tiếp cận dữ liệu đồ thị (DDIA)
Khám phá ba ngôn ngữ truy vấn đồ thị phổ biến — Cypher của Neo4j, SPARQL của RDF và Datalog — qua lăng kính của cuốn Designing Data-Intensive Applications
Juggling the Real World — Làm sao để code chạy giữa đời thực? (Pragmatic Programmer #29)
Cảm nhận về Topic 29: Juggling the Real World - Bốn chiến lược xử lý sự kiện trong thế giới thực: Finite State Machines, Observer Pattern, Pub/Sub và Reactive Programming.
Data Models & Query Languages — Cách dữ liệu được tổ chức và truy vấn (DDIA)
Relational vs Document models, schema-on-read/write, declarative vs imperative query languages — tóm tắt Chương 2 DDIA của Martin Kleppmann
Decoupling — Tách Biệt Code Để Dễ Thay Đổi (Pragmatic Programmer #28)
Cảm nhận về Topic 28 Decoupling trong chương Bend or Break của sách The Pragmatic Programmer. Học cách viết code linh hoạt, ít phụ thuộc để dễ maintain và mở rộng.
Maintainability & Summary — Ba nguyên tắc để hệ thống dễ bảo trì (DDIA)
Maintainability là trụ cột thứ ba trong Chapter 1 của DDIA — gồm Operability, Simplicity, và Evolvability. Hệ thống không chỉ cần chạy tốt, mà còn phải dễ bảo trì và phát triển lâu dài.
Đừng Chạy Nhanh Hơn Tầm Nhìn Của Mình! — Don't Outrun Your Headlights (Pragmatic Programmer #27)
Pragmatic Programmer Topic 27 — Don't Outrun Your Headlights: bài học về việc chỉ nên tiến xa trong tầm nhìn của mình, lấy feedback làm tốc độ giới hạn.
Reliability & Scalability — Hai trụ cột đầu tiên của Data System (DDIA)
Bài đầu series DDIA: Reliability và Scalability - hai yếu tố nền tảng khi xây dựng hệ thống dữ liệu lớn. Tóm lược chương 1 cuốn Designing Data-Intensive Applications.
Topic 26. How to Balance Resources — Cân Bằng Tài Nguyên (Pragmatic Programmer #26)
Cảm nhận về cách cân bằng tài nguyên trong lập trình từ cuốn The Pragmatic Programmer. Tip thực tế để tránh leak memory, file và các resource khác.
Think Like a Programmer #9 — Chương 8: Tư duy như một lập trình viên — Master Plan của riêng bạn
Kết thúc series cảm nhận 'Think Like a Programmer' của V. Anton Spraul — Chương 8: master plan cá nhân, điểm mạnh/yếu, cheating hangman, và bài học cuối cùng về tư duy lập trình viên.
Topic 25. Assertive Programming — Lập trình quyết đoán (Pragmatic Programmer #25)
Assertive Programming dạy chúng ta đừng bao giờ tin vào câu 'chuyện này không bao giờ xảy ra'. Dùng assertion để ngăn chặn những điều tưởng như impossible — Tip 39 của The Pragmatic Programmer.
Think Like a Programmer — Chương 8: Solving Problems with Code Reuse (Tái sử dụng mã nguồn)
Cảm nhận về Chương 8 sách Think Like a Programmer: nghệ thuật tái sử dụng code, cân bằng giữa NIH syndrome và copy-paste programming, và cách dùng code người khác một cách thông minh.
Dead Programs Tell No Lies — Crash Early, Don’t Trash (Pragmatic Programmer #24)
Topic 24 trong chương Pragmatic Paranoia: Tại sao chương trình chết lại tốt hơn là chương trình 'bị thương' và tiếp tục chạy? Cảm nhận của mình sau khi đọc.
Think Like a Programmer #7 — Đệ quy: Khi hàm gọi lại chính mình
Cảm nhận Chương 6 sách Think Like a Programmer của V. Anton Spraul — Big Recursive Idea, head vs tail recursion, đệ quy với linked list và binary tree.
Topic 23. Design by Contract — Hợp đồng trong code (Pragmatic Programmer #23)
Design by Contract (DBC) là một trong những nguyên lý quan trọng nhất của Pragmatic Programmer — giúp phân định trách nhiệm giữa các module bằng hợp đồng rõ ràng. Preconditions, Postconditions và Class Invariants là nền tảng.
Think Like a Programmer #6 — Lớp đối tượng: Từ code chạy được đến code có kiến trúc
Cảm nhận Chương 5 sách Think Like a Programmer của V. Anton Spraul — class, encapsulation, Rule of Three, interface design, và tư duy thiết kế phần mềm
Engineering Daybooks — Ghi chép hàng ngày cho lập trình viên (Pragmatic Programmer #22)
Tại sao một cuốn sổ tay và cây bút lại là công cụ mạnh mẽ nhất mà một lập trình viên có thể sở hữu? Bài học từ Topic 22 của The Pragmatic Programmer về engineering daybooks.
Think Like a Programmer #5 — Con trỏ và Bộ nhớ Động: Khi "địa chỉ" là chìa khoá
Cảm nhận Chương 4 sách Think Like a Programmer của V. Anton Spraul — con trỏ, bộ nhớ động, linked list, memory leak, và cách tư duy về memory ownership
Text Manipulation — Đừng Viết Code Khi Có Tool Sẵn (Pragmatic Programmer #21)
Cảm nhận về Topic 21 trong The Pragmatic Programmer. Học cách tận dụng sed, awk, Perl để thao tác văn bản hiệu quả thay vì viết code thủ công.
Think Like a Programmer #4 — Solving Problems with Arrays: Khi dữ liệu cần được tổ chức
Cảm nhận Chương 3 sách Think Like a Programmer của V. Anton Spraul: mode, lookup tables, non-scalar arrays, và tư duy tổ chức dữ liệu với array.
Debugging — Tâm lý và cách tiếp cận đúng khi fix bug (Pragmatic Programmer #20)
Cảm nhận về Topic 20 Debugging trong The Pragmatic Programmer. Bình tĩnh thu thập dữ liệu, dùng debugger, và coi bug là cơ hội học hỏi.
Think Like a Programmer #2 — Pure Puzzles: Khi 'bài toán thuần tuý' mới thấy mình yếu ở đâu
Chương 2 của Think Like a Programmer dạy về giải quyết những bài toán 'thuần tuý' — nơi cú pháp đơn giản nhất nhưng tư duy mới là thử thách thật sự.
Version Control — The Basic Tools (Pragmatic Programmer #19)
Cảm nhận về Topic 19 Version Control trong The Pragmatic Programmer. Tại sao version control là công cụ cơ bản quan trọng nhất cho dev.
Think Like a Programmer #1: Strategies for Problem Solving — Bài Học Đầu Tiên Về Tư Duy Giải Quyết Vấn Đề
Mở đầu series cảm nhận 'Think Like a Programmer' của V. Anton Spraul. Chương 1: Strategies for Problem Solving — 8 chiến lược giải quyết vấn đề mà lập trình viên nào cũng cần.
Power Editing — The Pragmatic Programmer #18
Cảm nhận về Topic 18 Power Editing trong cuốn The Pragmatic Programmer. Học cách dùng editor mạnh mẽ để tăng năng suất lập trình.
Think Like a Programmer: Introduction — Tư duy khác biệt giữa học cú pháp và giải quyết vấn đề
Cảm nhận về Introduction sách Think Like a Programmer của V. Anton Spraul: tại sao học cú pháp khác với học giải quyết vấn đề, và cạm bẫy Kobayashi Maru trong lập trình.
🐚 Shell Games — Làm chủ terminal, làm chủ công cụ (Pragmatic Programmer #17)
Shell Games (Topic 17) trong The Pragmatic Programmer so sánh terminal với bàn làm việc của người thợ mộc. Tại sao lập trình viên cần làm chủ command line?
The Power of Plain Text — Sức mạnh của sự đơn giản (Pragmatic Programmer #16)
Topic 16 của The Pragmatic Programmer nói về plain text — thứ tưởng xưa mà hoá ra là vũ khí lợi hại nhất của lập trình viên.
Estimating — Nghệ thuật ước lượng (Pragmatic Programmer #15)
Topic 15 của The Pragmatic Programmer nói về estimating — kỹ năng ước lượng mà dev nào cũng cần rèn. Làm sao để ước lượng trung thực, không biến estimate thành commit.
Domain Languages — Ngôn ngữ của riêng bài toán mình (Pragmatic Programmer #14)
Topic 14 trong series The Pragmatic Programmer: Domain Languages — xây dựng ngôn ngữ nhỏ cho riêng bài toán, giúp code gần gũi với domain hơn và dễ maintain hơn.
Prototypes and Post-it Notes — Học hỏi, không phải để dùng lại (Pragmatic Programmer #13)
Topic 13 trong series The Pragmatic Programmer: Prototypes and Post-it Notes — một trong những topic làm mình suy nghĩ lại rất nhiều về cách mình vẫn thường làm việc. Prototype không chỉ dành cho code, mà còn có thể dùng Post-it Notes để thiết kế UI nữa cơ!
Tuần 5: Good-Enough Software — Khi nào thì "đủ tốt" là đủ?
Tuần 5: Good-Enough Software — phần mềm 'đủ tốt' là gì? Khi nào thì ship, khi nào thì trau chuốt thêm?