What we build on, and when we would not

A stack chosen for fashion becomes someone’s migration project two years later. We pick per workload, and we write the reasoning down so the decision can be audited later by whoever inherits it.

The order we actually ask the questions in is: what are the data constraints, what is the failure the system must not have, what volume is this at, and only then which tool. Data residency alone eliminates most of a shortlist before capability is ever discussed, a regulated Indian lender cannot pick from the same set as a consumer app, however good the benchmarks look.

Volume changes the answer again. A workload running a thousand calls a day and one running ten million are different engineering problems with different correct answers, and a tool that is obviously right at one scale is often obviously wrong at the other. That is why almost every production system we ship ends up routing across several of the options below rather than standardising on one.

Each page states what its subject is genuinely strongest at and the trade-off it carries. The trade-off line is the one worth reading. It is the part a vendor’s own documentation will never tell you.