Cost as a First-Class Constraint: FinOps for Architects
Reliability is non-negotiable, but “cost” is where architecture meets physics. This month is a practical playbook: how to model cost, allocate it, and design guardrails so your system scales without surprising invoices.
Axel Domingues
A system that “works” but bleeds money is still broken.
Not because finance is grumpy — but because cost shapes what you can safely ship:
- the features you can afford to run,
- the reliability budget you can afford to buy,
- and the scale you can survive without panic.
In practice, cost is a constraint just like latency or correctness.
So October is about making cost architectural instead of accidental.
This is the architect’s perspective:
- model the cost curve
- make it observable
- and put guardrails where systems tend to explode
The goal this month
Make cost predictable by design: unit costs, ownership, and guardrails.
The mindset shift
Cost is not an afterthought — it’s a runtime property of your architecture.
What I’m measuring
Unit cost ($/request, $/order, $/active user), plus the top 5 cost drivers.
What “good” looks like
You can answer: “If traffic doubles, what happens to the bill — and why?”
The uncomfortable truth: most cost incidents are architecture incidents
Cost spikes rarely come from “the cloud being expensive.”
They come from unbounded behavior:
- a retry storm that multiplies downstream traffic
- high-cardinality metrics that explode your observability bill
- a streaming pipeline without retention limits
- a data model that forces full scans
- chatty microservices with N× calls per request
- egress-heavy patterns (cross-region, cross-provider, public internet)
- “temporary” debug logs that became a firehose
Cost is a tail risk. Like latency, the mean is boring — the spikes are what hurt.
That’s the worst moment to touch your architecture.
Mini-glossary (as used in this post)
A cost expressed per business unit: $/order, $/1k requests, $/active user-month, $/GB processed.
If you don’t have a unit cost, you don’t have a cost model — you have a receipt.
Showback: attribute spend to teams/services for visibility.
Chargeback: actually bill teams (or budgets) for their spend.
Start with showback. Chargeback is an organizational choice, not a technical prerequisite.
Fixed: baseline you pay even at zero traffic (always-on services).
Variable: scales with usage (requests, GB, messages).
Accidental: spend caused by inefficiency or mistakes (debug logs, runaway queries, retries).
How many unique values a metric label can take.
High-cardinality labels (userId, requestId, URL with parameters) can blow up metrics/log costs.
A cost model architects can actually use
You don’t need perfect accounting.
You need a model that lets you reason about change.
I use a simple decomposition:
- Baseline spend (what you pay to exist)
- Unit cost (what you pay per business outcome)
- Growth curve (what happens as volume increases)
- Blast radius (where spend can become unbounded)
Here’s the key idea:
If you can express cost as “base + (units × unit_cost) + risk,” you can design.
Baseline
Always-on resources: minimum instances, databases, NAT gateways, control planes.
Unit cost
Per request/order/user. This is the number product teams can reason about.
Growth curve
Linear? Step function? Superlinear? Depends on architecture.
Blast radius
Unbounded behavior: retries, scans, cardinality, egress, retention.
Where cloud costs actually come from (and why architects should care)
Most cloud bills collapse into four buckets:
- Compute (CPU, memory, GPUs, “always-on” vs “per-invocation”)
- Storage (hot vs cold, backups, snapshots, retention)
- Network (especially egress and cross-zone/region traffic)
- Managed services (databases, queues, analytics, observability)
You can’t optimize what you can’t name.
So your first FinOps move is boring but powerful:
Build a “top spenders” map by service and by environment.
- spend by service
- spend by environment (prod vs non-prod)
- spend by tenant/customer (if B2B)
- top 10 cost deltas week-over-week
Architecture choices that change your cost curve
Here are the decisions that move your cost curve structurally (not cosmetically).
Every synchronous hop adds:
- compute on both sides
- network costs
- retries/timeouts
- tail latency amplification
- and often duplicated serialization/deserialization
The cost curve becomes more sensitive to traffic because one user action triggers many internal actions.
Mitigation patterns:
- coarse-grained APIs (BFF / aggregator)
- internal batching
- async fan-out via events where correctness allows
- caching with explicit invalidation rules
Retries are a cost multiplier.
A “small” error rate can become:
- 1 request → 3 requests
- then 3 services retrying each other → 9 requests
- then queues fill → more retries → more compute
Mitigation patterns:
- bounded retries + exponential backoff + jitter
- circuit breakers
- idempotency keys
- backpressure (reject early, degrade gracefully)
Cost spikes love:
- full table scans
- N+1 queries
- unindexed filters
- “just for now” analytical queries on production OLTP
Mitigation patterns:
- query budgets and limits
- read models (CQRS-style) for heavy reads
- move analytics to OLAP systems with controlled ingestion
- caching for expensive reads, with correctness rules
Logging and metrics are not free — they are managed services with pricing curves.
Common traps:
- logging every request body
- sampling turned off “temporarily”
- high-cardinality labels
- long retention by default
Mitigation patterns:
- sampling + dynamic sampling under incident mode
- log levels enforced by config + CI checks
- cardinality budgets
- retention by value (hot → warm → cold)
If you accidentally make your architecture “egress-heavy,” you’ve created a tax that scales with success.
Common traps:
- cross-region service calls for “simplicity”
- data replication without filtering
- CDN misconfiguration (cache misses everywhere)
- sending large payloads repeatedly instead of using object storage + signed URLs
Mitigation patterns:
- keep chatty traffic in-zone/region
- use CDNs and cache correctly
- compress payloads
- ship pointers (IDs/URLs) instead of blobs
The FinOps loop for architects (a playbook)
FinOps is a practice, not a one-off project.
What works is an operating loop:
Define your unit of value
Pick 1–3 business units your product cares about:
- order, quote, claim, document, message, active user, tenant
Write them down and stop debating. You can refine later.
Build “cost per unit” metrics
You need two ingredients:
- usage counters (orders/day, requests/day, messages/day)
- cost attribution (service spend)
Then compute:
- $/1k requests
- $/order
- $/active user-month
- $ per GB processed
Attribute ownership (showback)
Every major cost center needs an owner:
- a team, a platform group, a product area
No owner = no optimization.
Create guardrails (budgets, quotas, limits)
Examples:
- max log ingestion per service per day
- max message backlog
- max query runtime or scanned bytes
- max concurrency for expensive endpoints
Optimize the big levers first
Don’t “save 5%” by turning knobs.
Focus on cost multipliers:
- retries
- data scans
- cardinality
- egress
- always-on capacity
Operationalize: review, regressions, and alarms
A healthy system has:
- weekly cost review (30 minutes, not 3 hours)
- cost regressions flagged like performance regressions
- alerts on deltas, not just absolute thresholds
It’s preventing regressions.
Cost guardrails you can bake into architecture (without becoming a finance team)
You can embed cost safety into the system the same way you embed reliability safety.
1) Budget-based alerting (deltas beat thresholds)
Absolute thresholds are brittle.
What you want is:
- “spend is up 40% week-over-week”
- “log ingestion doubled after deploy X”
- “egress grew faster than traffic”
2) SLO-aware sampling for logs/traces
If your SLO is healthy, you can sample aggressively. If it’s degraded, sample less and increase detail temporarily.
That keeps observability useful and affordable.
3) Hard limits on unbounded dimensions
- cardinality budgets (metrics labels)
- retention limits (logs, events, snapshots)
- query limits (runtime, scanned rows/bytes)
- queue limits (max backlog before shedding load)
4) Environment hygiene
Non-prod is where cost discipline goes to die.
Rules that pay for themselves:
- nightly shutdown for dev/staging where possible
- TTL tags for “temporary” resources
- separate budgets by environment
- automated cleanup of orphaned resources
- service
- environment
- owner
- cost-center
A practical “Costed Architecture” worksheet
When I’m reviewing an architecture proposal, I ask these questions.
- What’s the minimum always-on footprint?
- What services require always-on capacity?
- What’s the cost of “being up” at zero traffic?
- What is the unit (order/user/request/message)?
- What is the estimated $/unit at current scale?
- Which components dominate that unit cost?
- What scales linearly with traffic?
- What scales stepwise (extra partitions, shards, replicas)?
- What can become superlinear (fan-out, scans, cardinality)?
- Where can retries multiply traffic?
- Where can storage/retention grow unbounded?
- What workloads can accidentally become analytical?
- Where can egress scale with success?
- Which limits exist (quotas, budgets, max concurrency, query limits)?
- What fails closed vs fails open?
- How does the system degrade under pressure?
Common cost anti-patterns (and the “adult supervision” fix)
“We’ll optimize later”
Later is when you’re busy and scared.
Fix: design the cost model now (baseline + unit cost + blast radius).
“It’s just logging”
Logs scale with traffic, retries, and payload size.
Fix: sampling, retention tiers, and enforce log levels.
“The database can handle it”
Databases handle it… until they don’t, and scaling is a step function.
Fix: query budgets, read models, caching, and OLAP separation.
“We need multi-region now”
Multi-region multiplies complexity and often cost (especially traffic replication).
Fix: make the reliability goal explicit, then choose the cheapest topology that meets it.
Resources
FinOps Foundation / FinOps Framework
A shared language for the practice: inform → optimize → operate, plus tooling and organizational patterns.
Google Cloud Pricing Calculator
Sanity-check “always-on” vs “serverless” and data/egress heavy designs.
FAQ
No. Cutting cost is sometimes a result, but the real win is predictability.
FinOps is about aligning engineering and finance around:
- unit costs
- tradeoffs
- ownership
- and guardrails
The goal is to scale without financial surprises.
Not at first.
Start with showback:
- attribution
- visibility
- ownership
Chargeback is an organizational lever. Visibility is the architectural prerequisite.
Almost always from multipliers:
- retry storms and timeouts
- observability firehoses
- wasteful non-prod environments
- unbounded data retention
- egress-heavy architectures
These wins are both cost and reliability wins — because they remove runaway behavior.
No. Serverless is great when:
- traffic is spiky
- you can tolerate cold-start constraints
- and you’ve bounded downstream costs
But always-on workloads with steady volume often favor:
- committed usage / reserved capacity
- predictable baselines
- fewer per-invocation overheads
The right answer is: pick the model that matches your traffic curve and operational needs.
What’s Next
October made cost explicit:
- unit economics instead of receipts
- ownership instead of blame
- guardrails instead of panic
Next month is the inevitable companion topic:
Incident Response and Resilience: Designing for Failure, Not Hope
Because the same systems that create latency spikes and outages… also create cost spikes.
The adult supervision move is the same:
Design for failure paths — and design for the bill you’ll get when those paths trigger.
Incident Response and Resilience: Designing for Failure, Not Hope
Most teams “have on-call”. Fewer teams have resilience. This is a practical blueprint for designing systems, teams, and workflows that respond fast, recover safely, and learn without blame.
Data Engineering for Product Teams: OLTP vs OLAP, Streaming, and Truth
Most “data problems” are actually truth problems. This month is a practical mental model for product teams: where truth lives, how it moves, when to stream, when to batch, and how to keep analytics useful without corrupting production.