Why I Built a Serverless Certificate Generation System
When I was the Group Leader of the AWS Student Builders Group at Lovely Professional University, one of the biggest challenges wasn't organizing events.
It was what happened after they ended.
Every event meant generating and distributing certificates to hundreds of attendees. Which sounds easy for now.
That's exactly what I thought. Turns out, it wasn't.
Especially when you're running a student community with little to no budget and infrastructure decisions directly affect what you can (and can't) afford.
The First Attempt
Like every developer, I started with the quickest solution.
Google Apps Script + Gmail.
It was easy to build, easy to maintain, and honestly, it worked pretty well...until our events started getting bigger.
Once we crossed the 200+ attendee mark, Gmail started becoming the bottleneck.
Sending that many emails in a short period meant running into sending limits, risking spam filters, and hoping every participant actually received their certificate.
What was supposed to be a one-click automation slowly became a process of checking failed deliveries, retrying emails, and occasionally answering, "Hey, I still haven't received my certificate."
Clearly, this wasn't going to scale.
The "Let's Put It on the Website" Phase
My next thought was simple.
"Why email certificates at all? Why not let attendees generate them themselves?"
So that's exactly what I did.
Participants could log into the event platform and generate their certificates whenever they wanted.
Problem solved...or so I thought.
The website was running on Cloudflare Workers, and generating PDF certificates turned out to be one of the most compute-heavy operations in the entire application.
The more certificates people generated, the more Workers quota disappeared.
At one point, the application felt like it was spending more time generating PDFs than actually serving the website.
I had fixed the email problem. Now I had a compute problem.
Taking a Step Back
Instead of looking for a bigger server or a more expensive plan, I asked myself a different question.
Why is the website generating certificates in the first place?
The website's job is to serve users.
Certificate generation is a completely separate task.
It doesn't have to happen inside the same request. It doesn't even have to happen on the same infrastructure.
That realization changed everything.
Instead of making the website do all the heavy lifting, it would simply say,
"Hey, someone requested a certificate."
And another system would take care of the rest.
That's when I decided to move towards an event-driven, serverless architecture.
How It Works Today
The platform already had a QR-code-based attendance system.
When attendees scanned the checkout QR code, their attendance was marked as complete.
Once that happened, they became eligible for a certificate.
A Generate Certificate button appeared on their dashboard, allowing them to generate the certificate up to three times for that event.
From the participant's perspective, that's all they ever see.
Attend the event.
Scan the QR code.
Click one button.
Download the certificate.
Simple.
Behind that single click, however, there's an event-driven workflow handling all the heavy processing without putting additional load on the main application.
Why I'm Happy With This Approach
The biggest lesson from this project wasn't learning a new AWS service.
It was learning that sometimes the solution isn't making your application stronger.
It's making your application responsible for less.
Once I stopped treating certificate generation as a website feature and started treating it as an independent workflow, everything else started falling into place.
The application became lighter. The workflow became more scalable.
And the operational cost became so low that our student community could comfortably afford it ourselves.
Literally around the cost of a few evening snacks.
What's Next?
This article was about why this system exists.
In the next one, I'll go full engineering mode.
I'll walk through the complete architecture, explain why I chose a serverless event-driven approach, why each AWS service earned its place in the system, and the trade-offs I had to make along the way.
Top comments (0)