pyparsing’s backtracking was the latency ceiling (~3.2k parses/sec). How we identified it, built a hand-written recursive-descent parser with pyparsing as a live parity check, and caught 22 edge cases along the way.
The Rust card store held 96k printings, each owning its own heap-allocated strings — even though ‘Forest’ appears 130 times with the same set name and ‘Shock’ has the same oracle text across every printing. Replacing each unique string with a u32 ID cut the archived card data from 107 MB to 47 MB and the build-time heap from 205 MB to 145 MB.
Swapping cachetools for cachebox (a Rust-backed Python cache) required only a thin key-hashing compatibility wrapper. TTLCache operations went from 537 ns/op to 90 ns/op — a 6× gain for a one-line dependency change.
Why id:gruul was doing a full table scan and how encoding color identity as a 5-bit integer—twice, once in SQL and once in the Rust engine—fixed it with arithmetic that fits in a single CPU instruction.
Card search moved from PostgreSQL into a Rust extension via PyO3. The 76× speedup came not from clever SQL tuning but from eliminating the database round-trip entirely — and from hitting a ceiling that Python itself could not clear.
Ten worker processes share a port. A write that clears the cache on one worker leaves the other nine serving stale results. Fixed with a shared multiprocessing.Value generation counter checked on every request.
The /random_search endpoint ran two full-table queries on every request. A 10-minute TTL cache materialized the 30k preferred-printing list once; individual requests then did an in-memory sample. Zero DB round-trips on the hot path.
Serving card images via CloudFront with responsive srcset, native lazy loading, and a sync script that uses Python set subtraction to find exactly which images are missing.
Two SQL hypotheses about DISTINCT ON key choice: UUID vs text, and whether DISTINCT ON the primary key does any real work. One hypothesis failed; two wins shipped.
ILIKE on a trigram-indexed column was spending ~40ms in the query planner for every ~3ms of execution. The fix was two lines of SQL and one line of Python — but finding it required understanding what the planner actually does with ILIKE.