Many though not all of these patterns are useful even in a small company.

I’m on a tiny team building an application that’s unlikely to ever average more than a handful or two of concurrent active users.

We’re using DB replicas for redundancy and failover and may eventually use the read replica to remove load off the primary. We’re using caching (which comes almost “for free” with our framework) to save slow/resource-intensive expensive DB and third-party API queries for lookups against rarely changing data sets.

We run background jobs and need at-least-once processing, which means consumers must be idempotent; not to mention idempotent handling of webhooks from one of our vendors. In fact, I can’t think of a small company I’ve worked at beyond proof of concept stage that hasn’t needed idempotence and benefitted from caching some things.

My last small company dealt with high volume and needed rate limiting and outboxes. In other highish volume contexts I’ve pre-computed expensive data structures (idempotently) and cached them in a document database.

Next time you’re at a small company might be a time to look around and ask yourself if any of these patterns is needed or would improve your software’s reliability or performance.

They are baked in to the libraries, frameworks, and services I have used throughout my 15 year career. In a practical sense, I can diagnose issues and point to them as potential solutions. I would not I really know them in the sense I could speak to a lot of them off the top of my head. I probably should be able to do so (if nothing else to impress the types of people who hire developers), but I do not find the inner workings of production-grade web development particularly interesting, at least not anymore.

[flagged]