Skip to content

studio-link-evaluator

Cloud Run / CQS queue name: studio-link-evaluator Legacy name: platform-evaluation-engine (deprecated) Tech stack: Quarkus (GraalVM native image, Java 21), Gradle

studio-link-evaluator is a stateless, CPU-intensive evaluation service that translates high-level communication pack rules into concrete per-ESL rendering instructions. For every ESL that is affected by a change to a communication pack, a link assignment, or item property values, the evaluator fetches the current state of all three inputs, runs the CEL expressions in the active communication pack against the current item properties, selects the winning design ID, and writes a studiolink.v1 DTO. The studiolink is then consumed by studio-renderer to produce the final image. The service is deliberately kept separate from studio-scenario-library because CEL parsing is CPU-heavy and the evaluation path scales at a different rate from the authoring CRUD path.

DTO Ownership

DTO Version Why this service owns it
studiolink v1 Evaluated rendering instruction: links a specific ESL barcode to the resolved design_id (plus item context) determined by running the communication pack scenarios. This DTO is the trigger for studio-renderer.

CQS Subscriptions

DTO Version What the service does when it receives a change
communicationpack v1 A pack change means the scenario rules have been updated. The service re-evaluates every ESL currently assigned to this pack and writes new studiolink DTOs for any whose resolved design has changed.
link v2 A new or updated link means a new ESL–item–design relationship. The service evaluates the applicable communication pack for this ESL against current item values and writes (or deletes) the studiolink.
storeitemvalues v1 Item property values have changed for one or more items in a store. The service identifies which ESLs display those items and re-evaluates their communication pack scenarios; any ESL whose winning design changes gets a new studiolink.

Processing Logic

Inputs: For a given evaluation trigger the service resolves three pieces of state: 1. The active communicationpack.v1 for the relevant store/ESL (fetched from DTOflow by the pack's canonical ID). 2. The current link.v2 assignment (which ESL is showing which item, under which design source variant). 3. The current storeitemvalues.v1 for the linked item in the store (item properties used by CEL expressions).

Evaluation: Scenarios within the communication pack are evaluated in priority order. Each scenario's CEL expression is compiled and executed against the item property map. The first scenario whose expression returns true supplies the winning design_id. If no scenario matches, the pack's fallback design is used. If there is no fallback and no match, any existing studiolink for the ESL is deleted so studio-renderer knows to clear the image.

Output: A studiolink.v1 DTO is written to DTOflow. Its ID follows the pattern t/{tenantid}/s/{storeid}/esls/{barcode}/studiolink. The DTO carries the resolved design_id, the source link_id, the barcode, and enough item context for the renderer to skip a redundant DTOflow lookup.

Heavy fan-out via re-enqueue: A communicationpack.v1 change can imply re-evaluating every ESL bound to that pack across a tenant. Rather than evaluate them all under one ack lease, the evaluator returns the notification via ReEnqueue, first as per-store parent_id notifications and then, on dequeueing each per-store one, as per-link dto_id notifications. Urgent single-link re-evaluations continue to dequeue in priority order while the bulk job is broken down.

Stateless scaling: The service holds no local state between evaluations. All inputs are fetched from DTOflow at evaluation time. This means the service can scale to zero and back instantly, and multiple replicas can process different ESLs in parallel without coordination. Scaling is driven by CQS queue depth, independent of studio-scenario-library's replica count.

Native image: Same GraalVM native-image constraints as studio-scenario-library apply (gRPC Netty and Vert.x PooledByteBufAllocator classes require runtime initialisation).

  • studio-scenario-library — produces the communicationpack.v1 DTOs this service evaluates
  • link-registry — produces the link.v2 DTOs that trigger per-ESL evaluation
  • studio-renderer — consumes the studiolink.v1 output to render PNG images
  • item-registry — produces storeitemvalues.v1 DTOs; property changes here fan out to re-evaluation of all linked ESLs