On a server you own, platform overhead is not an abstract number. It shares memory, disk and CPU with the application you wanted to run in the first place.
That is why a feature’s limits are part of its design. A log collector that tries to read everything, or a delivery queue that grows forever, can become the problem it was meant to help investigate.
Add a workflow before adding a system
Hakopod keeps its Go API and reconciler together by default, with PostgreSQL holding accepted operations and history. Newer features follow that existing shape where it fits.
Deployment notifications use a durable outbox. Requests collects managed ingress logs into PostgreSQL. These choices avoid introducing a separate queue service or logging database just to support the first version of a workflow.
Fewer processes do not automatically mean low resource use. Queries, buffers, retained records and concurrency still need limits. “It runs in the existing process” is an architectural fact, not a memory benchmark.
Make the bounds visible
Requests retains at most 24 hours and the newest 100,000 records across an installation. Collection has work and time limits. Notifications have bounded retry attempts, a delivery deadline and a capped pending queue.
Those boundaries have consequences. A busy request log can have a shorter history. Bursts or downtime can leave collection gaps. A full notification queue can skip delivery work instead of blocking the rollout.
An interface should expose these limits where they change the meaning of the data. A count on one page is not the installation’s traffic rate. An empty recent log is not proof that no requests arrived. A queued notification is not proof of delivery.
Decide what you need to retain elsewhere
A bounded operational view is often enough to answer “what just failed?” It is not automatically enough for long-term analysis, compliance or billing.
If your work requires a complete archive, design and verify that separately. Decide the retention period, failure behavior and recovery path before relying on it. Do not turn a short-lived debugging surface into an unofficial ledger by habit.
The same restraint applies to capacity claims. We can describe the processes and the limits they enforce. We should not promise an idle memory footprint for your server without measuring the configuration you actually run.
Read the Requests limits and notification behavior when sizing an installation. A small platform stays manageable by being clear about the work it accepts.