Planning on Deploying App to Handle Million of Requests by Leveraging Serverless Computing

Main Components

There are 3 components that can be deployed separately:

1. the app (komform, used by seller)
2. the form scripts (form’s script created by seller, loaded by end customer)
3. the submit API (used by end customer to submit from form script)

The App

Since we are using t3 stack for the app, and Cloudflare pages doesn’t support it yet (too many issues related to NextJS 13, Trpc, and other libraries used).

The App (1) is reasonably easier to deploy to Vercel still considering their seamless deployment experience and the serverless support. Even if the price might be slightly higher than using Cloudflare workers.

The Form scripts

The form scripts is expected to be static scripts and rarely rewritten but frequently read. It is best to deploy it to S3 or Cloudflare R2, but since R2 offers the same performance like S3 and same experience with it but with dramatically lower cost due to zero egress fees then R2 seems to be the best choice to deploy it.

The Submit API

Submit API is expected to handle large amount of request at the same just like form scripts. This API is crucial because we do not want to lose data when end-customer submit data via seller’s form.

To overcome it, I think we can use Cloudflare workers combined with Queue. With queue each message sent is guaranteed to be at least delivered once.

So there will be API / HTTP request handler that will capture the POST request from the form, and then it will send to the queue (acting as producer).

And there will be another worker that will consume the queue and proceed with storing it to database (right now we are using Planetscale which promise can handle million of requests per second to their MySQL database, https://planetscale.com/blog/one-million-queries-per-second-with-mysql)

Limitation of Queue

I’ve read somewhere in the doc that each queue can only have one consumer, which means if I have to do multiple things with a message I have to do it all in single worker. Let’s say store it to database and then send email notification.

Need more research about Queue

If the consumer failed to process, I assume there should be a way to mark the operation as failed and then retry after some time. Need to research more if this is true and how to do that.

ORM

Since Prisma doesn’t support serverless computing without setting up Prisma data account, We plan to use Kysely (https://github.com/kysely-org/kysely) as ORM for API that will be deployed to serverless functions (e.g Cloudflare Workers)

Supporting Components

Besides the main components, we also have another components that provide sellers with more useful insights.

1. Form Analytics (All time, monthly, daily)

   • This includes: Form views count, form submit count.
   • Time series data: Yearly, monthly, daily.

We should do this also in Queue’s consumer.