Latest — Page 2
42Notes, systems write-ups and journal — one stream, newest first.
- Note7 sections
Idempotency: When the Same Message Arrives Twice
At-least-once delivery means a handler will see the same message twice. The idempotency key, where it comes from, and the dedupe that survives a crash
- Journal5 sections
AI Didn't Remove the Bottleneck — It Moved It
Cheap code production doesn't raise throughput if review and integration can't keep up. The bottleneck moves downstream — that's where the work is
- Journal6 sections
Flaky Tests: Retrying Isn't a Fix
AI made writing tests nearly free, and flaky suites exploded. Why retry and quarantine are a treadmill, and what catches flakiness deterministically
- Journal5 sections
Schema Evolution Without Breaking the Contract
You can't change a cross-service contract atomically. The rule: additive is safe, a breaking change needs a new identity — consumers upgrade first
- Journal4 sections
Can You Ship Vibe-Coded Software to Production?
Vibe coding lowers the cost of a first version, not the cost of being wrong. That bill arrives in production, not at build time.
- Journal5 sections
Layered Architecture or Clean Architecture?
Why the classic layered structure is enough for most projects while we drown in abstraction layers, and when Clean Architecture actually pays off.
- Journal5 sections
The Production Cost of "Just-in-Case" Code
Applying YAGNI in practice: the price of adding flexibility you don't need today, repaid daily in maintenance, readability, and bug surface
- System10 sections
Race Conditions and Gaps in Sequential Numbering
Generating legally sequential, gap-free numbers with parallel workers: the JIT reservation pattern that solves race conditions and gaps together
- Journal5 sections
When I Move to Microservices
The measured signals that justify moving from a monolith to a distributed architecture — and the common false reasons that say it's still too early
- Journal8 sections
Gitflow or GitHub Flow? How I Choose
Practical criteria for picking a branching strategy by product model, version count, and deploy rhythm — and how each model breaks in the wrong place.
- Journal8 sections
When I Switch to Trunk-Based Development
Why release branches break for high-frequency deploy teams and how much of trunk-based is really discipline — the thresholds I cross and the ones I don't
- Journal5 sections
Why I Start Projects With a Modular Monolith
The case for drawing clean module boundaries inside a single deployable app before jumping to microservices — and when I stop doing it.
- System9 sections
Scale Breaking Points in Data-Intensive Systems
As data load grows, where does boring architecture break? Working set, read replicas, partitioning, write load, a separate data layer — in order.
- Journal7 sections
Why I Prefer Boring Architecture
The pragmatic case for choosing proven tools over chasing new technology. This is not cowardice, it is a budget decision.
- Note5 sections
Namespace Isolation for a Shared Redis
The pattern I use to avoid key collisions and accidental deletes when a single Redis instance is shared across several projects
- Journal8 sections
My AI-Assisted Engineering Workflow
The seven rules I follow to use Claude Code and similar agents on production code with confidence — not a skeptical take, a discipline manifesto
- Note6 sections
A PostgreSQL Backup Strategy with pgBackRest
pg_dump alone is not a backup. A PITR-capable, compressed, verifiable backup architecture with pgBackRest.
- Note6 sections
Why Do Laravel Queues Slow Down in Production?
Laravel queue workers are flawless locally and slow in production. The five most common reasons developers overlook.
- System11 sections
Multiple Projects on a Single VPS
One VPS, several independent apps. Deliberate minimalism over Kubernetes: user isolation, separate PHP-FPM pools, shared PostgreSQL/Redis, a plain deploy.
- Note6 sections
Nginx + PHP-FPM Pool Separation
The concrete benefits of defining a separate pool per application instead of a single PHP-FPM pool when running multiple PHP apps on one VPS
Elsewhere
My main software blog
sade.dev keeps the architecture notes and the production lessons. The rest of software — languages, tools, practice, teams — lives on the main blog.