コンテンツにスキップ
#0023
PipeContainers

Inter-container IPC without the message broker

Service A produces work. Service B consumes it. They live in different containers. Standard answer: stand up Redis, write a producer, write a consumer, manage credentials, monitor lag.

Hoody answer: A pipes its output to a path. B pulls from the same path. service-a | curl -T - https://.../api/v1/pipe/work, curl https://.../api/v1/pipe/work | service-b. The pipe routes bytes between the two containers in real time. Either side can connect first; the pipe waits five minutes for the counterpart.

When a third service needs the events: a logger, a metrics collector: raise ?n and add a reader. No broker config. No consumer group. The new reader just exists.

The trade-off is honest: the pipe forgets messages once delivered. For durable queueing, this isn't it. For fast fan-out between containers, the broker just disappeared.

The broker is the URL. The URL is the broker.