Latest — Page 2
40Notes, systems write-ups and journal — one stream, newest first.
- 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: Changing a Contract Without Breaking It
A message's data shape is a contract across services you can't change atomically. The rule: additive is safe, a breaking change needs a new identity — and 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 — and it depends on whose hands shipped it.
- 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: JIT Reservation
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 and a separate data layer — the breaking points in order, and what each one costs
- 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
- System13 sections
Laravel Production Stack
A production-grade Laravel setup with Nginx + PHP-FPM + Redis + PostgreSQL + Supervisor + Horizon. Each piece's job and what you lose if you drop it
- Note6 sections
Multiple DB Users with pgBouncer auth_query
A practical setup for dynamic user authentication via `auth_query` instead of `userlist.txt` when running pgBouncer