From 692b72c68cea15cad4bd63af11732b73121067d1 Mon Sep 17 00:00:00 2001 From: Julien Calixte Date: Wed, 1 Jul 2026 20:00:19 +0200 Subject: [PATCH] docs(adr): record central print service over direct printing --- .../0002-central-print-service-over-direct.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 docs/adr/0002-central-print-service-over-direct.md diff --git a/docs/adr/0002-central-print-service-over-direct.md b/docs/adr/0002-central-print-service-over-direct.md new file mode 100644 index 0000000..f7021e9 --- /dev/null +++ b/docs/adr/0002-central-print-service-over-direct.md @@ -0,0 +1,17 @@ +# Central print service routing to networked label printers + +**Status:** accepted + +Cards reach board printers through a small internal print service: the CLI renders client-side, then POSTs the card image + board-id to the service, which forwards the raster to that board's networked Brother QL-1110NWB by IP. We chose this over direct CLI→printer and over corporate CUPS queues because at 50+ boards the dominant cost is operational — a board→printer registry, retries, and "did it print / is it out of labels" visibility — which a central router provides and 50 hand-configured connections do not (serves G2/F4). + +## Considered options + +- **Direct-to-printer (T-A).** No server, but 50 addresses to track, cross-floor reachability issues, and no central status. +- **Central service (T-B, chosen).** One registry + `--board` routing + status; also the future home of the F5 short-link redirector. +- **Corporate CUPS (T-C).** Reuses IT ops, but label media/routing is awkward in generic queues and couples the project to IT's roadmap. + +## Consequences + +- The service is a single point of failure: if it is down, printing stalls. Mitigation (watched, not built for v1): keep it simple/HA and let the CLI cache the registry to fall back to direct-print. +- Printers must be networked (QL-1110NWB) rather than USB-only — slightly pricier per unit, but avoids a Raspberry Pi agent (and its patching burden) on every board. +- Rendering stays client-side; the service is a thin router, not a renderer.