A Serverless Backend for a Two-Sided Marketplace: Letting Cost Follow Usage

A new two-sided marketplace has an awkward traffic profile. At launch there may be very little activity, then sudden bursts when a batch of jobs is posted or a campaign lands. For a gig marketplace connecting freelancers with clients posting short-term work, we built the backend fully serverless, so that infrastructure cost stays proportional to what the platform actually does.

This post explains that decision, the trade-offs that come with it, and how to judge whether it fits your own product.

The product

The marketplace covers the full lifecycle of short-term work:

• Clients post gigs, and freelancers discover and apply to them.
• Both sides message each other.
• Ratings and reviews build trust after each job.
• Payments are integrated into the flow.

The front end is built with React and Vite. The backend uses NestJS on a serverless architecture designed for elastic scaling.

Why serverless suited this marketplace

Cost that tracks activity

With traditional servers, you pay for capacity whether or not anyone is using it, and you size for your busiest moment. On a serverless platform, you are billed for execution, so a quiet week costs little and a busy one scales without anyone resizing servers. For an early marketplace still finding its audience, that alignment between cost and usage matters.

The workload is event-shaped

Most marketplace actions are discrete events: someone posts a gig, submits an application, sends a message, leaves a review, completes a payment. Each is a short request with a clear start and end. That is the kind of work serverless platforms handle naturally.

Less infrastructure to operate

A small team building a marketplace should spend its time on the marketplace. Serverless hands patching, scaling and much of the availability work to the provider, as described in overviews such as AWS's introduction to serverless.

The trade-offs to plan for

Serverless is not free of constraints. These are the ones worth designing around from the start:

• Cold starts. A function that has not run recently can take longer to respond on its first request. Keep function start-up work light, and be aware of which user-facing paths are most sensitive to it.
• Database connections. Many short-lived functions can open many database connections at once. Plan for connection pooling or a data layer suited to serverless use.
• Long-running work. Functions have execution time limits. Anything slow, such as generating reports or processing large files, belongs in a queue or background job, not in a request.
• Local development and debugging. Reproducing a serverless environment locally takes more setup than running a single server. Invest in that setup early.

None of these rules serverless out. They are simply easier to design for on day one than to discover in production.

When serverless is a poor fit

It tends to be the wrong choice when:

• Traffic is steady and high, so reserved capacity would be cheaper.
• The workload is dominated by long-running or stateful processes.
• The product needs persistent connections at the core of its experience and the platform does not support them well.
• The team is not prepared to work within the provider's model.

How to decide for your product

Ask three questions:

1. What will traffic look like in the first year? Spiky and unpredictable favours serverless. Steady and heavy favours servers.
2. Is the work made of short events or long processes? Events favour serverless.
3. Who will operate it? A small team without dedicated operations benefits most from handing that work to a provider.

For this gig marketplace, the answers pointed clearly to serverless. For a data-heavy internal system with constant load, they would point elsewhere, which is why we do not start from a default architecture.

The anonymised write-up is in our work library. If you are designing a marketplace, choosing an architecture that matches your expected traffic is part of how our MVP service scopes a first release. Our post on building the account foundation first covers the other early decision marketplaces tend to get wrong.