Analysis
The development process started by mapping the existing certificate issuance workflow.
From this analysis, I found that the main problem was not simply PDF generation, but the relationship between:
- activities;
- participants;
- issuers;
- certificate numbers;
- batches;
- generated files;
- and the certificate issuance lifecycle.
I separated master data from transactional data so future changes to participant information would not modify the historical data of certificates that had already been issued.
Strategy
I selected a modular monolith architecture using Laravel to keep delivery straightforward while maintaining clear domain boundaries.
The participant import workflow was separated from the certificate generator.
Participants must already be validated and associated with an activity before an issuance batch can be created.
This approach makes certificate generation more deterministic and prevents the generator from becoming an implicit pathway for creating new participant data.
Batch and certificate states were also defined explicitly.
Automatically generated certificate numbers are allocated using database transactions and locking, while externally sourced numbers are validated before certificate records are created.
Snapshots of recipient and issuer information are stored with each certificate so historical records remain consistent even when master data changes.
Implementation
CSV files are processed using a streaming approach.
Headers are normalized and each row is validated before the data is committed.
When an email address is available, it can be used to identify an existing participant within the same branch. Participants with identical names but insufficient identifiers are not automatically merged.
When an operator confirms an issuance batch, the system creates one queued job for each certificate.
Each job:
- reloads the certificate record;
- checks whether the item has already been completed;
- renders a Blade view into PDF using Chromium;
- stores the file in private storage;
- updates the certificate status;
- updates batch progress atomically.
The application interface reads progress directly from the database, allowing processing status to remain available even when the browser page is refreshed.
For public verification, verification codes are directed to dedicated permanent URLs.
These pages display only the required registry information and certificate snapshot, while PDF file locations and internal data remain private.
Validation
Implementation validation was performed through unit tests and feature tests.
Test scenarios include:
- data import;
- participant deduplication;
- participant selection;
- certificate numbering;
- queue dispatch;
- idempotency;
- batch status;
- PDF rendering;
- private storage;
- file downloads;
- public verification;
- authorization;
- and cross-branch access denial.
Laravel Pint and production asset builds were also used as additional quality checks before delivery.
Key Features / Implementations
Participant Registry and CSV Import
Participants are stored as canonical identities within the context of each branch.
Package and activity-specific information is stored within participation records, allowing the same participant to join multiple programs without creating unnecessary duplicate identities.
The import process provides summaries for:
- valid rows;
- invalid rows;
- new participants;
- existing participants;
- and duplicate records.
Certificate Generation Engine
The certificate generator retrieves participants from stored activity data and applies the required issuance scope.
Operators can select all eligible participants or specific participant groups before confirmation.
Batch and certificate records are created within a transaction, after which each certificate is processed through an independent queue job.
This approach allows failures to be handled at the individual certificate level without causing the entire batch to fail.
Numbering and Immutable Snapshots
Internal certificate numbers are allocated using a locking mechanism.
For activities using external numbering, official source numbers are preserved and checked for duplication.
Certificates also store snapshots of important information, including:
- recipient name;
- issuer;
- activity title;
- activity period;
- certificate number.
These snapshots preserve historical certificate information even when the associated master data is later updated.
PDF Generation, Private Storage, and Downloads
Blade-based print views are rendered into A4 PDF documents using Chromium.
Attendance and course completion templates use official artwork with controlled dynamic data placement.
Generated files are stored in private storage.
Authorized users can access certificates through:
- preview;
- individual PDF download;
- batch ZIP download.
Public Certificate Verification
Completed certificates can be verified using a public identifier.
The identifier resolves to a canonical verification URL.
The verification page displays only the minimum information required to confirm certificate validity without exposing private file paths or unnecessary participant information.
Multi-Branch Authorization and Audit
Queries, policies, middleware, and relational constraints are used to restrict access according to the user's branch.
Specific roles can be granted explicit cross-branch capabilities when required.
Important actions such as data imports, certificate generation, deletion, and configuration changes are logged to support traceability and auditing.
Workshop CMS and Email Foundation
In addition to credential operations, InixCert includes a Workshop CMS foundation covering:
- categories;
- collections;
- SEO metadata;
- workshop schedules;
- activity batches;
- public visibility rules.
For communication workflows, the application also provides reusable email templates, controlled personalization tags, HTML sanitization, activity-specific drafts, subscriber lists, and a queue-based mailing foundation.
Case Study
Problem
Certificate issuance previously depended on several disconnected tools and files.
Participant data, certificate numbers, templates, and generated PDF files were not managed within a single traceable lifecycle.
As the number of activities and participants increased, the manual workflow resulted in more repetitive work and a greater risk of data inconsistencies.
Analysis
I concluded that improving PDF rendering speed alone would not solve the underlying problem.
The system needed to validate data before rendering, maintain relationships between participants and activities, manage certificate numbering, track the status of individual certificates, and provide public verification without exposing private files.
Action
I developed a sequential certificate issuance workflow:
- create activity master data;
- import participants;
- validate participant data;
- select the template and recipient scope;
- create certificate snapshots;
- confirm the issuance batch;
- process PDF generation through the queue;
- store generated files in private storage;
- display progress from the database;
- provide public certificate verification.
At the application level, I also implemented database transactions, unique constraints, idempotent job behavior, branch-scoped authorization, audit logging, and minimum disclosure principles for public verification.
Result
InixCert provides a centralized certificate issuance workflow connecting participant data, generated PDF files, and public verification pages.
Operators do not need to wait for PDF rendering to complete within the browser request.
Each certificate can be tracked individually, and a failure affecting one certificate does not remove visibility into other items within the same batch.
The underlying data structure also supports multiple issuance contexts, including internal events, training programs with external numbering, workshops, and gradual expansion into multi-branch operations.
