Bulk Card Issuance as a Managed Job

Issuing a batch of cards is not simply calling the issuance service in a loop. The operation needs a defined scope, durable progress, a way to recover after interruption, and a result an operator can inspect without reconstructing it from server logs.

The jPOS Control Plane’s bulk-issuance task brings those responsibilities into Job Control. An approved job definition establishes what may run; each execution has its own inputs, status, progress, and reports. The browser submits the request and follows the run. It does not have to remain connected for issuance to continue.

Progress is part of the transaction

The important detail is where progress is recorded. Each batch commits the issued cards and its progress counter in the same database transaction. A retry can determine what has already been committed instead of guessing how far the previous worker got. Cancellation takes effect between batches, preserving completed work.

Job Control provides the operational view around that work: checkpoints, execution status, completion notifications, and downloadable failure reports. These reports describe failed issuance positions; they are not card-personalization or fulfillment files.

Separating coordination from execution

The next step is to move this task from in-process execution to an independent Kubernetes worker pod. In that model, the Job Runner launches the worker, the pod performs the issuance, and Job Control monitors the run and retains its result. The application serving operators is not also the process doing all the batch work.

That distinction is architectural, not cosmetic. A background thread on one server still shares that server’s CPU, memory, and failure domain. Independent worker pods can be scheduled across cluster nodes, allowing execution capacity to grow horizontally without requiring one increasingly large application server. Job status and recovery remain coordinated through the persistent run records.

It also separates two different kinds of parallelism: running several independent jobs across workers is not the same as splitting one issuance request across many pods. The latter requires its own partitioning and recovery contract. Database and cryptographic-service capacity still determine useful concurrency.

The video shows the issuance workflow and its operational evidence. The independent-pod model extends that foundation: keep job coordination and results in the Control Plane, while letting execution capacity grow separately.