5 Creative Solutions Using Serverless Computing

There is one project that made me look at serverless in an entirely different way. There was a global online learning platform, and the traffic to the platform was far from being consistent. Right after a lecture, thousands of users could upload files, process videos, and generate notifications in a matter of minutes. For the rest of the day, the platform was pretty inactive.

On the other hand, we considered every user action an individual event. An upload triggered a small script to process that file, make updates, or send notifications. Once the script was done, it faded away. We utilized computing power only when something had to be done.

In essence, it was an architecture that naturally scaled based on demand without any capacity planning. Less time was spent managing infrastructure, and more time was spent adding user-oriented functionality. This experience has shown that the optimal serverless architecture is not one that eliminates servers, but one that matches the infrastructure to the needs of the business.

One creative use of serverless computing was for a telehealth client where a single customer action could trigger several downstream workflows. A subscription purchase or renewal might need to update the commerce platform, generate a patient intake workflow, synchronize CRM data, notify external fulfillment systems, and trigger marketing automation.

The challenge was that the volume wasn’t consistent. Most of the day, the integration layer could be relatively quiet, but promotions, renewal cycles, or bulk processing could suddenly create a large burst of events. Running another permanently provisioned application just to sit between those systems didn’t make much sense.

We used serverless functions as an event-driven integration layer. Incoming webhooks were validated and normalized, then individual functions handled the appropriate downstream actions. That gave us the ability to absorb bursts without sizing infrastructure around peak demand, while also isolating failures. If the CRM update failed, for example, it didn’t have to prevent the rest of the patient workflow from continuing, and that individual operation could be retried.

What made serverless particularly useful wasn’t simply reducing infrastructure cost. It allowed us to decouple business processes that previously would have been tightly connected. As the client changed a CRM, fulfillment provider, or workflow, we could modify that piece without rebuilding the entire integration.

The lesson for me was that serverless is often most valuable not as the application itself, but as the connective tissue between applications.

One of the more interesting problems we solved with serverless was handling the extreme spikiness of inference demand. AI workloads don’t arrive at a steady rate. A customer will send essentially nothing for hours and then suddenly need to process a large batch, or traffic will spike unpredictably because something went viral or a product launch happened. Traditional infrastructure forces you to provision for the peak, which means you’re massively over-provisioned most of the time and paying for capacity that’s sitting idle.

We used serverless to build an inference layer that scales to zero when there’s no traffic and spins up almost instantly when demand hits. The interesting part was getting the cold start latency low enough that customers couldn’t feel the difference between a warm instance and a fresh one. That required some creative work around pre-warming and request routing, but once we solved it, the economics changed completely. Customers stopped paying for idle capacity and we stopped having to guess what their peak demand would be. The serverless model turned an infrastructure headache into something that just handled itself.

Most conversations about digital identity and accessibility focus on making the login screen easier to read. The bigger unlock is redesigning who’s allowed to act on an account at all. We built a remote monitoring platform for a US clinic serving patients with long-term physical, mental, intellectual, or sensory impairments, and one of the real design problems wasn’t authentication itself — it was letting care staff or a family caregiver view and act on parts of a patient’s data without requiring the patient to be the one logging in and confirming every step. That meant building a permission model where the patient keeps a distinct identity and consent trail, while specific, narrow actions can be delegated to a second identity with its own limited scope and full audit history.

That separation — who owns an identity versus who is currently authorized to act through it — is the practical lever for inclusion. It lets someone who can’t reliably complete a verification flow alone still get full access to a service through a trusted second party, without the provider losing track of consent or accountability. Most identity systems are still built assuming a single, capable user acting alone; the accessibility gap closes when they’re designed to expect the opposite.

A straightforward implementation of serverless that I like involves handling everything that happens after a user submits a form on a web page. Submitting the form is relatively simple. The complicated part comes when dealing with validating and processing the submitted form data, sending emails or other notifications, and feeding the information into the CRM.

A serverless function runs only when the form is submitted to perform that task and then stops instead of maintaining the application process throughout for doing these few tasks. This is highly suitable for websites which face uncertain traffic conditions; you may get nothing on some days and then suddenly get a lot due to a campaign.

It’s not just about serverless technology; this is a reduction in manual processes. Incoming leads will move through the cycle without manually copying and pasting data from one system to another or ignoring anything along the way.

I also don’t believe that the serverless approach is applicable to all cases. In cases when you need your program to work continuously, there might be another approach. For me, it is much more appropriate to begin with a business issue and only after that choose the necessary technology.

This might be the most important benefit of using serverless for me. It might help to turn the small annoying process into a silent background process.