The comment said which rule it came from, which section notified it, and that it could change without warning. That felt like a lot of ceremony for a two-digit integer — until I remembered the alternative.

In most software, a constant is a decision you made. In software that implements regulation, a constant is a decision someone else made, which they can change without telling you, and which has a legally correct value you may not be reading correctly in the first place.

I learned both halves of that the hard way, building a set of finance calculators. Here's what went wrong, and the three habits I now apply to any code that encodes a rule someone else owns.

This article is for developers who write code that implements rules somebody else owns, like tax, payroll, benefits, lending, or any domain where a regulator or standards body sets the numbers and can revise them without asking you. If you've ever hard-coded a rate that later changed, this is for you.

Prerequisites:

You'll need enough JavaScript and Go to read short snippets. Both appear below, but only as illustration. Nothing here depends on knowing either language deeply.

I don't assume any finance or tax background, and I'll explain every domain term where it first appears. The examples come from Indian GST because that's where I hit these bugs, but none of the three failure modes are specific to India, to tax, or to any one jurisdiction.

What We'll Cover:

• The Bug That Returns a Plausible Number

• The Constant That Changes While You Sleep

• The Validation That Lived in the Form

• The Three Habits

• Wrapping Up

The Bug That Returns a Plausible Number

Let's start with the worst kind, because it doesn't look like a bug at all.

In India, if you pay Goods and Services Tax late, you owe interest. The obvious implementation reads: take the tax owed, multiply by the annual rate, and scale by days late.

const interest = taxOwed * (ratePct / 100) * (days / 365);

That code is arithmetically perfect. It is also, in a large number of real cases, several times too high.

The reason is that "the tax owed" isn't one number. A GST return has a gross output liability: the total tax on everything you sold. But most businesses settle much of that with input tax credit, the tax they already paid on their own purchases. Only the remainder is paid in cash. And interest, under the rule that governs it, runs on the tax actually paid in cash, not on the gross liability.

So we have the same formula, same rate, and two different inputs. And one of them is wrong:

90 days late at 18% p.a.
  on cash actually paid   (₹50,000)    →   ₹2,219
  on gross liability      (₹3,00,000)  →  ₹13,315

Six times the interest. Both numbers are what the formula returns. Neither throws. Neither looks obviously absurd. If you're the developer, your tests pass, because you wrote the tests against the same misunderstanding as the code.

This is the failure mode that makes regulatory code different. A regular bug produces a stack trace, or a number so wrong that someone notices. This one produces a number that is the right shape, the right order of magnitude, and confidently incorrect.

What Actually Fixes it

A better test doesn't fix this. A better doc comment does.

The fix is to write down, at the definition site, which quantity the parameter means and where that requirement comes from:

// GSTInterest returns interest on a late GST payment.
//
// Under Rule 88B(1) interest runs on the tax actually debited from the
// electronic cash ledger — NOT on the gross output liability. Getting
// this wrong overstates the interest, often by several times. Pass
// cashTaxPaid as the cash-ledger portion, not the gross bill.
//
// Pass annualRatePct as DefaultGSTInterestRate unless the notified rate
// has moved; 18% p.a. is currently notified under Section 50(1).
func GSTInterest(cashTaxPaid float64, days int, annualRatePct float64) float64

Notice that the parameter is called cashTaxPaid, not amount. That name is the entire defense. A caller who has the gross bill in hand has to stop and ask whether it's the right number (which is exactly the pause that prevents the bug).

I'd go further: if a parameter can be confused with a similar quantity, the name should make the confusion impossible. amount invites the mistake. cashTaxPaid forbids it.

The Constant That Changes While You Sleep

The second failure mode is slower and more embarrassing.

Tax brackets move with the annual budget. Statutory ceilings get revised by notification. A gratuity limit sits at one figure for years and then doesn't. None of these changes care about your release schedule.

The tempting implementation is a constant:

const gratuityCeiling = 2000000

Now think about who's hurt by that. Not only the user reading a stale number, but also the developer who spots the change on a Tuesday, finds the value baked into a dependency, and can do nothing but file an issue and wait.

There's also a subtler problem. Statutory figures often aren't one value. They're one value for most people. The same ceiling is higher for certain government employees. The same minimum service period is shorter for fixed-term staff. A hidden constant isn't just potentially stale. It's silently wrong for an entire class of user, forever.

