Single dependency stacks

I&#x27;m a big fan of this approach, having built a Django monolith with the standard Celery&#x2F;RMQ, dabbled in Redis for latency-sensitive things like session caching, and never hitting scale where any of those specialized tools were actually required (despite generating substantial revenue with the company).<p>One thing to note, if you use pq or another Postgres-as-queue approach, you should be aware of the work you&#x27;ll need to do to move off it -- this pattern lets you do exactly-once processing by consuming your tasks in the same DB transaction where you process the side-effects. In general when using a separate task queue (RMQ, SQS, etc.) you need to do idempotent processing (at least once message semantics). A possible exception is if you use Kafka and use transactional event processing, but it&#x27;s not serializable isolation.<p>This is probably a reason in favor of using a Postgres task queue initially since exactly-once is way simpler to build, but just be aware that you&#x27;re going to need to rethink some of your architectural foundation if&#x2F;when you need to move to a higher-throughput queue implementation.

Note that you can approximate rate-limiting in Redis with Postgres&#x27; UNLOGGED tables [0]. They&#x27;re a lot faster than regular tables since they don&#x27;t write to the WAL. Of course, if you restart your server or if it crashes then you lose the table contents. But for stuff like rate-limiting you probably don&#x27;t care. And unless you&#x27;re using some kind of persistence in Redis it happens there also.<p>I tend to run this kind of stuff on a separate PG server so that the query velocity doesn&#x27;t affect more biz-critical things.<p>[0] <a href="https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;sql-createtable.html#SQL-CREATETABLE-UNLOGGED" rel="nofollow">https:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;current&#x2F;sql-createtable.html...</a>

Personally staking my own future on this &quot;less is more&quot; approach having seen some serious horror flicks in terms of app&#x2F;infrastructure stacks the past few years.<p>What continues to surprise me: a lot of time and money has been or is being wasted on reinventing the wheel (speaking specifically about webdev here).<p>There are a ton of great tools out there that are battle-tested (e.g., my favorite find of late as someone just digging into hand-rolled—meaning no k8s&#x2F;docker&#x2F;etc—infrastructure is haproxy).

What other examples are there of &quot;single dependency stacks&quot;?<p>This article is really about the versatility and reliability of postgres.<p>And I&#x27;m all in agreement.<p>Reminiscent of:<p><a href="https:&#x2F;&#x2F;www.craigkerstiens.com&#x2F;2017&#x2F;04&#x2F;30&#x2F;why-postgres-five-years-later&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.craigkerstiens.com&#x2F;2017&#x2F;04&#x2F;30&#x2F;why-postgres-five-...</a><p><a href="https:&#x2F;&#x2F;webapp.io&#x2F;blog&#x2F;postgres-is-the-answer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;webapp.io&#x2F;blog&#x2F;postgres-is-the-answer&#x2F;</a><p><a href="http:&#x2F;&#x2F;rachbelaid.com&#x2F;postgres-full-text-search-is-good-enough&#x2F;" rel="nofollow">http:&#x2F;&#x2F;rachbelaid.com&#x2F;postgres-full-text-search-is-good-enou...</a><p><a href="http:&#x2F;&#x2F;boringtechnology.club&#x2F;" rel="nofollow">http:&#x2F;&#x2F;boringtechnology.club&#x2F;</a><p>As much as HN could lead you astray with the hype of this and that tech, articles like the above are some of the most consistently upvoted on this website.

I think this is the right idea. The pendulum between having as many dependencies as possible and having no dependencies at all has flung way too far in the &#x27;as many dependencies as possible&#x27; side. It is a major PITA when yet another random component breaks. Let us say that A can be done in B in, let us say, three man weeks. I would say it is worth it. The advantage is that A will never break because it is not there. Note that A also may break 3 years from now when everybody who knows anything about A has left the company.... B is now used in more places so people are more likely to have been forced to learn it so when the emulation of A break there is a better chance that people will know what to do. I see mostly advantages.

