Sizing Compute for a Ticket-Intake API with Violent Month-End Peaks
LedgerLine processes parking-ticket images for 40 municipal customers. Its Spring Boot API takes about 6 million uploads a month: roughly 150 requests per second during business hours, with two month-end peaks that reach about 1,400 requests per second for 90 minutes each, and near-zero traffic between 02:00 and 05:00. Each upload writes a row to PostgreSQL and places the image in Cloud Object Storage. A separate worker OCRs each image and can take up to four minutes per job. The team has five developers and two SREs, no dedicated platform engineers, and a hard requirement that data stay in the Frankfurt region. Finance approved a monthly infrastructure budget with no headroom for permanent over-provisioning. The lead developer wants everything on a serverless container platform to reach zero cost at night; the SRE lead wants VPC virtual server instances behind a load balancer; a third voice proposes a Kubernetes cluster with horizontal pod autoscaling.
1. Recommend a compute target for each of the three workloads (API, OCR workers, PostgreSQL) and justify the choice against the constraints.
Read the worked answer
Match each workload to its runtime characteristic rather than standardizing on one platform.
API. Stateless and HTTP-driven, so a serverless container platform fits well: scale-to-zero overnight, scale-out on the month-end spike, and no cluster to patch for a team with no platform engineers. Two caveats decide the details. First, 150 requests per second means it is rarely at zero during business hours, so configure minimum instances to keep a warm floor and avoid cold-start latency on the first morning requests. Second, the 1,400 rps spike can outrun default concurrency and maximum-instance limits, so raise the per-region quota and load-test before the first month-end, not after.
OCR workers. Four-minute jobs are a bad fit for a request-driven path that bills and times out per request. Run them as asynchronous jobs or as a worker deployment fed by a queue, with retries and a dead-letter path. A container job service keeps operational overhead low; a worker deployment on Kubernetes is acceptable but adds a cluster to own.
PostgreSQL. Never in the serverless container platform and preferably not self-managed on a single volume. Use a managed database service deployed across zones, with connection pooling in front of it, because 1,400 rps of short writes will exhaust connections before it exhausts CPU.
If the team later hires platform engineers, consolidating API and workers on Kubernetes becomes reasonable; today the operational tax outweighs the flexibility.
2. How should the architecture be placed and sized across the Frankfurt multizone region so that a single-zone failure does not breach the service level, and what quota work does that imply?
Read the worked answer
Treat the multizone region as the unit of design, not as a checkbox.
Placement. Create one subnet per zone and place API capacity in all three. A regional load balancer spans zones and health-checks per zone, so it removes a failing zone automatically, but only if capacity exists in the surviving two. That is the sizing rule: provision the API so that two of three zones can carry the full month-end peak, which means either N+1 sizing or an autoscaling policy that can reach the peak within the spike ramp. For the workers, use queue depth as the scaling signal and spread pods or instances across zones; losing a zone should delay OCR, not drop jobs.
Database. Managed PostgreSQL with a multizone deployment keeps a standby in another zone and handles failover; verify the failover time against your tolerance rather than assuming it.
Quota work. VPC vCPU quotas are per region, and autoscaling fails silently from the user's perspective when a quota blocks scale-out. Calculate peak vCPU including the N+1 headroom, request an increase before the first month-end, and add a budget alarm on the quota. Also confirm object storage request-rate limits and that image uploads retry idempotently, since a burst of 1,400 rps against a bucket is as much a rate question as a compute question.
3. Finance wants predictable spend without paying for the peak all month. Which pricing and cost-control levers apply, and which ones would mislead the team?
Read the worked answer
Split the bill into a floor and a peak, then buy each with the right instrument.
Floor. The 150 rps business-hours baseline is predictable. Cover it with reserved capacity or committed use for the compute that runs continuously, and with a fixed-size managed database tier. That is where discounting is real and the risk of overcommitment is low.
Peak. Ninety minutes, twice a month. Buy that on-demand. Committing for the peak means paying for 720 hours to serve three, and the serverless container model handles it without idle spend as long as the quota is raised.
Levers that work: a tagging standard (customer, environment, workload) so per-municipality unit economics are visible; budgets with 50/80/100% notifications per resource group; deleting or powering off non-production outside working hours; and watching the non-obvious lines, namely object storage operation counts (6 million uploads is 6 million PUT requests plus reads and lifecycle transitions) and storage-class choice for images that are rarely re-read.
Levers that mislead: treating the average request rate as the sizing basis, so the spike is discovered in production; assuming serverless means the bill is zero at night when the database, storage, and load balancer keep running; and committing to reserved capacity for the API before the autoscaling profile is measured. Revisit reservations after one full quarter of real peak data, not before.