So: make statutory values options with documented defaults, never hidden constants.

// GratuityOptions carries the statutory figures that change by
// notification. The zero value means "use the defaults".
type GratuityOptions struct {
    Ceiling  float64 // 0 -> 20,00,000. Use 25,00,000 for Central Government civil employees.
    MinYears float64 // 0 -> 5. Use 1 for fixed-term employees.
}

The zero value still does the right thing for the common case, so nobody pays a complexity tax to get started. But the day the figure moves, a caller can correct it themselves – immediately, without waiting for me to cut a release.

That last clause is the real point. When your code encodes a rule you don't control, your users need an override that doesn't route through your release cadence.

The Validation That Lived in the Form

The third one caught me during a refactor, and it's the most transferable.

I had a function that builds a loan amortisation schedule: one row per month, stepping through the tenure. Inside an app, this was safe. The form had a max attribute. The UI clamped the input. Nobody could ask for a 200-year loan because the interface wouldn't let them.

Then I extracted the calculations into a library, and the form stopped existing.

rows, _ := Amortisation(principal, rate, months) // months came from where?

The loop is bounded only by the tenure it's handed. With a nonsense value, it doesn't return a wrong answer or run slowly. It just allocates until the caller's process dies. My bug, their out-of-memory crash, in a program I've never seen.

The fix is unglamorous: put the guard in the function.

const MaxMonths = 1200 // 100 years

rows, err := Amortisation(principal, rate, 2000)
// err: months must be at most 1200, got 2000

The ceiling is deliberately absurd. The longest home loan actually sold runs 30 to 40 years, so 100 years only ever fires on input that was never going to mean anything. That's the property you want in a guard like this: it should be impossible to hit by accident, so it never becomes a limit anyone argues with.

The general lesson is bigger than one function. When you extract a library out of an application, you inherit every input validation the UI was quietly doing for you, and you inherit it as someone else's crash.

The Three Habits

If you write code that implements rules you didn't write, there are three habits you should adopt now:

1. Name the Authority in the Doc Comment.

Not "the rate". Which rule, which section, and that it's subject to change. The comment above names Rule 88B(1) and Section 50(1) precisely so that anyone checking my work knows what to check it against, and so that a reader who disagrees can go and read the source rather than trusting me.

2. Make Statutory Values Options with Defaults, Not Constants.

The zero value handles the common case. The override handles the day the law moves, and the class of user the default was never right for.

3. Move the Guard from the Form to the Function.

Any validation the UI is doing is validation your library isn't. Assume the next caller has no UI at all.

None of this is exotic. It's the ordinary discipline of not trusting your inputs, applied to a domain where the definitions of the inputs are set by someone else and revised on their timetable.

The reason it's worth naming separately is that domain's specific failure signature: no exception, no stack trace, and no obviously wrong output. Just a number that's the right shape and six times too large, sitting quietly in a report that someone is about to act on.

Wrapping Up

Here's what this comes down to.

Code that implements regulation has a failure signature of its own: no exception or stack trace, just a number that looks right and is confidently wrong.

We saw it three ways: a parameter that silently meant a different quantity than the rule intends, a statutory value frozen into a constant that the law later moved, and validation that stayed behind in the UI when the logic was extracted into a library.

The three habits answer those three failures in order. Name the authority at the definition site, so the next reader knows what to check your work against. Expose statutory values as options with defaults, so the day the law moves you change an argument instead of hunting for a literal. And put the guard in the function, because the next caller may have no UI at all.

If you take one thing away, make it the naming. amount invites the bug. cashTaxPaid forbids it. And a parameter name is the cheapest documentation you will ever write.

Thanks for reading!

I build EMICalcs, a set of free finance calculators for India — loans, SIP, GST, gratuity and tax. The formulas above are extracted from it and published as an open-source library, so the arithmetic is auditable by anyone who wants to check my work.

But instead, it got measurably slower. Not subtly: an independent crawler that had flagged 38 slow pages before the change flagged 75 after it.

I reverted it the same day. This is what happened, why it happened, and the one calculation that would have told me not to bother before I deployed anything.

Table of Contents

• Prerequisites

