One application, two paths to useful work
This illustrative scenario is a small reporting product, not a customer case study or a delivered application. Its synchronous path authenticates an account and reads report metadata. Its asynchronous path creates a CSV export. PostgreSQL holds application state, a queue dispatches work and a separate destination stores recovery copies.
The operator installs and maintains these components. A VPS profile does not automatically create the database, queue, HTTPS configuration or application. Decide where persistent data lives before starting a container.
Budget API latency and job throughput separately
App 2 starts with 2 vCPU, 4 GB RAM, 60 GB storage and 2 TB monthly transfer. These are allocations, not a promise about the number of accounts, requests or exports it can support. Start a worksheet for API processes, database, one worker, the host and overlapping release work.
The illustrative 3,840 MiB worksheet leaves too little confidence near a nominal 4 GB boundary. If measurements support that shape, App 2 plus 2 GB RAM totals $15.00 monthly before term discounts. That adds memory, not CPU or database independence. Compare Scale 4 if both CPU and memory need a larger starting budget.
Monitor oldest-job age and useful completion rate alongside API latency. A growing queue with low CPU can point to storage or database waiting. Do not buy compute to compensate for an export that repeatedly retries an invalid input.
Choose the coupling you can operate
One host simplifies the first service map and avoids some inter-host coordination, but shares memory, disk, maintenance and failure. An expensive export can interfere with ordinary requests. Bound worker concurrency and make repeat delivery safe before adding processes.
Separate workers when a realistic job load consistently harms API behavior, when their runtime requirements diverge or when independent scaling and maintenance become important. Separate the database when its own resource, access or recovery needs justify the added networking and operational work. These are design choices, not features automatically provided by upgrading a plan.
Prove the shape with a repeatable exercise
Use synthetic accounts and a representative dataset. Run API reads, a large export and a release overlap together. Record latency, errors, active worker count, oldest-job age, memory and temporary disk. Then restart one worker after an output is written but before completion is recorded; confirm the application still publishes one logical result.
Repeat a recovery drill for the database and one upload on an isolated target. Capture the actual result and repair missing dependencies. Do not run this exercise against customer data or real external payment and email destinations without a separate operating plan.
Choose a period after choosing the resources
The following totals use the current App 2 base configuration. Resource options increase the monthly subtotal and receive the same selected term discount. The full reduced period is paid upfront; more months do not increase the CPU, RAM or monthly transfer allocation.
| Period | Before discount | Saving | Total USD |
|---|---|---|---|
| 1 month | $12.00 | $0.00 (0%) | $12.00 |
| 3 months | $36.00 | $0.00 (0%) | $36.00 |
| 6 months | $72.00 | $20.16 (28%) | $51.84 |
| 12 months | $144.00 | $72.00 (50%) | $72.00 |
Confirm actual inventory, service responsibilities, tax and renewal terms in service facts. A local payment reference does not establish a registered order or a delivered server. Keep your workload worksheet and revisit it when the application changes.
Turn the budget into a configuration.
Review all choices and the full upfront total.