RN-018
🍜 Food & Restaurants
Splitting a god-module without a big-bang rewrite
A billing module doing three jobs at once, and the branch-by-abstraction path we used to take it apart one seam at a time.
Relev3nNOTES
Vol. 07 — Issue Log
// engineering log — updated continuously
Notes from the build, not the whiteboard.
A running log of what actually happened when we refactored, tested, shipped and occasionally broke real systems — written down before we forget the details.
Log summary
- Entries logged
- 18
- Categories
- 06
- Current volume
- 07
- Status
- Active
Advertisement
728 × 90 leaderboard — AdSense unit placeholder
RN-017
✈️ Travel & Experiences
Characterization tests: locking in behavior before you touch it
Why we write tests against what the code actually does before we change it — not what we wish it did.
RN-016
🏃 Health & Wellness
Branch by abstraction, six months later
A retrospective on the slowest part of a six-month migration — and it wasn't the code.
RN-015
🚗 Rides, Cars & Road Trips
The N+1 query we didn't see coming
A "readable" refactor turned one join into a loop — here's the query-count test we added so it can't happen quietly again.
RN-014
💻 Technology & Useful Digital Life
Feature flags are a liability if nobody deletes them
Why every flag we ship now gets an owner and a removal date at creation time, not as a future cleanup task.
RN-013
Culture
Why our postmortems stopped naming names
A small template change that made incident reviews more honest, not less accountable.
Advertisement
In-feed native unit — AdSense placeholder
RN-012🍜 Food & Restaurants
Strangler pattern for a 40k-line billing service
Route by route, over eighteen months — how we replaced a service too big to characterize and too critical to pause.
RN-011✈️ Travel & Experiences
Flaky tests are a signal, not an annoyance
What we found when we stopped quarantining flaky tests and started reading them instead.
RN-010🏃Health & Wellness
The seam we should have found sooner
The cleanest place to introduce an interface was already sitting in the codebase — we just weren't looking there first.
RN-009🚗 Rides, Cars & Road Trips
Cold starts: what actually moved the needle
We guessed wrong about which optimizations would matter — here's what actually moved the number and what didn't.
RN-008💻 Technology & Useful Digital Life
Linting rules nobody reads, including us
Ninety-plus lint rules, a third with no one left who could explain them — how we audited and cut the list down.
RN-007Culture
Code review as a teaching tool, not a gate
Splitting "must fix" from "worth knowing" in every review comment changed what people learned, not just what merged.
RN-006🍜 Food & Restaurants
Parallel run: proving the new path before the cutover
Three weeks of logging divergences between old and new pricing logic before we let the new path touch a real charge.
RN-005✈️ Travel & Experiences
Contract tests at the seams that keep drifting
Boring on purpose: the contract tests we add at every seam to catch two sides silently drifting apart.
RN-004🏃Health & Wellness
Modules that own their data, not just their code
Our module boundaries kept dissolving until we drew them around data ownership first and code second.
RN-003🚗 Rides, Cars & Road Trips
Latency budgets, and who owns them
A budget nobody owned drifted for two quarters — splitting it across the request path made regressions traceable again.
RN-002💻 Technology & Useful Digital Life
Migration scripts as first-class, reviewed code
After one bad migration, every schema change now goes through the same review and dry-run as application code.
RN-001Culture
The first note we ever logged
How a private "don't relearn this the hard way" file turned into the log you're reading now.
No notes match that search. Try a different term or clear the filters.
// colophon
What this log actually is
Relev3n Notes isn't a polished engineering blog. It's the log a team keeps so the next refactor, migration or incident doesn't start from zero. Every entry comes from a real change, written down close enough to the event that the details are still true.
We publish the parts that generalize — the sequencing, the tests that caught something, the assumption that turned out wrong — and leave out anything specific to our own stack that wouldn't help you.
- Written after, not duringNotes get published once a change has shipped and held for at least two weeks.
- No vendor pitchesNotes describe what we tried and what happened, not a tool we're selling.
- Corrections welcomeIf a note aged badly, we update it in place and say so at the top.
Advertisement
300 × 250 rectangle — AdSense unit placeholder
Get new notes by email
// one email when a new note goes up — no digest, no drip sequence