コンテンツにスキップ
#0084
SqliteContainers

Fifty workers, one source of truth, one URL

You're running fifty containers that scrape product pages: one container per merchant, all coordinating through shared state. They need to know which URLs have been done, which are in flight, which have failed.

In Redis-land, you'd run a Redis cluster, plumb a client into every container, and pray on the network partition story. In Postgres-land, you'd run a Postgres instance, manage connection pools, and watch fifty containers each open ten connections.

You don't. The shared state is a SQLite file in /hoody/databases/work_queue.db. Each worker pops a row and updates it. The FUSE mount serializes the writes; nothing corrupts. New workers join by reading the URL: no service discovery, no client config.

When a worker dies, you restart its container. It picks up the next row. The state was never on the worker.

The shared state has a URL. The workers have HTTP. That's the whole architecture.