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.