• The Setup

• What I Changed

• The Result

• Why it Backfired, Part One: a MISS is Not Free

• Why it Backfired, Part Two: Crawlers Are Always Cold

• The Calculation I Should've Done First

• The Part That Stings

• A Technique Worth Keeping

• What I'd Tell You to Do Instead

Prerequisites

You don't need to have run a CDN before. But this will make more sense if you're comfortable with:

• What a CDN does at a high level: it keeps copies of your pages on servers around the world and serves each visitor from a nearby one.

• Basic HTTP caching headers: roughly what Cache-Control and max-age are for. I explain s-maxage and must-revalidate where they come up.

• Reading a curl command: every measurement in this article is a one-line curl you can run against your own site.

No Cloudflare-specific knowledge is assumed, and there's nothing to install. The core lesson is arithmetic, and it applies to any CDN.

The Setup

The site is a static Astro build: 77 HTML pages, no server-side rendering, and no database. It sits behind Cloudflare on the free plan, with an origin server in Navi Mumbai. Traffic is modest: roughly 9 visitors a day.

Google Search Console reported an average response time of 711 ms. Google's own guidance is 200 ms. That's 3.5× over, and it looked like an obvious problem with an obvious cause.

The cause was real: Cloudflare was caching none of the HTML:

$ curl -sI https://example.com/ | grep -i 'cache-control|cf-cache-status'
cache-control: no-cache
cf-cache-status: DYNAMIC

DYNAMIC means Cloudflare isn't caching the response at all. Every single HTML request (from every visitor and every crawler on earth) was traveling all the way to Mumbai.

The origin was sending Cache-Control: no-cache, which was a deliberate choice by past-me so that deploys would be visible immediately. Static assets (JS, CSS, fonts, and images) were cached fine. Only the HTML was passing through.

So: origin far away, HTML uncached, and a metric saying responses were slow. Cache the HTML at the edge and the problem goes away. Right?

What I Changed

I changed two things, in this order.

1. The origin header. From no-cache to:

Cache-Control: public, max-age=0, s-maxage=31536000, must-revalidate

This is a useful pattern worth knowing. max-age=0, must-revalidate means browsers revalidate on every request, so a deploy is instantly visible to users, exactly what no-cache guaranteed. But s-maxage applies only to shared caches, which lets a CDN hold the object for a year while browsers keep checking.

2. A Cloudflare Cache Rule. Here's a detail that surprised me: the header alone does nothing. Cloudflare won't cache extensionless HTML on the strength of your Cache-Control header. I verified this on a throwaway path rather than assuming it:

req 1: cf-cache-status: DYNAMIC
req 2: cf-cache-status: DYNAMIC
req 3: cf-cache-status: DYNAMIC

Five requests, with s-maxage set to a year, still DYNAMIC every time. You need an explicit Cache Rule marking the response eligible for cache. That's actually a useful property. It means you can ship the header change safely, well ahead of switching caching on.

With the rule deployed, it worked exactly as intended:

req 1: cf-cache-status: MISS
req 2: cf-cache-status: HIT
req 3: cf-cache-status: HIT

And it looked like a win. Time to first byte on a warm page dropped from ~0.28 s to ~0.17 s.

I was measuring from India. The origin is in India. Hold that thought.

The Result

The next crawl came back worse. Same site, same day, and the same 80 URLs:

Nearly double. I had made the exact metric I was trying to fix substantially worse.

Why it Backfired, Part One: a MISS is Not Free

The mental model I had was that caching is a coin flip between two outcomes: a HIT, which is fast, and a MISS, which costs the same as having no cache at all.

That second half is wrong. On a MISS, the CDN doesn't just proxy your response through. It has to store the object as it streams. That work costs something.

I measured it by purging the cache and then fetching the same pages two ways: through Cloudflare, and straight to the origin IP with --resolve.

# through Cloudflare, cache cold
curl -s -o /dev/null -w '%{time_starttransfer}' https://example.com/page

# straight to origin, bypassing Cloudflare entirely
curl -sk -o /dev/null -w '%{time_starttransfer}' --resolve example.com:443:203.0.113.10 https://example.com/page

Across six pages:

A cache MISS was ~85 ms slower than simply not caching. Which means every request that misses is now worse off than it was before I started.

