AI & The FutureWhen an AI Answer Needs a TestA calm explainer on treating AI answers as claims that need proportionate verification. The article shows how engineers can keep responsibility by testing AI output against evidence, context, and real system behavior before acting on it.Apr 15, 2026·7 min read
Perspectives & Field NotesWhy Preparation Often Looks InvisiblePreparation often looks like nothing from the outside: a quiet note, a rehearsal, a cleaned-up checklist, or one small risk handled before it becomes visible. This reflection looks at why calm outcomes usually come from work people do not see.Apr 14, 2026·5 min read
Ways of WorkingThe Daily Standup That Changes DecisionsA practical companion to the daily standup conversation, focused on the small decisions a team should make before the day starts: what to finish, what to defer, what to escalate, and where help would change the outcome.Apr 13, 2026·6 min read
AI & The FutureKhi AI chạm vào việc hằng ngày, ý tưởng bắt đầu nở raKhi AI đủ thực tế để bước vào những việc nhỏ trong văn phòng, ý tưởng không còn nằm ở các bản demo xa xôi. Chúng xuất hiện ngay trong onboarding, hỗ trợ khách hàng, đối chiếu tài chính, chuẩn bị họp, đọc tin tức, kiểm tra tài liệu và rất nhiều workflow lặp lại khác. Bài viết là một góc nhìn bình tĩnh về cách nhận ra các điểm nghẽn ấy, cải tiến từng chút và giữ con người ở phần phán đoán quan trọng.Apr 12, 2026·7 min read
Source & ArchitectureEvents, Queues, and the Art of Not Calling Each Other: Event-Driven Architecture, ExplainedWhen services hold hands through synchronous calls, latency adds up and one slow dependency takes down checkout. A no-hype guide to event-driven architecture: sync vs async, commands vs events, what brokers really promise (at-least-once, not exactly-once), choreography vs orchestration, and exactly when NOT to reach for events.Apr 11, 2026·13 min read
Source & ArchitectureWho Owns the Data? Database-per-Service, Sagas, and Eventual Consistency Without TearsSplitting 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.Apr 10, 2026·13 min read
Source & ArchitectureThe Distributed-Systems Tax, Paid: Timeouts, Retries, Circuit Breakers, and IdempotencyThe 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.Apr 9, 2026·13 min read
Source & ArchitectureScaling the Database: Indexes, Read Replicas, Caching, and Sharding — In That OrderThe 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.Apr 8, 2026·14 min read
Source & ArchitectureYou Can't Fix What You Can't See: Logs, Metrics, Traces, and SLOs at ScaleIn 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.Apr 7, 2026·14 min read