System Design - lesson 6 | HackIndia Skills

Key point

One idea

Scale up means use a bigger machine. Scale out means use more machines or more instances.

In your hackathon design, do not say “it scales” without naming the bottleneck. Say what gets bigger, what gets copied, and what can break.

When to scale up

Scale up first when one service is simple, traffic is low, and you want fewer moving parts. For a college hackathon demo, this is often enough for your backend or database.

Example: move from a small free database to a paid plan with more RAM, CPU, storage, or connections. The trade-off is cost and a hard limit. One large machine can still fail.

When to scale out

Scale out when many similar requests can be handled by copies of the same service. API servers are usually easier to scale out than databases.

Example: run two backend instances behind a load balancer. Each instance should be stateless. Store sessions, uploads, and jobs outside the server instance.

Common mistake

Do not scale out a stateful server that keeps login sessions or in-memory carts without a plan. Users may hit instance A once and instance B next time.

Fix it by storing session data in a shared store, using JWT carefully, or keeping state in the database or cache. Then any instance can answer the request.

Example

Show it in config

For a Node or Python API, your project can read a port from the environment. This lets you run multiple copies locally or deploy replicas on a platform.

This is not the full load balancer setup. It is proof that your app is ready to run as more than one instance.

PORT=3001 node server.js
PORT=3002 node server.js

# In your design notes:
# Client -> Load balancer -> API instance 1 / API instance 2
# API instances are stateless.
# Database stores users, orders, and submissions.
# Redis cache stores hot reads, not source-of-truth data.

Your to-do

Choose your path

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Find one bottleneck: API CPU, database reads, file uploads, image generation, or slow third-party calls.
Pick scale up if one bigger plan solves it with less complexity.
Pick scale out if the work is repeatable and safe across multiple instances.
Write the limit: cost, failover, data consistency, connection limits, or deployment complexity.
Draw only the scaled part. Keep the rest of the diagram simple.

0 of 5 done

Tip

Use AI carefully

Ask an AI tool to challenge your scaling choice. Give it your app flow and ask: “What breaks if I run 3 API instances?”

Check the answer for real issues: sessions, file storage, background jobs, database connections, cache invalidation, and duplicate queue processing. Do not copy vague lines like “use Kubernetes” unless you actually use it.