Ask HN: So many patterns I know only in theory
I know about the outbox pattern, the rate limiting pattern, CDC, idempotent consumers, main/replica setup, circuit breakers, caching, sharding, partitioning, and a large etc. I know them well enough to pass technical interviews in which I'm asked about them, and I know them well enough to work in an environment in which these solutions have already been implemented and one only needs to be aware of them.
But I have never implemented such a solution in a production environment. Over a decade of experience. I have played around with these topics at personal projects, ofc, but never a single time i have deployed my own solution to a prod. environment. In very small companies, these patterns are typically not needed. In big/medium-size companies, they are already typically implemented.
What about you?
Comments
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.