Why it Backfired, Part Two: Crawlers Are Always Cold

A cache only pays off when the same URL is requested again while it's still cached, at the same edge location.

A crawler doesn't do that. It fetches each URL once.

I could verify this precisely, and the technique is worth stealing: if a request is served from the CDN's cache, it never reaches your origin. So the origin access log is a direct measurement of your miss rate.

grep -ic "crawler-user-agent" /var/log/nginx/access.log

During the crawl of 80 URLs, my origin logged **82 requests**. Every single page the crawler asked for was a miss. A 0% hit rate, and every one of those misses now carried the extra ~85 ms.

The same logic applies to first-time human visitors, who are also, by definition, arriving cold.

The Calculation I Should've Done First

Here's the whole thing, and it takes about a minute.

You have three numbers:

• H: time on a cache hit

• M: time on a cache miss

• B: your baseline, the time with no caching at all

Caching only wins when your average request beats the baseline:

h × H + (1 − h) × M  <  B

Solve for the hit rate h:

h  >  (M − B) / (M − H)

For my numbers:

h > (0.366 − 0.281) / (0.366 − 0.239)
h > 0.085 / 0.127
h > 0.67

I needed a 67% cache hit rate just to break even.

Now the reality check. 77 pages, and about 9 visitors a day, plus a search crawler refetching each page every few days. Call it 35 HTML requests a day, spread across 77 URLs and across many edge locations worldwide. And a full cache purge on every deploy.

The realistic hit rate is close to zero. I needed 67%.

The change was never going to work, and I could have known that before writing a line of config.

The Part That Stings

The diagnosis was correct. The origin genuinely is far from most of the traffic. The HTML genuinely wasn't cached. The 711 ms was real.

I just picked a fix without asking what fraction of requests would actually benefit from it.

And my verification made it worse, because I measured from a laptop sitting in the same country as the origin. Local curl timings said the change was a success. Only the external crawler – the thing that raised the issue in the first place – showed the regression.

So just make sure you verify against the metric that flagged the problem, not a proxy for it.

A Technique Worth Keeping

One piece of this survived the revert, and it's genuinely useful.

If you cache HTML at the edge, your deploy pipeline must purge that cache. And an API call returning "success": true isn't evidence the cache actually dropped anything. So don't trust it. Check.

LOCAL=$(shasum -a 256 dist/index.html | cut -d' ' -f1)
LIVE=$(curl -s https://example.com/ | shasum -a 256 | cut -d' ' -f1)

if [ "$LOCAL" != "$LIVE" ]; then
  echo "EDGE IS STALE — this deploy is not live" >&2
  exit 3
fi

That compares the bytes your CDN is actually serving against the bytes you just built. It's the difference between "the purge API said OK" and "the site is genuinely updated."

A related trap: if those hashes never match, suspect a feature that rewrites HTML at the edge (script optimizers, email obfuscation, auto-minification) before you suspect the cache.

Better still, don't hardcode the assumption that caching is on. Ask:

STATE=$(curl -sI https://example.com/ | tr -d '\r' | awk 'tolower($1)=="cf-cache-status:"{print $2}')

case "$STATE" in
  DYNAMIC|BYPASS) echo "HTML isn't cached; a missing purge is harmless" ;;
  *)              echo "HTML IS cached — a failed purge means this deploy is invisible" ;;
esac

Now the check corrects itself when someone toggles the cache rule, instead of quietly rotting.

What I'd Tell You to Do Instead

Calculate your break-even hit rate before you deploy. (M − B) / (M − H). If you can't plausibly reach it, stop.

Estimate your real hit rate honestly. Requests per day, divided across your URLs, divided again across edge locations, reset on every deploy. It's usually far lower than it feels.

Measure from where your users and crawlers actually are, not from the machine next to your origin.

Remember caching is a popularity bet. It rewards sites where the same URLs are requested repeatedly, in a short window. A high-traffic site would have won here comfortably. A 9-visitors-a-day site never could.

And if you're staring at a slow origin far from your audience, the honest answer might not be a cache at all. It might be moving the origin.

I write about the engineering behind Healthy Calculator Hub, a set of free health and fitness calculators — including, evidently, the optimizations that don't work.