Skip to content

Sizing and Capacity

Applies to: All subscriptions

Purpose

Give infrastructure teams a defensible starting specification, explain what each resource is actually consumed by, and — because the starting figures are estimates — show how to replace them with measured values after the first month.

Audience

Infrastructure engineers, architects, procurement.

Prerequisites

  • Deployment Topologies
  • Expected monthly document volume, agreed with the business
  • Agreed retention period

Reference

Verify: Every figure on this page is an engineering estimate. None is a measured benchmark. Use them to start a conversation with procurement, not to conclude one — and re-forecast from your own telemetry after one month of real traffic. Recorded as assumptions A1 to A4 in the Assumptions Register.

Volume tiers

Tier Documents per month Typical customer
Pilot Up to 2,000 Proof of concept, single GSTIN
Small 2,000 to 20,000 Single entity, a few registrations
Medium 20,000 to 100,000 Multi-entity, several registrations
Large Over 100,000 Group-wide, high transaction volume

Count documents processed, not invoices issued: credit notes, debit notes, delivery challans and e-Way-Bill-only documents all consume the same pipeline.

Starting specification

Application host (API and worker, per the chosen topology):

Tier vCPU Memory Local storage
Pilot 2 8 GB 60 GB
Small 4 16 GB 100 GB
Medium 8 32 GB 200 GB
Large 8 or more per instance, several instances 32 GB per instance 200 GB per instance

Database host:

Tier vCPU Memory Data storage (first year)
Pilot 2 8 GB 50 GB
Small 4 32 GB 150 GB
Medium 8 64 GB 500 GB
Large 16 or more 128 GB or more 1 TB or more

Database memory matters more than database CPU for this workload. The access pattern is dominated by reads over recent documents; keeping the working set in memory is what keeps screens responsive.

What actually consumes each resource

CPU is consumed mainly by document validation and by transformation of ERP payloads — both proportional to document count and to lines per document. Government calls themselves are cheap in CPU terms; they are network waits.

Memory has two distinct consumers with very different profiles:

Consumer Profile
API request handling Steady, roughly proportional to concurrency
PDF rendering Spiky. A headless browser instance per render, released afterwards

Size for the peak of the second, not the average of the first. A host sized for steady request load will fail during a month-end bulk print, and the failure will look like an unrelated application fault.

Storage grows from four sources:

Source Grows with Discretionary?
Document and compliance records Documents processed No — statutory retention
Stored payloads and signed responses Documents processed No — this is the evidence
Cached rendered documents Documents printed Partly — cache lifetime is configurable
Raw ERP payloads Ingested documents Partly — retention is configurable
Audit and telemetry Activity Partly

The two non-discretionary rows are the reason storage forecasting matters: they cannot be trimmed to recover space.

Growth estimate

Verify: These per-document figures are estimates, not measurements. Replace them with your own after one month. Recorded as assumption A2 in the Assumptions Register.

Item Estimate per 1,000 documents
Database rows and indexes 40 to 80 MB
Stored payloads and responses 20 to 60 MB
Cached rendered documents 100 to 300 MB, if printing is heavy
Audit and telemetry 5 to 15 MB

A medium tier at 50,000 documents per month, using the upper end and including printing, projects to roughly 20 to 25 GB per month before compression — a figure that matters when it is multiplied by a multi-year retention period.

Non-production environments

Non-production environments are usually sized at one tier below production, with two exceptions:

  • Upgrade rehearsal requires a representative data volume, or the rehearsal proves nothing about migration duration.
  • Load testing, if performed, requires production-equivalent specification.

Validation

Sizing is not validated by provisioning it. Validate it against behaviour, in the first month and then quarterly.

Check Method Healthy Act when
Application CPU Sustained utilisation over a working day Below 60 percent Sustained above 75 percent
Application memory Peak during the heaviest print batch of the month Peak below 75 percent of available Peak above 85 percent, or any out-of-memory event
Database CPU Sustained utilisation Below 50 percent Sustained above 70 percent
Database memory Buffer cache hit behaviour Working set resident; reads mostly from memory Read latency rising with a falling cache hit rate
Storage growth Measure database and file-store size weekly for four weeks Matches or beats the forecast Actual exceeds forecast by more than 25 percent — re-forecast immediately
Free space Percentage free on every volume Above 30 percent Below 20 percent
Job latency Time from upload submitted to job complete, at peak Stable week on week Rising trend at constant volume
Print latency Time to render a single document at peak Stable Rising, or renders failing

The four-week measurement is the important one. It replaces every estimate on this page with a fact, and it is the only way to make a defensible multi-year storage commitment.

Troubleshooting

Symptom Likely cause Action
Screens slow, application CPU high, database idle Application tier undersized Add vCPU, or add an instance if the topology allows
Screens slow, database CPU high, application idle Database undersized, or index maintenance overdue Check maintenance first — it is cheaper than hardware. See Monthly Checks
Screens slow, both idle Waiting on an external call, or a network path problem Government calls are network waits. See Performance Issues
Bulk print fails while everything else works Rendering exhausted memory Raise memory, or reduce batch size. Sizing for average request load causes exactly this
Upload jobs queue and never clear Worker down, or the queue unreachable — not a capacity problem Check the worker and queue before adding hardware
Disk fills faster than forecast Cache and raw-payload retention longer than assumed, or volume above plan Review retention settings; confirm actual volume against plan. See Housekeeping
Performance degrades gradually over months at constant volume Data growth outpacing memory, or index fragmentation Re-measure the working set; verify maintenance is running
Month-end is consistently slower than the rest of the month Real load concentration, not a fault Size for the peak. Averages hide month-end entirely