There&#x27;s definitely potential to go too far into monolith territory and misinterpret how simple your architecture actually is.<p>An example: Django backed by Postgres. I tend to view this as 1 architectural unit, i.e. Postgres is wholly embedded in Django. I am under no illusion that I have <i>both</i> a Django project and a PostgreSQL instance. I have a Django-backed-by-Postgres. I <i>can</i> have that PostgreSQL instance be a standalone interface, but that means increasing my architectural units from 1 to 2. Instead, if I want to integrate with Django&#x27;s raw tables, I&#x27;m going to do it on Django&#x27;s terms (via a custom HTTP API) rather than fighting the ORM over who gets to DBA the database. Bad for performance? No doubt. We&#x27;ll worry about that when we get there.<p>Yes, you can run a web app server directly out of Postgres without an additional &quot;app layer&quot; like Django (Crunchy has some cool tools for this). But should you?<p>To be clear, I&#x27;m a big fan of KISS, just skeptical of false minimalism.

I am so for this, being the sole developer in my company for the last 10 years I introduced far to many “moving parts” as it grew and I’m now going through the process of simplifying it all.<p>I love Redis but it’s next to go, currently used for user sessions and a task queue, both of which Postgres is more than capable of doing [0]. Also, as a mostly Python backend, I want to rip out a couple of Node parts, shrink that Docker image.<p>0: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21536698" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21536698</a>

Apparently Tailscale for a long time just used a JSON file as their data storage, and moved from that to SQLite with a hot-swappable backup with Litestream [0], and hey they&#x27;ve done fine with that.<p>[0]: <a href="https:&#x2F;&#x2F;securitycryptographywhatever.buzzsprout.com&#x2F;1822302&#x2F;9890092-tailscale-feat-avery-pennarun-and-brad-fitzpatrick?t=0" rel="nofollow">https:&#x2F;&#x2F;securitycryptographywhatever.buzzsprout.com&#x2F;1822302&#x2F;...</a>

