Architecture Decision Records¶
Architecture Decision Records (ADRs) capture significant technical decisions made on the Pricer EVO ESL platform. Each record describes the context that led to the decision, the decision itself, and its consequences — including trade-offs that were accepted.
ADRs are not change logs or design specs. They exist so that future contributors understand why the system is the way it is, and can evaluate whether the original reasoning still applies.
Scope¶
These records cover two overlapping areas:
- DTOflow platform decisions — infrastructure choices affecting how data moves between services (queue configuration, delivery models, LFS file naming, service naming conventions).
- Functional system decisions — DTO design, service responsibilities, lifecycle management, and migration strategies for the ESL domain (links, images, store ESL status, configuration singletons).
Index¶
| ADR | Title | Status | Date | Summary |
|---|---|---|---|---|
| ADR-001 | DTOflow for inter-service data sharing | Accepted | 2025-01 | Services share data via DTOflow + CQS; no direct REST calls between services |
| ADR-002 | Short canonical service names (PLT-2122) | Accepted (in progress) | 2025-06 | Uniform Cloud Run and CQS queue names replace verbose legacy identifiers |
| ADR-003 | link.v2 and ESL image DTO split (PLT-2484) | In Progress | 2026-04 | link.v1 replaced by link.v2; rendering DTOs split by renderer with a merger service |
| ADR-004 | CQS persistent dynamic queue configuration | Accepted | 2026-05 | Dynamic queues stored in registry.json on GCS; services self-provision at startup |
| ADR-005 | CQS static config and push model deprecation | Accepted | 2026-05 | Static queue config and push delivery removed in phased migration to gRPC pull |
| ADR-006 | ESL status as a separate DTO (storeeslstatus) | Accepted | 2026-05 | ESL lifecycle state separated from storeesl into its own child DTO |
| ADR-007 | Content-addressed LFS (hash-named files) | Accepted | 2025-06 | LFS files named by SHA-256 hash of content for deduplication and immutability |
| ADR-008 | Singleton DTOs for per-store configuration | Accepted | 2025-09 | Configuration DTOs are singletons with a fixed ID pattern, one per store |
| ADR-009 | CQS re-enqueue streaming API | Accepted | 2026-06 | Client-streaming RPC to split one notification into many; atomic ack on Footer |
| ADR-010 | Operator trigger APIs for force re-processing | Accepted | 2026-06 | Per-service named RPCs for operator-initiated re-render/re-export; rejects CQS injection and single-hop TouchDto |