Decisions
Choosing well is a different skill from knowing a lot. Each page here takes a real fork, commits to an answer, and says plainly what that answer costs.
Anyone can list trade-offs and refuse to conclude. These pages conclude, which is the part that can be wrong, which is the part worth reading.
Why a section for forks rather than problems
A solution page answers somebody who is stuck. A decision page answers somebody who has two workable options and has to pick one this week, usually with a colleague arguing for the other. Those need different writing. The second one is worthless unless it commits.
So each page here states which one I pick, in what circumstances that flips, and what the choice costs on the day it turns out to be wrong. Server sent events against WebSockets is the clearest case: I pick SSE most of the time, the reason is that most realtime requirements are one directional and a full duplex socket is a connection and a reconnection strategy you now own, and the page says exactly when that stops being true.
How to read one of these against your own situation
Skip to the section that says when the other answer wins. That is the useful part if you are already leaning the other way, and it is the part that tells you whether the writer understood the trade or just preferred something.
Every one of these was made on a system that then had to be operated for years, which is a different exercise from choosing on a greenfield project. The cost of a decision usually shows up long after the commit that made it.
Astro against Next for content sites, dogfooded on this one
I rebuilt this site in Astro rather than Next, and the reasoning is a fair test of the decision, because you are reading the result and can check every claim in it.
Queues against cron, and when cron is still the right answer
Replacing cron with a queue is treated as an obvious modernisation. It is a trade, and there are systems where cron is the correct answer and the queue is a liability.
Server sent events against WebSockets, and why I usually pick SSE
WebSockets are the default answer to the word realtime, and most realtime requirements are one directional. The server has something to say, the browser needs to hear it, and nothing goes back the other way.
Postgres against Mongo for multi-tenant systems
This choice gets argued on flexibility and schemas, and both sides are usually arguing about the wrong thing. The question that actually decides it is whether anything in your system has to add up.
Where to start
- The one most teams get wrong
- Cron is a trigger, not an engine. It stays the right answer for a narrower set of cases than people assume, and the page states all three.
- If you are adding realtime
- Most realtime requirements are one directional, and the cheaper option carries reconnection for free.
- Dogfooded
- This site is the worked example, including what the choice costs the moment the site needs anything genuinely interactive.
Common questions
- What if I disagree with one of these?
- Then the page has done its job, because it committed to something specific enough to disagree with. Each one states the conditions under which the other answer is right, so the useful conversation is about whether your conditions match, not about which technology is better in the abstract.
- Do these get updated when the tools change?
- When the reasoning changes, yes, and the page carries the date it was last revised. Where a decision was right at the time and would go the other way now, that is worth saying explicitly rather than quietly editing, because how a decision aged is more informative than the decision.
For problems rather than forks, see solutions .