Source Code & Software Architecture
Thiết kế default sao cho fail vẫn an toàn
Một reflection thực tế về cách chọn default bảo vệ user và system khi configuration, rollout hoặc external dependency còn bất định.
Bài viết
Source Code & Software Architecture
Cách tổ chức codebase để hệ thống dễ hiểu, dễ sửa và vẫn đứng vững khi team lớn lên.
Những bài viết thực tế về software architecture và source code structure: từ Ports & Adapters, Clean Architecture đến dependency, module boundary, scaling và trade-off. Mỗi bài cố gắng giải thích bằng sơ đồ, ví dụ gần với đời làm việc, để người mới không bị ngợp và người đã đi làm vẫn có thứ mang về áp dụng.
Source Code & Software Architecture
Giữ data contract đủ nhỏ để tin được
Một reflection thực tế về cách thiết kế data contract hẹp, testable và đủ ổn định để team có thể dựa vào.
Source Code & Software Architecture
Chủ động chọn những boundary nhàm chán
Một reflection thực tế về cách chọn software boundary đơn giản để ownership, testing và future change dễ suy luận hơn.
Source Code & Software Architecture
Thiết kế escape hatch, không phải back door
Một reflection thực tế về cách xây safe operational escape hatch rõ ràng, có audit và có boundary thay vì back door bị giấu.
Source Code & Software Architecture
Làm interface thành thật về giới hạn của system
Một reflection thực tế về cách thiết kế interface cho thấy giới hạn thật của system trước khi user và operator phải tự phát hiện qua failure.
Source Code & Software Architecture
Thiết kế cho thay đổi mình thật sự nhìn thấy
Một reflection thực tế về cách thiết kế phần mềm quanh những pattern thay đổi thật sự visible, thay vì flexibility trừu tượng có thể không bao giờ tới.
Source Code & Software Architecture
Khi boundary cần example hơn là tên gọi
Một reflection thực tế về lý do software boundary rõ hơn khi team neo chúng vào example, responsibility và behavior thay vì chỉ đặt tên layer.
Source Code & Software Architecture
Giữ architecture decision đủ nhỏ để quay lại
Một reflection thực tế về cách giữ architecture decision nhỏ, rõ và có thể quay lại, để team học tiếp mà không biến mọi lựa chọn thành tượng đài vĩnh viễn.
Source Code & Software Architecture
Thiết kế interface sống lâu hơn implementation
Một reflection thực tế về cách thiết kế software interface để behavior ổn định trong khi implementation bên dưới vẫn có thể thay đổi.
Source Code & Software Architecture
Refactor để phần lõi rõ ràng hơn
Một reflection thực tế về refactor phần lõi codebase: cách team giảm coupling, bảo vệ behavior và giúp người đến sau hiểu hệ thống bình tĩnh hơn.
Source Code & Software Architecture
Architecture decision cho teammate tương lai
Một góc nhìn thực tế về architecture decision như team memory: cách những ghi chú ADR nhỏ giúp teammate tương lai hiểu trade-off, option bị từ chối và thời điểm nên revisit.
Source Code & Software Architecture
Chọn boundary trước khi chọn tool
Một góc nhìn thực tế về architecture boundary: vì sao team nên gọi tên ownership, data và pattern thay đổi trước khi chọn framework, service, queue hay database.
Source Code & Software Architecture
Observability là một quyết định thiết kế
Một bài giải thích thực tế về observability như một quyết định kiến trúc: vì sao team nên thiết kế log, metric, trace, dashboard và alert vào hệ thống trước khi production đặt những câu hỏi khó.
Source Code & Software Architecture
Outbox Pattern
Một bài giải thích thực tế về Outbox Pattern: vì sao dual write dễ fail, cách transactional outbox giữ database state và event đi cùng nhau, và những phần team vẫn cần xử lý quanh retry, idempotency, ordering, cleanup và observability.
Source Code & Software Architecture
Service Mesh: Do You Need It?
A practical explanation of service mesh trade-offs: what it centralizes, when it helps, and why teams should solve real service-to-service pain before adopting another infrastructure layer.
Source Code & Software Architecture
Event Sourcing cho người mới bắt đầu
Một bài nhập môn về Event Sourcing: lưu các sự kiện như lịch sử append-only, dựng current state bằng projection, và hiểu khi nào pattern này đáng với chi phí vận hành.
Source Code & Software Architecture
Saga Pattern cho distributed transaction
Một bài giải thích thực tế về Saga pattern trong distributed transaction: vì sao một database transaction không còn đủ khi hệ thống tách service, orchestration và choreography khác nhau thế nào, và vì sao compensation, observability, idempotency lại quan trọng.
Source Code & Software Architecture
API Gateway Patterns
Một góc nhìn thực tế về trách nhiệm của API gateway: routing, authentication boundary, rate limiting, request aggregation, trade-off của backend-for-frontend, failure mode và observability cần có để vận hành edge của hệ thống rõ ràng hơn.
Source Code & Software Architecture
Áp dụng Hexagonal Architecture vào một feature nhỏ
Một hướng dẫn thực tế về cách áp dụng Hexagonal Architecture cho một feature nhỏ: vẽ boundary, đặt tên port bằng ngôn ngữ business, giữ adapter ở rìa hệ thống, test phần core, và biết khi nào pattern này đáng với chi phí của nó.
Source Code & Software Architecture
Event-Driven Architecture: khi service bớt gọi trực tiếp và hệ thống dễ thở hơn
Khi service nào cũng gọi trực tiếp service khác, một dependency chậm có thể kéo cả checkout đi xuống. Bài này giải thích event-driven architecture bằng cách gần gũi: khi nào nên dùng sync hay async, command khác event ra sao, message broker thật sự bảo đảm điều gì, choreography và orchestration khác nhau thế nào, và lúc nào events chỉ làm hệ thống rối hơn.
Source Code & Software Architecture
Database-per-Service, Saga và Eventual Consistency: dữ liệu sống thế nào trong distributed systems
Tách code thường dễ hơn tách dữ liệu. Khi mỗi service cần sở hữu dữ liệu riêng, team phải đối mặt với shared database, eventual consistency, dual-write bug, outbox, saga, CQRS và event sourcing. Bài này đi qua những lựa chọn đó bằng ví dụ thực tế, để bạn hiểu trade-off trước khi hệ thống phân tán bắt đầu làm mọi thứ khó hơn.
Source Code & Software Architecture
Timeout, Retry, Circuit Breaker và Idempotency: bộ kỹ năng sống còn của distributed systems
Một lời gọi ra khỏi process có thể chậm, lỗi, timeout, hoặc chạy hai lần. Đó không phải chuyện hiếm, mà là đời sống bình thường của distributed systems. Bài này gom lại những kỹ thuật giúp hệ thống bền hơn: timeout, retry với backoff và jitter, idempotency, circuit breaker, bulkhead, graceful degradation và observability.
Source Code & Software Architecture
Scale database theo đúng thứ tự: Index, Read Replica, Cache rồi mới tới Sharding
Khi traffic tăng, database thường là nơi kêu cứu đầu tiên. Nhưng không phải cứ chậm là lao vào sharding. Bài này đưa ra một nấc thang thực tế để scale data layer: đo trước, thêm index, dùng read replica, cache đúng chỗ, hiểu replication lag và chỉ đụng tới partitioning hoặc sharding khi thật sự đã đến lúc.
Source Code & Software Architecture
Observability ở quy mô lớn: Logs, Metrics, Traces và SLO giúp mình thấy gì
Khi một request đi qua nhiều service, không còn một log file duy nhất để kể toàn bộ câu chuyện. Bài này giải thích observability theo cách dễ nắm: metrics cho biết hệ thống đang khỏe hay không, logs kể chuyện chi tiết, traces nối các bước lại với nhau, còn SLO giúp team nói về reliability bằng một ngôn ngữ rõ ràng hơn.
Source Code & Software Architecture
Chi phí thật sự của Microservices
Microservices có thể tạo quyền tự chủ thật cho team, nhưng chuyển chi phí sang vận hành, dữ liệu, observability, testing và phối hợp. Bài viết hỏi khi nào cái giá đó đáng trả, và khi nào modular monolith tử tế hơn.
Source Code & Software Architecture
Ports & Adapters: Hexagonal Architecture giải thích bằng ví dụ dễ hiểu
Ports & Adapters nghe có vẻ học thuật, nhưng ý tưởng cốt lõi rất thực tế: business logic nên đứng vững dù database, UI hay API bên ngoài thay đổi. Bài này giải thích port, adapter và dependency direction bằng ví dụ gần gũi, để bạn biết áp dụng vừa đủ cho dự án nhỏ lẫn codebase lớn.
Source Code & Software Architecture
Clean, Onion và Hexagonal Architecture: ba tên gọi cho cùng một hướng nghĩ
Clean Architecture, Onion Architecture và Hexagonal Architecture thường bị xem như ba trường phái khác nhau. Thực ra chúng cùng nhắc về một điều: domain và business rule nên nằm ở trung tâm, framework và chi tiết kỹ thuật ở ngoài rìa. Bài này so sánh nhẹ nhàng để bạn chọn cách gọi và cách vẽ phù hợp với team.
Source Code & Software Architecture
Dependency Injection & Inversion of Control: bớt coupling mà không cần phép thuật
DI và IoC không phải phép màu của framework. Ý tưởng đơn giản hơn nhiều: đừng để một class tự tạo mọi dependency mà nó cần; hãy đưa dependency từ bên ngoài vào. Bài này giải thích vì sao cách làm đó giúp code dễ test hơn, dễ thay đổi hơn và đỡ dính chặt vào database, SDK hay service cụ thể.
Source Code & Software Architecture
Tổ chức codebase: theo layer, feature hay domain?
Một codebase bắt đầu lớn lên từ những lựa chọn rất nhỏ: thư mục trên cùng nên là controllers/services/models, hay orders/billing/auth? Bài này so sánh cách tổ chức theo layer, theo feature và theo domain, chỉ ra mỗi kiểu hợp với giai đoạn nào, và vì sao cấu trúc thư mục thật ra đang kể cách team suy nghĩ về sản phẩm.
Source Code & Software Architecture
Monolith, Modular Monolith hay Microservices: chọn theo giai đoạn, không theo trend
Microservices không phải điểm xuất phát bắt buộc, mà thường là cái giá phải trả khi team và hệ thống đã đủ lớn. Bài này đi qua hành trình từ monolith, modular monolith đến microservices, với các dấu hiệu thực tế giúp bạn biết khi nào nên tách, khi nào nên giữ lại, và khi nào chỉ đang đổi sự đơn giản lấy thêm vận hành.
Source Code & Software Architecture
Micro-Frontends: khi nào đáng tách, khi nào chỉ thêm rối
Micro-frontends có thể giúp nhiều team deploy độc lập hơn, nhưng cũng mang theo chi phí về routing, shared dependency, design system, performance và ownership. Bài này nhìn micro-frontends từ kinh nghiệm thực tế, để bạn biết khi nào nó giải phóng team, và khi nào nó chỉ biến frontend thành một distributed system khó chăm hơn.
Source Code & Software Architecture
Layered và Vertical Slice Architecture
Layered architecture dễ nhận ra và dễ dạy; vertical slice giữ thay đổi gần với feature người dùng chạm vào. Bài viết so sánh hai cách qua những thay đổi code hằng ngày và trade-off về boundary.
Source Code & Software Architecture
Dependency direction bằng ngôn ngữ đời thường
Dependency direction là một quy tắc đơn giản giúp team thống nhất: business rule ổn định không nên phụ thuộc vào chi tiết delivery dễ đổi. Bài viết dùng một tình huống release nhỏ để giải thích vì sao hướng phụ thuộc giúp code, review và trao đổi trong team bình tĩnh hơn.
Source Code & Software Architecture
Eventual Consistency trong đời thật
Một bài giải thích thực tế về eventual consistency ngoài định nghĩa sách vở: người dùng thật sự thấy gì, team đang đổi lấy điều gì, product nên đặt kỳ vọng ra sao, và vận hành phải làm gì để sự thật đến trễ không biến thành dữ liệu lệch âm thầm.
Source Code & Software Architecture
CQRS: tách phần ghi và phần đọc cho đúng việc
Một bài giải thích thực tế về CQRS: tách command khỏi query, khi nào read model và write model nên có hình dạng khác nhau, và cách tránh biến một pattern hữu ích thành kiến trúc thừa.
Source Code & Software Architecture
Serverless: những trade-off và sự thật cần nhìn thẳng
Một góc nhìn thực tế về serverless architecture: team được gì khi giao bớt infrastructure cho managed platform, vẫn phải sở hữu phần nào, và khi nào function, queue, managed service là một lựa chọn hợp lý.
Source Code & Software Architecture
Caching: chiến lược và những cái bẫy dễ gặp
Một bài giải thích thực tế về caching: cache giúp ở đâu, cache-aside, read-through, write-through, TTL và invalidation khác nhau thế nào, và vì sao stale data, cache stampede, key design cùng observability quan trọng không kém tốc độ.
Source Code & Software Architecture
Database sharding: khi nào cần và vì sao
Một bài giải thích thực tế về database sharding: điều gì thay đổi khi một database được chia thành nhiều partition nhỏ hơn, khi nào sharding đáng với chi phí vận hành, và vì sao shard key, hotspot, rebalancing cùng observability rất quan trọng.
Source Code & Software Architecture
GraphQL và REST
Một bài so sánh thực tế giữa GraphQL và REST: mỗi cách định hình API contract, độ linh hoạt cho frontend, caching, observability, ownership trong team và trade-off vận hành khi chọn một phong cách API.
Source Code & Software Architecture
Thiết kế idempotent API
Một bài giải thích thực tế về idempotent API design: vì sao retry luôn xảy ra, duplicate request tạo rủi ro thế nào, và cách idempotency key, state transition ổn định cùng response contract rõ ràng làm distributed system bình tĩnh hơn.
Source Code & Software Architecture
Rate limiting và throttling
Một bài giải thích thực tế về rate limiting và throttling: cách hệ thống bảo vệ capacity chung, điều tiết traffic, giao tiếp limit rõ ràng và ngăn overload biến thành outage.