# Launch-day readiness

> Your biggest day shouldn't be your first real load test.

- Page: https://deependra.in/services/scale/launch-readiness
- Type: Service, part of Performance and reliability
- Last updated: 2026-11-02
- Line page: [Performance and reliability (Scale)](https://deependra.in/services/scale)
- Author: [Deependra Vishwakarma](https://deependra.in/about), senior software engineer in Mumbai

## In short

Launch readiness is load-testing a system at the expected traffic before a launch, campaign, sale or broadcast, then fixing what breaks first. It is for media, e-commerce and SaaS teams whose biggest day shouldn't be their first load test.

It's the work behind the voting platform in my case studies, which had to stay fast for all 22 days of a campaign.

## Key facts

- Engagement: fixed-scope project
- Price: Fixed price for readiness; on-call cover priced per day
- Timeline: Best started well before the event
- First step: **Model the day.** Expected visitors, the journeys they'll take, and where the writes happen. That becomes the load test.
- Works with: k6, Apache JMeter, Redis, Laravel Queues, NGINX, Cloudflare, Google Cloud, AWS, Grafana
- Based in: Mumbai, India · UTC+5:30. I plan my working day around my clients' hours. The overlap with your timezone is shown on the [contact page](https://deependra.in/contact).

## What is launch readiness?

Launch-day readiness is load testing and hardening a web application before a known traffic peak, a launch, a sale, a broadcast or a public vote, and then staying on call while the event runs. I model the day, test the system at the expected load until something breaks, fix what broke, and repeat until it holds the peak with headroom. It is for media, e-commerce and SaaS teams whose biggest day shouldn't be their first real load test.

## Who it is for, and who it is not

### Who this is for

- Media and entertainment platforms before a broadcast or a public vote
- E-commerce teams before a sale or a product drop
- SaaS teams before a launch, a press moment or a large customer's go-live

### Who this is not for

- Events less than a week away with no staging environment: I can still help, but that's emergency work, not readiness

## What you get

1. A load model: expected peak, traffic shape and what counts as failure
2. Load-test results against staging, with the first bottleneck found at each stage
3. Caching, queueing and database changes that remove those bottlenecks
4. Autoscaling and CDN configuration, pre-warmed for the event
5. A runbook, dashboards and alerts, and on-call cover during the event

## Scope

One event and the system that serves it: the pages and API journeys visitors will take, the writes they will make, and the infrastructure underneath. The load model comes first: expected visitors, how fast they arrive, which journeys they take, where the writes happen and what counts as failure. Everything after that is measured against it.

## What is tested and changed

Load tests are scripted to follow real journeys, run from several regions against a staging copy of production, and stepped up until something fails. Google's SRE book calls load-testing a server's capacity limits and its failure mode under overload the most important exercise for preventing overload; this is that exercise, done before the day rather than on it.

The first bottleneck is rarely where people expect. Typical fixes are caching in front of the reads everyone makes at once, moving slow work into queues, adding read paths that keep the database for the writes that must reach it, setting autoscaling limits and pre-warming instances, and CDN rules that let the edge answer what it can. After each fix the test runs again.

This is the work behind the [InfluencerX voting platform](https://deependra.in/work/influencerx-voting-platform), which served 1.6M+ users over a campaign of 22 days, with 2,000+ at the same moment at peak and 99.99% availability.

## Launch-day checklist

Six checks, in this order, are what launch readiness comes down to. You can run through them yourself before an event, or have them done for you.

**1. Load test.** Run scripted journeys with k6, or Apache JMeter where your team already uses it, from several regions against a staging copy of production, stepping the load up until something fails. Fix the first bottleneck, test again, and repeat until the system holds the expected peak with headroom.

**2. Warm the caches.** Pre-warm the CDN and the application cache, so the first visitors don't all reach the origin at once.

**3. Queue the slow work.** Anything that doesn't have to finish inside the request waits in a queue, so a spike delays a task instead of timing out a page.

**4. Set autoscaling.** Decide the minimum and maximum capacity and pre-warm instances before the event, instead of discovering the limits during it.

**5. Rehearse the rollback.** Agree how to go back if a change misbehaves, and practise it in a dry run of the day.

**6. Put someone on call.** Dashboards, alerts and a runbook are ready, and a named person is at their desk for the agreed window.

The [InfluencerX voting platform](https://deependra.in/work/influencerx-voting-platform) case shows this checklist at campaign scale.

## What it is not

It is not a guarantee that nothing can go wrong; it is a tested statement of how much load the system holds and what happens beyond it. It is also not a substitute for time: an event less than a week away with no staging environment gets emergency stabilization, which is useful but different. Three to four weeks of notice is comfortable.

## How the engagement runs

1. **Model the day.** Expected visitors, the journeys they'll take, and where the writes happen. That becomes the load test.
2. **Test until it breaks.** Step the load up against a staging copy of production and record what fails first.
3. **Fix in order.** Remove each bottleneck, re-test, and repeat until the system holds the expected peak with headroom.
4. **Rehearse and run.** A dry run of the day, then live monitoring and on-call cover while it happens.

## Technologies I use for this

k6, Apache JMeter, Redis, Laravel Queues, NGINX, Cloudflare, Google Cloud, AWS, Grafana

## How this works in your market

### How this works in the United Arab Emirates

For teams in [the UAE](https://deependra.in/markets/uae), our working days overlap almost completely, so rehearsals and the event itself fall inside my normal hours. Load tests run against infrastructure in the region you've chosen, so test data and logs stay where your production data lives. For an event that justifies it, I can be in Dubai for the dry run.

[United Arab Emirates page](https://deependra.in/markets/uae)

### How this works in South Korea

For teams in [South Korea](https://deependra.in/markets/south-korea) launching abroad, the load model includes where the traffic will come from, so tests run from the regions your new users are in, not only from Seoul. Korea is three and a half hours ahead of me; for an event in US or European hours, on-call cover is planned around the event's time, not mine.

[South Korea page](https://deependra.in/markets/south-korea)

## Case studies behind this service

- [InfluencerX](https://deependra.in/work/influencerx-voting-platform): Real-time voting platform. 1.6M+ users over the campaign.
- [TopGear India CMS](https://deependra.in/work/topgear-india-cms): CMS migration and modernization. 1–3 min → 3 s page load time, before → after.

## Questions about Launch-day readiness

### How much notice do you need?

Three to four weeks is comfortable: enough to test, fix and rehearse. With less, I focus on the changes with the biggest effect.

### Can you help if the site is falling over right now?

Yes. Stabilization comes first (edge caching, shedding non-essential load, scaling the database), then the proper fixes.

### How do you simulate the traffic?

With scripted load tests that follow real user journeys, run from several regions against a staging copy of production, stepping the load up until something breaks.

### Which load-testing tools do you use?

Mostly k6, an open-source load-testing tool whose tests are scripts kept in your repository, and Apache JMeter where a team already uses it.

### Do we need a staging copy of production?

For meaningful results, yes: same configuration, realistic data volumes, and no real customers. If you don't have one, building it is the first task.

### What does on-call cover include?

Live monitoring of the dashboards we built, the runbook to hand, and me at my desk for the agreed window, ready to act on the steps we rehearsed.

### What should I load test before a launch?

The journeys real visitors will take and the writes they will make, not only the home page. The load model decides the numbers first: expected visitors, how fast they arrive, which journeys they take and what counts as failure. The tests then run against a staging copy of production, stepped up until something breaks, so you learn the first bottleneck before your visitors do.

### How many users can my site handle?

Only a load test can tell you, and the answer is a tested statement rather than a guess: how much load the system holds, and what happens beyond it. I step the load up against a staging copy of production until something fails, fix that bottleneck and test again, until the system holds the expected peak with headroom. The result is a figure for your system, not a general one.

### What is a launch-day runbook?

A written plan for the event, kept next to the dashboards and alerts built during the readiness work. It says what to watch, what each alert means, what to do when it fires and who decides. It is rehearsed in a dry run of the day, so the person on call acts on steps already practised.

## Related services

- [Performance and Core Web Vitals audit](https://deependra.in/services/scale/performance-audit) (Performance and reliability): Find out in five working days exactly why your application is slow, and what to fix first.
- [Cloud, DevOps and cost](https://deependra.in/services/scale/cloud-devops) (Performance and reliability): Deployments you don't dread, backups you've actually tested, and a cloud bill that makes sense.

## Sources

1. [Google SRE book: Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/)
2. [Grafana k6 documentation](https://grafana.com/docs/k6/latest/)

## Related writing

- [How a voting platform held up through a 22-day campaign](https://deependra.in/writing/voting-platform-22-day-campaign-architecture) (2 November 2026): The architecture behind the InfluencerX voting platform: Cloud Run behind a load balancer with health checks, layered caching and Supabase.
- [TopGear India: moving a publishing CMS from CodeIgniter to Laravel while the newsroom kept publishing](https://deependra.in/writing/topgear-india-cms-migration-case-study) (2 November 2026): The decisions behind one CMS migration: a full rewrite, the content model and URLs kept, the speed found in SQL, caching and images, and an editor-first CMS.

## Where this work happens

- [United Arab Emirates](https://deependra.in/markets/uae) (Dubai): A software engineer for UAE teams in Dubai and Abu Dhabi, working remotely from Mumbai with nearly the full working day in common. It is for digital teams building platforms that must meet the UAE's data-protection rules, where the first question is whether the federal law, the DIFC law or the ADGM regulations apply.
- [South Korea](https://deependra.in/markets/south-korea) (Seoul): A software engineer for Korean teams, working remotely from Mumbai with my morning in your afternoon. It is for startups and scale-ups going global that need AI and product engineering at speed, built to meet US and European privacy expectations from the first release.

## Teams that start here

- [Austin, US](https://deependra.in/markets/united-states/austin)

## Start

Plan your launch: https://deependra.in/contact

---

Cite as: Deependra Vishwakarma, "Launch-day readiness", https://deependra.in/services/scale/launch-readiness (last updated 2026-11-02).

This is the Markdown version of https://deependra.in/services/scale/launch-readiness; the page is the canonical source. Start a project: https://deependra.in/contact