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분 읽기