Nguyen Le PhongNguyen Le Phong
ブログに戻る

記事

ソースコード & アーキテクチャ

成長・チーム・変化を乗り越えられるコードの構成方法。

ソフトウェアアーキテクチャとコードの整理方法について、初心者にも優しい実践的な深掘り記事のシリーズです。Ports & Adapters や Clean Architecture から、依存関係管理・モジュール境界・各パターンのトレードオフまでを取り上げます。図解・実例・個人プロジェクトからエンタープライズシステムまで通用する知見をもとに構成されています。

ソースコード & アーキテクチャ

Scaling the Database: Indexes, Read Replicas, Caching, and Sharding — In That Order

The database is almost always the first thing to buckle under growth — and the first thing engineers over-engineer in a panic. A no-hype ladder for scaling the data layer: why you measure and add an index before touching hardware, how read replicas exploit the read/write asymmetry (and the replication-lag trap they bring), where caching helps and why invalidation is the hard part, and when you finally reach for partitioning and sharding — the one decision that is genuinely hard to undo.

14 分で読めます
ソースコード & アーキテクチャ

You Can't Fix What You Can't See: Logs, Metrics, Traces, and SLOs at Scale

In a monolith, debugging was almost cosy — one log file, one process, one place the truth lived. Distributed systems quietly took that away: one request now fans out across a dozen services, and when it breaks there is no single log to read. A no-hype guide to seeing your system at scale: the three pillars (metrics, logs, traces) and the question each one answers, why a single propagated trace ID is the highest-leverage habit you can adopt, how SLOs turn reliability into an error budget you can spend, and how to alert on symptoms so on-call doesn't burn out.

14 分で読めます
ソースコード & アーキテクチャ

Who Owns the Data? Database-per-Service, Sagas, and Eventual Consistency Without Tears

Splitting code is the easy half — splitting data is where distributed systems humble you. A practical guide to owning data across services: why a shared database is a distributed monolith, the trade from ACID to eventual consistency, the dual-write bug and the outbox that fixes it, sagas with compensating actions, and when CQRS and event sourcing are worth their lifetime cost.

13 分で読めます
ソースコード & アーキテクチャ

The Distributed-Systems Tax, Paid: Timeouts, Retries, Circuit Breakers, and Idempotency

The moment a call leaves your process it can be slow, fail, or happen twice — and that is the normal case, not the exception. The resilience toolkit, explained plainly: why timeouts come first, how retries become a self-inflicted DDoS without backoff and jitter, why idempotency is the price of retrying, and how circuit breakers, bulkheads, graceful degradation, and observability keep one bad dependency from taking down everything.

13 分で読めます
ソースコード & アーキテクチャ

コードベースの構成:レイヤー・フィーチャー・ドメイン、どれを選ぶ?

トップレベルのフォルダーを controllers/services/models にすべきか、orders/billing/auth にすべきか?この選択はコードベースの成長を静かに形作ります。レイヤー別・フィーチャー別・Screaming Architecture を実践的に比較し、会社の規模ごとのトレードオフを解説します。

14 分で読めます
ソースコード & アーキテクチャ

モノリス・Modular Monolith・マイクロサービス:正直な意思決定ガイド

マイクロサービスは組織的スケールのために払う税金であり、出発点ではありません。モノリスから Modular Monolith を経てマイクロサービスへの誇大広告なしのウォークスルーと、いつ(そして本当に)分割すべきかを示すシグナルを解説します。

16 分で読めます
ソースコード & アーキテクチャ

Micro-Frontends:いつ価値があり、何が実際にかかるか

フロントエンドを独立してデプロイ可能なピースに分割することでチームが解放されることも、複雑さに埋もれることもあります。Angular ホスト+ React モジュールをスケールで出荷した経験から:Micro-Frontends が見返りをもたらす場面と、それに伴うコストを正直にお伝えします。

15 分で読めます