Daniel Collins

This is one of those bugs that can be surprisingly hard to track down, because the code looks correct at first glance. The key point here is to check the raw request, not just what the framework reports — proxies, middleware, and duplicate set calls can all add a second copy before the request reaches the server. Logging the headers at each step, and comparing what the client sent with what the server received, usually narrows it down quickly. It is also worth checking whether the header is being set in more than one place, such as both application code and a server configuration.

This is a really useful framework, especially the first step. Too many database choices start with the technology rather than the workload, and that is where projects get into trouble later. Writing down the real query patterns, data volume, and constraints such as compliance or caching limits makes the trade-offs much clearer. I also liked the point about simulating at production volume before committing — a trial that only uses small test data can hide the exact problems that appear later. The zero-downtime cutover approach is a good reminder that migration planning matters just as much as the choice itself.

This is a useful reminder that caching is often treating the symptom rather than the cause. I have seen a slow endpoint get faster with Redis, only for the same slow query to show up again as soon as the cache missed or the data grew. I agree with Rishabh about keyset pagination too — Skip and Take feel harmless in development with a few hundred rows, then the offset cost grows with every page. Checking the query plan and looking for N+1 queries before adding a cache has saved me a lot of time. The other question I now ask first is how fresh the data needs to be. If the answer is seconds, a cache with a short lifetime can work well. If it needs to be exact, fixing the query or adding the right index is usually the better investment than managing invalidation later. Thanks for the practical framing.

This is a really clear explanation of a trap I have seen catch people in production. The key point for me is that NULL means unknown, not empty, so two NULLs are not equal to each other and a UNIQUE constraint does not stop them. One practical addition: the behaviour is not the same everywhere, so it is worth testing on the database you actually use. PostgreSQL 15 and later gives you NULLS NOT DISTINCT when you really do want only one NULL, while SQL Server treats NULL as a value in a unique constraint and allows only one. In older setups, a partial unique index that only applies where the column is not NULL can be a cleaner fix than adding a sentinel value. I also agree with the point about composite keys — that is where this bites hardest, because one NULL in the combination can quietly let duplicates through. Checking for existing duplicates before adding the constraint, as part of the migration, has saved me from a failed deploy more than once. Thanks for writing this up so plainly.