Every year a client asks why we are not putting a message broker, a search cluster and a document store into their architecture diagram. The answer is that they have four thousand users and one engineer who will inherit this system.
One database, four jobs
Postgres handles our queues, our full-text search, our scheduled jobs and most of our caching. Not because it is the best tool for each individually, but because it is one thing to back up, one thing to monitor and one thing to reason about at three in the morning.
- Queues — a table plus SKIP LOCKED goes remarkably far
- Search — tsvector covers most product catalogues
- Scheduling — pg_cron rather than a separate scheduler
- Caching — materialised views before Redis
Every additional piece of infrastructure is a thing that can be down at two in the morning while you are asleep.
When we do split it out
We move things out when we have measured a reason to. Haulr's route optimisation genuinely needed a dedicated worker fleet. Kapeko's ordering app did not, and still does not at eighty-two thousand orders a month.
The test we apply is simple: can the client's own team operate this after we leave? If not, it does not go in.
0 comments