Welcome to WhyBit

Fortex in this series is a fictional setting; Tom and Ben are characters. The technical experiments have their own code, measurements, and evidence. A scene is not a claim that the same incident occurred in production.

The chair beside Tom

On his first day at Fortex, Ben wanted a task he could finish quickly. He learned frameworks fast, read code fast, and liked turning a ticket into a pull request before the afternoon was over.

Tom reviewed his backend work. Ben expected a list of mistakes. Instead, Tom read the code, asked what he was trying to achieve, and pulled up a chair.

“Walk me through why you chose this.”

Ben spoke quickly. His reasoning made sense: deleting data should shrink a file; an index should make a query faster; a timed-out request should be retried. These weren't foolish ideas. They were missing a condition, a concurrent caller, or a gap between two commits.

Tom didn't know every answer in advance. Experience helped him spot risks, but it could also make him reach a conclusion too early. When measurements disagreed, he revised it in front of Ben. What he wanted to teach was how to find out why, including when he was the person who needed to change his mind.

Read it as a journey

The fictional Fortex builds sales and operational services for merchant partners. An older service uses MySQL; the newer features in this stretch use PostgreSQL and Redis. Each article identifies its engine, version, and actual lab components. An outbox experiment using Redis Streams does not establish Kafka behavior.

The technical topics can be read independently. To follow Ben's development, take this route:

1. Deleted rows, unchanged file. Ben separates what a query can see from what storage retains.
2. An index and a Seq Scan. He starts counting work and learns that a speed claim needs more evidence.
3. A read-only transaction retaining history. He examines resource lifetimes rather than individual statements.
4. Two concurrent stock decrements. Successful SQL stops being enough to convince him that the business result is correct.
5. One expired key, a crowd of loaders. Ben distinguishes reducing duplicate work from protecting correctness.
6. An order committed, an event missing. He follows commit boundaries and learns to preserve intent.
7. A missing tenant filter. He asks who enforces a policy and where trusted identity comes from.
8. Timeouts, retries, and one intent. Tom brings the problem; Ben leads the design and states the evidence's limits himself.

The complete article list still runs from newest publication to oldest. Chapter order is the story's order; rewriting an article doesn't reset its publication date. Each chapter links to its neighbors and has a Vietnamese counterpart, selected in the header.

Their lab bench

Tom and Ben take a hypothesis into a disposable Docker environment. They keep the failing branch, run an alternative, check the final data, and only then discuss a decision. You can download the source or use the article's Docker Lab controls to reproduce it.

Tables and charts refer to a specific run with a report and raw logs. Source commits, digests, and assertions let you inspect the experiment. Verified means that the relevant lab evidence passed within its scope; it does not turn every conversation or production recommendation into an experimental finding.

Some labs check correctness rather than speed. Some use deliberate failpoints rather than real network failures. Those limits appear in the article so you can distinguish what was established from what still needs testing on your workload. Primary sources sit beside the claims they support; reused concepts link back to their earlier WhyBit article.

Ben's notebook

Ben won't become someone who is always right after a chapter. He will still be quick and still like concise solutions. What changes is what he asks before running them: what am I assuming, what data could contradict me, and who pays the cost?

Eventually Tom will hold the marker less often. Ben will draw the failure path, request another check, and explain a decision to the team. Following them is a way to understand systems—and to watch an engineer learn to trust his reasoning while continuing to test it.

Start with the cleanup ticket Ben wanted to close early.