Cloud Compute and Storage Choices: VMs, Containers, Serverless, Object

A regional theatre company wants to sell tickets online. Most of the year a few hundred people visit per day. When a famous show goes on sale, thousands arrive in the first ten minutes, all fighting for the same front-row seats. This one product needs steady everyday capacity, a short enormous spike, strict correctness for seat reservations, and cheap storage for posters and PDF tickets. No single compute or storage option serves all of that, which makes it a good case for learning how to choose.

Compute: four ways to run your code

There is no best option, only a best fit per component. A useful rule of thumb is to match the shape of the workload: steady and long-running work suits containers or VMs, bursty event-driven work suits functions, and when nothing special is needed a platform service means the least work. Serverless is not magic: you still pay per invocation and for the time your code runs, so a function called constantly can cost more than a small always-on container.

Storage: the right container for the data

For databases, relational versus non-relational is a design question covered in Databases in System Design. For seat inventory the theatre needs transactions, so a managed relational database is the natural choice, with the provider running backups and a standby in a second zone.

Putting it together: the ticket-booking architecture

  Browser
    |
  [CDN] ---- posters, JS, CSS ----> [Object storage: assets]
    |
  [Load balancer]  (spans zones A and B)
    |
  [Web/API containers x2..8]   <- scale on request rate
    |        |
    |        +--> [Queue] --> [Function: PDF ticket + email]
    |                                  |
    |                         [Object storage: tickets]
    |
    +--> [Cache: seat holds, 5-min TTL]
    |
  [Managed SQL database]
     primary (zone A) + standby (zone B)
     automated daily backups, point-in-time recovery

Every box has a reason. The CDN and object storage serve posters so the app servers never touch them. Containers behind a load balancer run the booking logic and scale with traffic, and because they are stateless any of them can serve any request. The seat-hold timer lives in a cache so that tens of thousands of "hold this seat for five minutes" operations do not hammer the database. The only authoritative record of who owns which seat is the transactional database. And the slow, bursty, non-urgent work, building a PDF and sending an email, goes through a queue to a function so that a slow email provider can never slow down checkout. The same queue-and-worker idea appears in the Apache Kafka course when volumes get larger.

A back-of-envelope cost estimate (illustrative only)

Cost reasoning should happen before building, using rough numbers. The program below uses invented prices in made-up units, not any provider's real rates, to show the structure of an estimate: list the components, multiply a unit price by quantity and hours, and compare keeping spike capacity running all month against adding it only for the on-sale window.

# ILLUSTRATIVE prices in made-up units. Replace with your provider's price list.
HOURS_PER_MONTH = 730
PRICE = {
    "small_vm_hour": 0.02,
    "medium_vm_hour": 0.08,
    "db_hour": 0.15,
    "object_gb_month": 0.02,
    "egress_gb": 0.09,
}

def monthly(vms_small=0, vms_medium=0, dbs=0, stored_gb=0, egress_gb=0):
    return {
        "small VMs": vms_small * PRICE["small_vm_hour"] * HOURS_PER_MONTH,
        "medium VMs": vms_medium * PRICE["medium_vm_hour"] * HOURS_PER_MONTH,
        "database": dbs * PRICE["db_hour"] * HOURS_PER_MONTH,
        "object storage": stored_gb * PRICE["object_gb_month"],
        "data egress": egress_gb * PRICE["egress_gb"],
    }

normal = monthly(vms_small=2, dbs=1, stored_gb=200, egress_gb=500)
print("normal month (illustrative units)")
for item, cost in normal.items():
    print(f"  {item:15} {cost:9.2f}")
print(f"  {'total':15} {sum(normal.values()):9.2f}")

# Extra capacity for a 6-hour sale versus leaving it running all month
extra_per_hour = 4 * PRICE["medium_vm_hour"]
print()
print("4 extra medium VMs for a 6-hour sale :", round(extra_per_hour * 6, 2))
print("same 4 VMs left running all month    :", round(extra_per_hour * HOURS_PER_MONTH, 2))

normal month (illustrative units)
  small VMs           29.20
  medium VMs           0.00
  database           109.50
  object storage       4.00
  data egress         45.00
  total              187.70

4 extra medium VMs for a 6-hour sale : 1.92
same 4 VMs left running all month    : 233.6

The lesson is not the numbers but the shape. In this made-up model the database dominates the everyday bill, and the spike capacity is nearly free if it exists only for six hours but more expensive than the whole rest of the system if it is left on. That is the economic case for elasticity: pay for peak capacity only while you need it. It also shows what to question next: could the database be a smaller size outside the on-sale window, and is the egress figure realistic once the CDN absorbs most image traffic?

Common mistakes

• Treating object storage like a file system. Renaming a "folder" means copying every object, and appending to an object means rewriting it. Symptom: slow, expensive operations that would be instant on a disk.
• Storing sessions or uploads on the app server. Symptom: users get logged out or lose uploaded files when a request lands on a different instance, or whenever you scale in.
• Running a self-managed database on a VM "to save money". The cheaper hourly price ignores the engineer-hours for patching, backups and failover. Symptom: an untested restore procedure discovered during an outage.
• Choosing serverless for steady heavy load without checking the bill. Symptom: a function invoked millions of times a day costing more than a small container would.
• Sizing for the peak all month. Symptom: servers at five percent CPU nearly every day. Use autoscaling or scheduled scaling for known events such as an on-sale.

How this shows up in real projects and interviews

Interviewers ask "where would you store user-uploaded images?" (object storage with a database row pointing to it) and "when would you use serverless?" (spiky, event-driven, short-lived work). In real projects the best habit is to write a short architecture note, much like the diagram above, listing for each component why it is that type, what happens when it fails and roughly what it costs. Teams that do this catch the stateful-server and idle-capacity mistakes in review instead of in production.