I kind of love this idea.<p>It reminds me of a redis use case we had at a former employer.<p>We had a cluster with a high double digit number of nodes that delivered a lot of data to various external APIs.<p>Some of those APIs required some metadata along with the payload. That metadata was large enough that it had made sense to cache it in Redis. But over time, with growth the cluster got large enough, and high volume enough that just fetching that data from Redis was saturating the 10Gbps Nic on the ElastiCache instance, creating a significant scaling bottleneck. (I don&#x27;t remember if we moved up to the 25Gbps ones or not.)<p>But we could have just as easily done a local cache (on disk or something) for this metadata on each node and avoided the cost of the ElastiCache and all the scaling and operational issues. It would have also avoided the network round trips to Redis, and the whole thing probably would have just performed better.

This is why I love Ansible. As a DevOps enigneer I do not design or implement complex systems or programs. But I am responsible for the reliability of our systems and infrastructure. And Ansible is just pleasant to use for the same reasons stated by the author:<p>- a single packaged without any additional dependencies - no client side software - pure SSH - simple playbooks written in only YAML<p>Focusing on simplicity and maintainabilty has helped me deliver reliable systems.

Many can even get away with less: sqlite.<p>One less process to worry about.

I have nothing to disagree with here, but it&#x27;s worth noting that his company Crunchy Data are themselves a postgres provider. So they, more then most, have the chops and incentive to do a great deal in postgres alone.<p><a href="https:&#x2F;&#x2F;www.crunchydata.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.crunchydata.com&#x2F;</a>

This article makes me embarrassed. Not that they wrote the article, but that it had to be written.<p>A single web application with a single database is how <i>everything</i> should be built unless necessity demands more complexity.<p>It&#x27;s the way people do things in the &quot;uncool&quot; enterprise world every single day.

There are so many benefits of keeping things as simple as possible.<p><pre><code> - easier troubleshooting - easier to maintain documentation - quicker onboarding of new devs - easier to migrate to new hosting if needed - quicker to add features (or decide not to add)</code></pre>

Zero dependency is better.<p>Your database does not need to be a separate process. It can just be a library embedded in your application.<p>If your application is distributed across several physical servers, then your database can be as well.

&gt; normally I’d push all rate limiting to Redis. Here, we rate limit in memory and assume roughly uniform distribution between server nodes.<p>Dumb question: what do they mean by rate limiting in memory vs via Redis? Does that mean keeping track of request origins+counts using those storage mechanisms, or something else?

This idea is super cool.<p>I am not sure it necessarily has to be just one single dependency, but keeping the number of dependencies as low as possible makes a lot of sense to me. At least the overhead of introducing any given new dependency should be taken into serious consideration and held against the concrete benefits that will be gained from it.<p>I wrote a blog post on a very similar subject, essentially all of the same arguments, but targeted more towards the dependencies and abstractions found within a given systems code structure and application architecture.<p>If you are interested, you can read it here: <a href="https:&#x2F;&#x2F;betterprogramming.pub&#x2F;avoiding-premature-software-abstractions-8ba2e990930a" rel="nofollow">https:&#x2F;&#x2F;betterprogramming.pub&#x2F;avoiding-premature-software-ab...</a>

I’m a big fan of getting rid of the MVC frameworks too. Get down with PostgREST or Postgraphile on your control plane. Use Postgres to manage security, views, migrations, the whole nine yards.<p>On your data plane.. yeah queues on Postgres work too. Subscribe&#x2F;notify are decent. Or go with using a streaming replication client to send out events to a queue and decouple downstream stuff like your analysis datastores, notification systems, policy monitoring, what have you.<p>Postgres can handle a lot. It’s an awesome piece of tech.

&gt; 1 Okay fine, S3 too, but that’s a different animal.<p>I think people forget that AWS S3 isn&#x27;t immutable. Unlike an EBS volume, it is impossible to &quot;snapshot&quot; S3 the way you can a database. There are arbitrary global limitations outside the scope of your control, and a dozen different problems with trying to restore or move or version all the things about buckets that aren&#x27;t objects (although the objects too can be problematic depending on a series of factors).<p>If you want real simplicity&#x2F;repeatability&#x2F;reliability, but have to use S3, host your own internal S3 service. This way you can completely snapshot both the metadata and block devices used by your S3 service, making it actually immutable. Plus you can do things like re-use a bucket name or move it to any region without worrying about global conflicts. (All of that is hard&#x2F;expensive to do, however, so you should just use AWS S3 and be very careful not to use it in a way that is unreliable)

I am sure there is momentary thrill of achieving minimalism but alas the world is not so simple anymore. I would refer the OP and the community here to the paper from the creator of PostgreSQL: <a href="http:&#x2F;&#x2F;cs.brown.edu&#x2F;~ugur&#x2F;fits_all.pdf" rel="nofollow">http:&#x2F;&#x2F;cs.brown.edu&#x2F;~ugur&#x2F;fits_all.pdf</a>

I always start with just MySQL and introduce things as needed - not as guessed. These days I don&#x27;t work on anything with enough traffic that needs more than that.<p>An RDBMS is a lot more than just SQL these days, and they offer a lot of good enough solutions to a wide variety of problems.

I wholeheartedly agree with the author that holding all your state within one system has massive benefits. As soon as you have to make your state cross process boundaries yourself, you are going to have a much more difficult time and are exposing yourself to a much larger problem space.<p>&gt; If we were to need search, we’d use Postgres’ full text search instead of ElasticSearch.<p>I think this is significantly easier said than done, I don’t really consider those two pieces of tech equivalent. Postgres FTS is pretty good, but I don’t think it really can do a lot of the stuff ES can do well.

This is great, but you might want to have multiple postgreses for the different workloads. DB postgres != rate-limit PG != search PG. It&#x27;s pretty hard to optimize one DB for every workload.

The next level up of this approach is running everything on one box.

Redis is overused in my opinion. For many requests it does not beat a database for the same amount of money. There can be other reasons for using a cache though. I often hear that people claim that the cache “protects” the database. From my experience it is more common that once the database has problems it spills over to the cache. If then for instance a circuit breaker opens to the cache the database will be smacked senseless.

I love this concept.<p>For anyone who’s interested in doing this, but doesn’t want to manage the infrastructure you should check out Supabase. (I’m not affiliated, just a fan.)

I love Postgres and mostly agree, but there’s one caveat: Postgres’s full text indexing is better than most non-Lucene options, but it’s still a toy compared to anything using Lucene (eg ElasticSearch). If you need to support indexed search of documents, especially multi-language corpora, you need to use the right tool for the job and Postgres isn’t it.

operationally, makes sense. but the inevitable moment (if you survive) you need to migrate to smth else depending on a different queue system, it&#x27;ll be a pain to retrofit the code relying on db-level transactions and locks.

This is one thing that really appeals to me about postgres - it may not be the best at everything, but it can do it all. Love seeing people actually load testing it <i>before</i> adding another stateful service.

I was a bit disappointed. I though they were going to implement their entire system using stored procedures. That would be “single dependency”. As it stands it is “all my app tier dependencies and postgres.

I was worried about how long the initial indexing would take for a recent full text search implementation in Postgres.<p>Took less than a second on a few hundred thousand rows.<p>Naive and simple is good enough for now.

my take on this looks similar, but I&#x27;ll have more going on:<p>1. kubernetes. 2. postgres. 3. application.<p>where the kubernetes bit is used for the more integration test side of things.<p>a lot of machinery can be employed that gets in the way of &quot;wtf just happened&quot;.

I&#x27;m not sure what qualifies as &quot;stateful&quot;, but<p>&gt; <i>Fewer dependencies to fail and take down the service.</i><p>No logging? No metrics? No monitoring? (&amp; <i>yes</i>, you&#x27;d think those shouldn&#x27;t take down the stack if they went offline. And I&#x27;d agree. And yet, I&#x27;ve witnessed that failure mode multiple times. In one, a call to Sentry was synchronous &amp; a hard-fail, so when Sentry went down, that service 500&#x27;d. In another, syslog couldn&#x27;t push logs out to the logging service, as that was <i>very</i> down, having been inadvertently deleted by someone who ran &quot;terraform apply&quot;, didn&#x27;t read the plan, &amp; then said &quot;make it so&quot;; syslog then responded to the logging service being down by logging that error to a local file. Repeatedly. As fast as it possibly could. Fill the disk. Disk is full. Service fails.)<p>I&#x27;ve also seen our alerting provider have an outage <i>during an outage we&#x27;re having</i> &amp; thus not sending pages for our outage, causing me to ponder and wonder how I&#x27;d just rolled a 1 on the SRE d20 and what god did I anger? Also who watches the watchmen?<p>&gt; <i>A common pitfall is to introduce something like ElasticSearch, only to realize a few months later that no one knows how to run it.</i><p>Yeah I&#x27;ve seen that exact pit fallen into.<p>No DNS? Global Cloudflare outage == fun.<p>No certificates?<p>I&#x27;ve seen certs fail so many different way. Of course not getting renewed, that&#x27;s your table stakes &quot;welcome to certs!&quot; failure mode. Certs get renewed but an <i>allegedly Semver compatible</i> upgrade changed the defaults, and required extensions don&#x27;t get included leading to the client rejecting the cert. I&#x27;ve seen a service which watches certs to make sure they don&#x27;t expire (see the outage earlier in this paragraph!) have an outage (which, b&#x2F;c it&#x27;s monitoring, wasn&#x27;t customer visible) because a tool issued a malformed cert (…by… default…) that the monitor failed to parse (as it was malformed). Oh, and then the LE cross-signing expiration took out an Azure service that wasn&#x27;t ready for it, a service from a third-party of ours that wasn&#x27;t ready for it, <i>and</i> our CI system b&#x2F;c several tools were out of date including <i>an up to date system on Debian that was theoretically &quot;supported&quot;…</i> but still shipped an ancient crypto library riddled with bugs in its path validation.<p>&gt; <i>Okay fine, S3 too, but that’s a different animal.</i><p><i>Is it?</i> I&#x27;ve seen that have outages too, &amp; bring down a service with it. (There really wasn&#x27;t a choice there; S3 was the service&#x27;s backing store, &amp; without it, the service was truly screwed.)<p>But of course, all this is to say I violently agree with the article&#x27;s core point: think carefully about each dependency, as they have a very real production cost.<p>(I&#x27;ve recently been considering changing my title to SRE because I have done very little in the way of SWE recently…)