Module 01 · Lesson 12 of 14Free

Cost-aware design: avoiding unnecessary infrastructure

Level

Intermediate

Topic

System design fundamentals

Reading time

18 min

Kartly’s app server shows about 3% CPU usage during normal traffic. Someone proposes halving its size to save ₹3,000 a month, just before the festival sale.

At the sale’s opening, that smaller server would receive more CPU work than it could finish.

How do you reduce infrastructure cost without removing capacity or safeguards the product actually needs?

Count the whole workload

Kartly remains at its one-server stage: one app server with 8 CPU cores and one PostgreSQL database. It handles about 50 requests a second normally. The festival’s first minute reaches 1,000 requests a second.

Before comparing machines, draw a boundary around the costs you mean. Otherwise, moving work can look like saving money.

Here is an illustrative monthly budget. These amounts are assumptions for this lesson, not provider prices.

The app server is not even half the bill. Removing half its cost cannot halve the workload’s cost.

This table excludes payment-provider fees, taxes and staff time. Those exclusions make the model narrower, not wrong. Record them so nobody mistakes infrastructure cost for total business cost.

AWS recommends attributing spending to workloads and comparing it with the business output they deliver. That is a better starting point than comparing individual machine prices.^{1Design principlesAmazon Web Services, AWS Well-Architected Framework: Cost Optimization Pillar}

The boundary tells you what to count. You still need to know what makes each amount grow.

Turn actions into billable usage

A cost model connects product behavior to quantities, then quantities to charges.

Capacity estimation provides the usage estimates. Here, attach a billing rule to each estimate.

Some costs are fixed within a chosen allocation. Others change with usage. A third group changes in steps when you cross a capacity limit.

Lower CPU usage does not reduce a fixed server rental. It creates an opportunity to choose a smaller allocation, if that allocation still meets requirements.

For outbound delivery, suppose Kartly sends 250 GB of billable data in the month. Assume a flat rate of ₹8 per GB.

Do not equate that quantity with all application traffic. Measure which bytes the billing boundary includes. Images, API responses and internal calls may have different charging rules.

A billing record should therefore carry a quantity, unit, rate and scope. “250 GB of outbound delivery” is useful. “Network: ₹2,000” gives you less to investigate.

Next, connect the total to something customers successfully achieve.

Price a useful product outcome

Kartly receives 5,000 orders a day at this course stage. For this calculation, assume a 30-day month with the same daily volume.

This is a unit cost: cost divided by a useful unit of output. It helps separate healthy growth from declining efficiency.

Suppose next month’s bill rises to ₹26,000. If Kartly records 200,000 orders, the allocated cost is ₹0.13 per order. The total increased, but this measure of efficiency improved.

That does not prove the change caused the improvement. Traffic mix, promotions and order conversion may also have changed.

Nor does ₹0.15 mean one extra order costs ₹0.15. The existing server might handle it without a larger allocation. The average cost allocates shared spending; the extra cost of another order can differ.

Choose the denominator carefully. Cost per request can improve when a bug generates more requests without helping anyone. AWS’s efficiency guidance focuses on business output for this reason.^{1Design principlesAmazon Web Services, AWS Well-Architected Framework: Cost Optimization Pillar}

Now the opening proposal has a clearer goal: reduce the bill without reducing successful outcomes.

Idle capacity can be necessary

The proposal relies on a common belief: low average CPU usage means the server is too large.

Kartly’s product-page request uses about 5 ms of CPU work. Its database and pricing waits are separate from that CPU time, as covered in Server concurrency.

For this simplified capacity check, assume every request has that CPU cost.

This is a lower-bound resource check, not a benchmark. It does not prove the larger server meets response-time targets. The database, memory and connection limits still matter.

Vertical and horizontal scaling covers the capacity mechanisms. Cost analysis decides whether their benefit justifies using them.

Resource choices should follow workload patterns and environment requirements, rather than one utilization number. Google Cloud’s guidance makes that distinction explicit.

Capacity protects a known peak. Unbounded data growth needs a different control.

Bound data before adding storage

Assume Kartly generates 2 GB of diagnostic logs daily. The current policy keeps them searchable for 90 days.

These are additional scenario assumptions. The calculation concerns diagnostic logs, not order records or backups.

The simplest implementation is a retention policy in the logging service. It expires data after the chosen age. The team should verify that expired data stops contributing to the relevant storage charge.

Choosing 14 days requires a product and operations answer: how far back must the team investigate failures? If support regularly investigates older incidents, shorter searchable retention may remove evidence they need.

An alternative is a short searchable window plus a longer archive. It trades cheaper storage for retrieval delay and retrieval charges. Compare the expected retrieval workload before choosing it.

For this scenario, choose shorter retention only after the team confirms its investigation needs. Keep order records, security records and backups under their own policies.

Microsoft recommends removing unnecessary data and resources as part of ongoing optimization. That guidance does not decide which Kartly records are unnecessary; the requirements do.^{3Cost Optimization design principlesMicrosoft, Microsoft Azure Well-Architected Framework}

A smaller stored volume is a measurable saving opportunity. Whether implementing it is worthwhile depends on the work it creates.

Include the team’s operating work

Suppose someone proposes replacing a managed logging service with a self-operated one. Assume the infrastructure saving would be ₹3,000 a month.

The replacement also needs upgrades, access controls, recovery procedures and someone responsible when searches stop working.

Microsoft’s cost model includes implementation, support and operational expenses, not only resource charges.^{3Cost Optimization design principlesMicrosoft, Microsoft Azure Well-Architected Framework}

Engineering time is not always an extra invoice. It is still time unavailable for checkout fixes or customer features. State that opportunity cost separately from cash spending.

Avoid treating unknown operating work as zero. List the work, name its owner and estimate a range.

Before implementing any saving, write a short decision record:

• What amount should fall, and why?
• What implementation and recurring work will appear?
• Which product targets must remain unchanged?
• What measurement would make us undo the change?

That record turns a price comparison into a decision you can review.

Make cost changes reversible

Cost work starts with the product requirements from Functional and non-functional requirements. A cheaper design that misses those requirements is not an equivalent design.

For each experiment, pair a cost measurement with a user-facing measurement.

Start with a limited change where possible. Compare equivalent workloads, rather than a quiet weekday against a festival launch.

Keep the previous configuration available. If response time or errors worsen beyond the agreed target, restore it and investigate.

Review forecast spending before month-end. In this scenario, the team chooses a ₹25,000 monthly infrastructure budget and assigns an owner to investigate forecast overruns. An alert starts a review; it is not a reason to stop accepting orders.

Google Cloud recommends different resource choices for production and development environments. Kartly could stop an unused development environment overnight without applying the same policy to its store.

Where this shows up

• Design: a fast product catalog page: compare added infrastructure with the database work and delivery cost it removes.
• Design: monitoring and SLOs for a service: connect operating measurements to the requirements cost changes must preserve.

The next lesson applies this restraint to a URL shortener on a single server: which requirements actually justify another component?

Common mistakes

Optimizing the most visible line. The app server may be easy to resize, but another cost may dominate. Rank opportunities by expected net benefit.

Buying future capacity without a trigger. “We might grow” gives no decision boundary. Name the workload or requirement that would justify the purchase.

Counting a discount as lower usage. A lower rate can reduce spending without improving resource efficiency. Track quantity and rate separately.

Removing safeguards to meet a budget. Backups and recovery capacity serve requirements. Renegotiate those requirements explicitly instead of silently weakening them.

Check your understanding

Summary