Sage.

How my API design changed

At stage 0 I was writing Express routes directly in index.ts with no separation. By Flowbrand I was thinking in modules first — what are the aggregates, where are the boundaries, what does the service layer own versus the controller. NestJS exception filters and interceptors taught me that cross-cutting concerns belong in the pipeline, not scattered across handlers.

Race conditions — shape, not verb

I used to think about race conditions by HTTP verb. Wrong lens. The right question is the operation pattern: read-modify-write, check-then-act, multi-step writes without a transaction, single-use token exchange. PR #84's bug was a GET→DELETE that wasn't atomic. PR #109's bug was three writes that needed a transaction. The verb was incidental both times.

Error handling: catch specific or don't catch

Broad catch clauses that return null convert 5xx infrastructure failures into 4xx client errors. The Redis outage looks like an invalid token. The DB being down looks like a user not found. I learned to only catch the error you expect — EntityNotFoundError, not Error — and let everything else propagate so it surfaces as a 5xx.

Validation belongs at the boundary

Checks that only use request data kept appearing in my service layer. By the time you're in the service you've already paid the cost of the request. If the check needs no async lookup, it belongs in the DTO. Cross-field validation, format checks, enum membership — all DTO work, not service work.

Queue and Redis architecture

Bull stores all jobs in Redis — there's no separate queue server. Understanding this made the whole architecture click: sessions, rate limits, distributed locks, and background jobs all live in the same Redis instance, separated by key naming conventions. The processor architecture taught me that who owns the failure matters — ExtractionProcessor swallows and records, FunnelGenerationProcessor rethrows and lets Bull retry.

The thing I got wrong under pressure

PR #35 shipped at 889 lines across 15 files. The funnel worker, LLM orchestration, fallback chain, and atomic DB writes are at least three logical concerns. I knew that while writing it and merged it anyway because the deadline was real. My lowest score was Collaboration + Docs (6/10). Smaller, stacked PRs are reviewable PRs — that's the one I carry forward.