DEV Community: John Ayodele

The Circuit Breaker Pattern: Stopping Cascading Failures in Microservices

John Ayodele — Fri, 02 Oct 2026 17:50:26 +0000

If you run more than a handful of services that call each other over the network, you have probably seen this failure mode: one service gets slow or starts timing out, and instead of staying contained, the problem spreads. Threads pile up waiting on responses that never come, queues back up, and eventually services that had nothing wrong with them start failing too, because they were busy waiting on the one that did. This is a cascading failure, and the circuit breaker pattern is the standard tool for stopping it.

The problem: slow failures are worse than fast ones

A service that returns an error immediately is usually fine. Callers catch it, maybe retry, maybe degrade gracefully, and move on. The dangerous case is a service that is slow to fail, or that fails intermittently under load.

Say service A calls service B, and B's database is struggling, so B takes 20 seconds to respond instead of 200 milliseconds. Every request from A to B now holds a connection, a thread, or an event loop slot for 20 seconds. If A has a limited pool of workers (and it does), that pool fills up with requests stuck waiting on B. Soon A cannot serve any requests at all, including ones that have nothing to do with B. Now A looks down to its own callers, and the problem spreads one hop further.

This is how a single struggling dependency turns into a full outage. The fix is not to make B faster (you often cannot, in the moment). The fix is to stop calling B once it is clear that calls to B are not going to succeed.

How a circuit breaker works

A circuit breaker wraps a call to a dependency and tracks whether recent calls have been succeeding or failing. It behaves like an electrical circuit breaker: it sits in the path of the call, and it trips open when something downstream is going wrong, cutting the connection before the damage spreads further upstream.

It has three states:

Closed is the normal state. Requests flow through to the dependency as usual. The breaker counts failures (timeouts, errors, or both, depending on configuration) within a rolling window.

Open is the tripped state. Once failures cross a threshold (for example, more than 50 percent of calls failing over the last 20 calls, or 5 consecutive timeouts), the breaker opens. While open, calls to the dependency are not attempted at all. The breaker returns an error immediately, or falls back to a default response, without touching the network. This is the key benefit: callers stop waiting on a dependency that is not going to answer, and they stop consuming resources doing it.

Half-open is the recovery check. After a cooldown period, the breaker allows a small number of test requests through. If they succeed, the breaker closes again and normal traffic resumes. If they fail, it goes back to open and waits for another cooldown.

The effect is that a failing dependency gets isolated quickly, and the system periodically checks whether it has recovered, without hammering it with full traffic while it is still unhealthy.

Circuit breakers are not the same as retries

It is worth being explicit about this because the two are often used together and sometimes confused. A retry handles a single request: if it fails, try again, maybe with backoff. A circuit breaker handles a pattern across many requests: if enough recent calls have failed, stop making new ones for a while.

Used together, they complement each other. A request might retry two or three times with backoff, and if those retries are also failing across many different callers, the circuit breaker trips and stops the retries from compounding the load on the struggling service. Retrying without a circuit breaker on a dependency that is down can make things worse, because now every caller is sending multiple requests instead of one, adding load to a service that already cannot keep up.

What to put behind a breaker, and what to do when it trips

Not every call needs a circuit breaker. It matters most for calls to external dependencies you do not control directly: other internal services, third-party APIs, databases under heavy load. Calls that are cheap, local, and reliable usually do not need one.

When a breaker is open, the calling code needs a plan for what to do instead of the normal response. Common options:

Return a cached or default value. If a recommendations service is down, show no recommendations instead of failing the whole page.

Degrade the feature. If a pricing service is down, show a product page without real time pricing instead of refusing to load the page at all.

Fail the specific operation, not the whole request. If checkout calls both an inventory service and a loyalty points service, and loyalty points is open, let the checkout proceed without applying points rather than blocking the purchase.

Queue the work for later. For non urgent operations, write to a queue and process once the dependency recovers, instead of blocking the caller.

The right fallback is specific to what the feature means to the user, which is why circuit breakers are usually implemented in application code or a shared library, not purely at the infrastructure layer.

Where it lives in practice

You rarely need to hand write a circuit breaker from scratch. Most ecosystems have mature libraries: resilience4j for Java, Polly for .NET, opossum for Node.js, and pybreaker for Python. Service mesh tools like Istio and Linkerd can also apply circuit breaking at the network layer, which is useful for stopping traffic between services without changing application code, though it is coarser than an application level breaker that can choose a meaningful fallback.

Whichever layer you implement it at, the configuration choices that matter are the failure threshold (how many failures before tripping), the window size (how many recent calls to consider), and the cooldown duration (how long to wait before testing recovery). Set the threshold too low and healthy services trip under normal blips. Set it too high and the breaker does not protect anything until the damage is already done. These numbers are usually tuned from observed latency and error rates for each specific dependency, not set once globally.

Rate Limiting Algorithms: Token Bucket vs Sliding Window Explained

John Ayodele — Wed, 30 Sep 2026 06:29:03 +0000

Every public API eventually needs a way to say "not so fast." Without it, one misbehaving client, a retry loop gone wrong, or a scraper can consume enough capacity to slow the service down for everyone else. Rate limiting is the mechanism that enforces a cap on how many requests a client can make in a given period, and the algorithm you pick decides how fair, how bursty, and how expensive that enforcement actually is.

Two algorithms show up in almost every real system: token bucket and sliding window. They solve the same problem but make different tradeoffs, and picking the wrong one for the situation shows up later as either angry customers getting blocked unfairly or a service that never really protects itself.

Why rate limiting exists in the first place

A rate limit protects three things at once: the backend's own capacity, other tenants sharing that capacity, and, less obviously, the calling client itself. A client that's about to exceed a limit is often about to make things worse for itself too, retrying failed requests in a loop, burning through a budget, or hammering a downstream service it doesn't realize is struggling.

Limits are usually expressed as "N requests per period," like 100 requests per minute. The simplest possible implementation, a fixed window counter that resets every 60 seconds, has an obvious flaw: a client can send 100 requests in the last second of one window and another 100 in the first second of the next, producing 200 requests in roughly two seconds even though the stated limit is 100 per minute. Both token bucket and sliding window exist to close that gap.

The token bucket algorithm

A token bucket holds a fixed number of tokens, refilled at a steady rate, say one token every 600 milliseconds for a 100-per-minute limit. Every incoming request consumes one token. If a token is available, the request goes through and the count drops by one. If the bucket is empty, the request is rejected or delayed until the next token arrives.

The useful property here is that the bucket can hold unused tokens up to its capacity, which means a client that's been idle can send a short burst of requests immediately, then settle into the steady refill rate. This matches how real traffic actually behaves: a dashboard that loads ten resources at once on page load, then goes quiet. Token bucket tolerates that burst without needing a special case for it.

The tradeoff is that token bucket is a smoothing model, not a precise historical count. It doesn't answer "how many requests happened in the last 60 seconds," it answers "is there capacity available right now," which is a different (and usually more useful) question for protecting a backend, but a worse fit if the actual requirement is a hard, auditable cap like "this API key gets exactly 10,000 calls a day."

The sliding window algorithm

Sliding window fixes the boundary problem in fixed windows by looking at a rolling period instead of a fixed calendar-aligned one. Instead of asking "how many requests since minute 0," it asks "how many requests happened in the last 60 seconds, starting from right now."

There are two common ways to implement it. A true sliding log keeps a timestamp for every request and counts how many fall inside the trailing window, which is accurate but can get memory-heavy under high request volume. A sliding window counter approximates this cheaply: it keeps two fixed window counters (the current one and the previous one) and computes a weighted count based on how far into the current window the request landed. That weighted approach is what most production systems, including common Redis-based rate limiters, actually implement, because it gets very close to the true sliding log at a fraction of the storage cost.

Sliding window's strength is precision and fairness across the boundary, it closes the fixed-window loophole directly and gives an answer that matches what a person means by "100 requests per minute." Its weakness is that it doesn't naturally allow the same kind of burst tolerance that token bucket gives for free. A client that's been well under its limit for an hour gets no credit for that when a burst arrives.

Comparing the two in practice

Token bucket tends to fit situations where short bursts are normal and desirable, API gateways protecting infrastructure, client SDKs pacing their own outbound calls, or anywhere the goal is smoothing traffic rather than producing an exact count. Sliding window tends to fit situations where the limit is a contractual or billing-relevant number, like a per-plan API quota that needs to be enforceable and explainable to a customer who asks why they got a 429.

Neither algorithm is inherently "more correct." A payments API and an internal caching layer within the same company might reasonably choose different ones for the same nominal limit, because they're actually solving different problems: one is protecting shared infrastructure from spikes, the other is enforcing a plan boundary a customer agreed to.

Where enforcement actually lives

Rate limiting can sit in a few different places, and where it sits changes what's practical. At the API gateway or edge (a service like Cloudflare, or a reverse proxy), it protects the backend before a request even reaches application code, which is the right place for coarse, infrastructure-protecting limits. Inside the application, backed by a shared store like Redis, it can enforce per-user or per-API-key limits with either algorithm, since Redis makes atomic increment-and-check operations cheap and the same counters are visible across every application instance. Purely in-memory, per-process limiting is the least reliable option in any system running more than one instance, because each instance ends up enforcing its own separate limit rather than a shared one.

Whichever layer enforces the limit, the response matters as much as the algorithm. A 429 status code with a Retry-After header, or the increasingly standard RateLimit response headers, tells a well-behaved client exactly when to try again instead of forcing it to guess and retry blindly, which is itself a good way to accidentally cause the exact overload the limit was meant to prevent.

Choosing between them

A reasonable default: use token bucket when the goal is protecting a system from spiky traffic and bursts are actually fine, and use sliding window when the limit needs to be precise, explainable, and tied to something like a pricing plan or contractual quota. Plenty of systems end up combining the two: a fast token bucket at the edge to absorb spikes, and a sliding window count further in to enforce the account-level quota that shows up on an invoice.

Why Your App Shows Stale Data Right After a Write: Understanding Read Replica Lag

John Ayodele — Fri, 25 Sep 2026 13:58:04 +0000

The Bug That Isn't a Bug

A user updates their profile, hits save, gets redirected to their profile page, and sees their old name still sitting there. They refresh. Now it's correct. No error was thrown, nothing crashed, and the data was never actually lost. This is one of the most common "phantom bugs" reported against systems that use database read replicas, and it isn't really a bug at all. It's the expected behavior of an architecture that most engineers add for scaling reasons without fully accounting for its consistency tradeoffs.

How Replication Actually Works

Most relational databases (Postgres, MySQL, and their managed cloud equivalents) scale read traffic by running one primary node that accepts writes and one or more replica nodes that only serve reads. The primary streams a continuous log of changes, called a write-ahead log (WAL) in Postgres or a binlog in MySQL, to each replica. The replica applies those changes in order and stays a live copy of the primary.

The important detail is that this streaming happens over the network, asynchronously by default. The primary doesn't wait for a replica to confirm it received and applied a change before telling the client the write succeeded. That handoff is fast, usually single-digit milliseconds, but it is never zero. During that gap, the replica is technically behind the primary. That gap is replication lag.

Why the Lag Happens

Lag isn't a sign of misconfiguration. It's inherent to asynchronous replication, and it grows under a few predictable conditions: network latency between the primary and replica (worse across availability zones or regions), a replica that's under heavy read load and can't apply incoming changes fast enough, long-running transactions or large batch writes that take time to replicate and replay, and vacuum or maintenance operations competing for I/O on the replica.

Under normal conditions, lag might sit around 10 to 50 milliseconds. Under load or during a large migration, it can stretch to seconds, and in unhealthy setups, minutes. The application code usually has no idea any of this is happening. It just issues a read query to whatever connection pool routes to the replica, and gets back whatever the replica currently has.

The Classic Symptom: Read Your Own Write

The failure mode almost every team eventually hits is called read-after-write inconsistency, sometimes shortened to "read your own writes." The sequence is: a client writes to the primary, the write is acknowledged, the client immediately issues a read (often as part of returning a confirmation page or an API response), that read gets routed to a replica, and the replica hasn't caught up yet.

This is especially visible in write-then-redirect flows: submitting a form and being sent to a page that reloads the data, submitting a comment and not seeing it appear in the same request, or updating a setting and having the UI briefly flash the old value. None of this shows up in a typical staging environment, because the lag there is usually near zero and load is low. It tends to surface in production exactly when you have enough traffic to need read replicas in the first place, which makes it a frustrating one to reproduce and debug.

Fixing It: Four Practical Patterns

Teams generally reach for one of a handful of approaches, and most production systems end up combining two or three of them.

Route reads to the primary right after a write. The simplest fix: for a short window after a user's own write (often just for that request, or for a few seconds via a session flag), force reads for that user back to the primary instead of a replica. This is often called "read your own writes" routing and is the most common fix because it requires no schema changes, only routing logic in the application or ORM layer.

Use monotonic or "sticky" read consistency. Instead of routing every read to a random replica, pin a user's session to a single replica for a request lifecycle, or track the log sequence number (LSN) their last write produced and only route their next read to a replica that has caught up past that LSN. Postgres exposes this via functions like pg_last_wal_replay_lsn(), and some managed services (Aurora, for instance) expose similar mechanisms natively.

Return the written data directly instead of re-reading it. If a write handler already has the row it just inserted or updated, the simplest fix is often to hand that data straight back in the response rather than issuing a fresh SELECT against a replica at all. This sidesteps the consistency problem entirely for the common case of "show the user what they just saved."

Accept eventual consistency where it's genuinely fine. Not every read needs strong consistency. A public dashboard, an analytics view, or a activity feed that's a few hundred milliseconds behind is usually an acceptable tradeoff for the read scalability replicas provide. The key is being deliberate about which reads need freshness guarantees and which don't, rather than treating all reads the same.

Monitoring Lag Before It Becomes a Support Ticket

Because this failure is intermittent and load-dependent, it's worth tracking replication lag as a first-class metric rather than discovering it through user complaints. Postgres exposes lag directly through the pg_stat_replication view on the primary, and managed services like AWS RDS and Aurora surface a ReplicaLag CloudWatch metric out of the box. Alerting on lag crossing a threshold (say, 500ms sustained) gives you a warning before it turns into a wave of "my changes didn't save" tickets.

The underlying lesson is that read replicas trade strong consistency for read throughput, and that tradeoff needs to be a conscious decision made at the point where reads happen, not an assumption baked in silently by the connection pool.

Why Serverless Functions Keep Exhausting Your Postgres Connections

John Ayodele — Mon, 21 Sep 2026 18:36:53 +0000

The Problem

Serverless functions scale by running many short-lived instances in parallel, and each instance that touches Postgres wants its own database connection. That's fine at low concurrency. It falls apart the moment traffic spikes, because Postgres doesn't scale connections the way it scales queries.

A default Postgres install caps out at 100 connections, and managed databases often set the limit lower once you account for connections reserved for replication, monitoring, and admin access. A burst of 300 concurrent Lambda or Vercel function invocations, each opening its own connection, will blow past that limit in seconds. The failure mode isn't a slow query. It's a flat "too many connections" error, and it usually shows up first in production, under load, not in a staging environment running at a tenth of the traffic.

Why More Connections Isn't the Answer

The instinct is to raise max_connections. That works until it doesn't. Every open Postgres connection holds its own backend process and memory footprint (parsed query plans, temp buffers, session state) whether or not it's doing anything. Push the limit high enough to absorb serverless concurrency and you're now paying for idle memory most of the time, with a database that becomes fragile exactly when it's under the load you sized for.

The deeper issue is architectural. Traditional connection pooling, a pool held in application memory and reused across requests, assumes a long-lived process. Serverless functions are the opposite: short-lived, frequently cold-started, with no shared memory between invocations. Each instance either opens a fresh connection or, worse, leaks one that never gets cleaned up when the instance is recycled.

How an External Pooler Fixes It

The fix is to stop pooling in the application and pool in front of the database instead. A connection pooler, such as PgBouncer, Supabase's Supavisor, or a managed equivalent like AWS RDS Proxy, sits between your functions and Postgres as its own persistent process. It accepts a large number of client connections and multiplexes them onto a small, fixed set of backend connections to the database.

That gives you two independent limits to reason about instead of one: how many clients can connect to the pooler, and how many backend connections the pooler holds open to Postgres. The pooler absorbs the serverless side's churn, connections opening and closing constantly, without that churn ever reaching the database itself.

What You Lose in Transaction Mode

Most poolers default serverless deployments to transaction-mode pooling, where a backend connection is only checked out for the duration of a single transaction and returned to the pool immediately after. It's the mode that makes pooling actually work under high concurrency, but it isn't free.

Because a client's next transaction can land on a completely different backend connection, anything that depends on session state stops working reliably: prepared statements, SET-based session variables, LISTEN/NOTIFY, advisory locks, and temp tables all assume a stable connection across statements. If your ORM prepares statements by default, and several do, you'll either need to disable that behavior or confirm your pooler and driver combination handles it (some, including recent Supavisor and PgBouncer versions, support limited prepared-statement compatibility in transaction mode). This is the detail that turns "add a pooler" from a one-line config change into something worth testing under real load before it ships.

Picking a Pooler and Sizing It

Which pooler makes sense depends on where you're already hosted. If you're on Supabase, Supavisor is the built-in option and requires no extra infrastructure. On AWS, RDS Proxy integrates directly with Lambda and IAM auth. Running your own Postgres, PgBouncer remains the standard, self-hosted choice. Prisma users have Prisma Accelerate as a managed alternative that adds caching on top of pooling.

However you deploy it, don't size the backend pool by guessing. A widely used starting formula is (CPU cores × 2) + effective disks, which reflects that Postgres throughput is bounded by how much work the database server can actually parallelize, not by how many clients are waiting. Oversizing the pool doesn't add capacity, it just adds contention. Start conservative, watch pool wait time in your metrics, and size up only when wait time, not connection count, tells you to.

Idempotency Keys: Making Payment APIs Safe to Retry

John Ayodele — Sun, 20 Sep 2026 17:17:49 +0000

Every API call over a network can fail in a way that tells you nothing. The request might never have reached the server. It might have reached the server, been processed successfully, and then the response got lost on the way back. From the client's point of view, both look identical: a timeout.

The natural instinct is to retry. For a search query, that's harmless, worst case you run the same read twice. For a payment, a signup, or anything that changes state, a naive retry can charge a customer twice, send a duplicate email, or create two identical orders from one click. Idempotency keys are the standard fix, and they show up in almost every serious payments API for a reason.

The core idea

An idempotency key is a unique value the client generates and attaches to a request, usually as a header, like Idempotency-Key: 8f14e45f-ceea-467e-bd53-.... The server uses that key to recognize "I've seen this exact request before" and, instead of processing it again, returns the same result it returned the first time.

The client doesn't need to know whether its earlier request succeeded, failed, or is still in flight. It just retries with the same key, and the server guarantees the underlying operation happens at most once.

This is different from an operation simply being idempotent in the mathematical sense (like PUT, which is supposed to produce the same end state no matter how many times you call it). A POST /charges call is never naturally idempotent, calling it twice should, by default, create two charges. An idempotency key is what lets you bolt idempotent behavior onto an inherently non-idempotent operation.

What happens on the server

A typical implementation looks like this:

When a request arrives with an idempotency key, the server checks a store (usually a database table or a fast key-value store) for that key.
If the key isn't there, the server records it, marks it "in progress," processes the request normally, then stores the response body and status code against that key.
If the key is there and the original request finished, the server returns the stored response immediately without re-running any of the business logic.
If the key is there and the original request is still in progress (a second request arrived while the first was mid-flight), the server should reject or hold the second request rather than let both proceed concurrently. Otherwise you get a race that idempotency keys were supposed to prevent in the first place.

Stripe's implementation is a good reference point: it stores the key alongside a hash of the request parameters, the response, and the status, and reuses that response for up to 24 hours on a matching key.

Handling the edge cases

A few details separate a correct implementation from one that just looks correct in the happy path:

Same key, different payload. If a client sends the same idempotency key with a different request body than before, that's almost certainly a bug on the client side: reusing a key across unrelated requests. Most APIs treat this as an error rather than silently processing the new payload, since guessing which version the client "really" meant is worse than failing loudly.

Concurrent requests, same key. Two requests with the same key can genuinely arrive at nearly the same time, for example, a mobile client retries after a slow response that eventually does arrive. The server needs some form of locking or a unique constraint at the database level on the key column so that only one of the two ever executes the underlying logic; the other should wait and then return the first one's result.

Expiration. Keys shouldn't live forever. Stripe expires them after 24 hours; other systems use shorter or longer windows depending on how long a client might realistically retry. Whatever the window, it needs to outlast the client's own retry logic, or a legitimate retry after the key expires will double-process.

Where the key comes from. The client should generate the key once, before the first attempt, and reuse the exact same value on every retry of that same logical operation, not generate a new key per HTTP call. A UUID v4 generated at the point the user clicks "submit" is the usual pattern.

Beyond payments

Idempotency keys aren't only useful for charging a card. The same pattern applies anywhere a retry could duplicate a side effect: webhook delivery (many providers, including Stripe and GitHub, recommend deduplicating incoming webhooks by event ID for the same reason), message queue consumers that might redeliver a message, and background job systems where a worker crash mid-task could cause a job to run twice. Anywhere "at-least-once delivery" meets "this operation has a side effect," idempotency keys (or the same idea under a different name) tend to show up.

There's also now a proposed IETF standard (draft-ietf-httpapi-idempotency-key-header) working to formalize the Idempotency-Key header across APIs generally, rather than leaving every provider to define its own semantics. It's still a draft, but it's a sign the pattern has moved from "a good idea a few payment companies do" to something closer to a general HTTP convention.

What the Model Context Protocol Actually Is (and Why It Became the Standard)

John Ayodele — Mon, 14 Sep 2026 10:48:32 +0000

MCP gets mentioned in almost every AI engineering conversation right now, but rarely explained plainly. Here's what the protocol actually does, how it works under the hood, and why nearly every major AI vendor ended up adopting it within about a year.

The problem it was built to solve

Every AI model is, by default, isolated. It can reason well, but it can't see your database, read your files, check today's weather, or send a message on your behalf unless someone builds a custom bridge for that specific combination of model and tool. Before late 2024, that bridge had to be built separately for every pair: one integration for Model A talking to a CRM, a different one for Model B talking to the same CRM, and another for Model A talking to a different database. Vendors and developers were rebuilding the same plumbing over and over, and it didn't scale as the number of models and tools grew.

What MCP actually is

The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that gives AI applications one common way to connect to external data and tools instead of a custom integration for each pair. It's often compared to USB-C: instead of a different cable for every device, you get one connector that works across vendors. Anthropic donated the protocol to the Agentic AI Foundation, part of the Linux Foundation, in December 2025, which is part of why it's no longer just an "Anthropic thing" — OpenAI added support across its products in March 2025, and Google DeepMind followed in April.

The three pieces: hosts, clients, servers

MCP splits the work into three roles. The host is the AI application itself — a chat app, a code editor, an agent — the thing a person is actually using. The client lives inside the host and handles the actual conversation with a server, translating requests back and forth. The server is the part that does the useful work: it exposes a specific set of capabilities, like "query this database" or "search these files," and executes them when asked. A single host can talk to many servers at once, which is how one AI assistant ends up able to touch your calendar, your codebase, and your ticketing system in the same conversation.

How a request actually flows

Underneath, MCP uses JSON-RPC 2.0, a lightweight, decades-old message format for calling functions across a network. A server first tells the client what it can do — its list of available tools, resources, and prompt templates — described in plain language a model can understand. When the model decides it needs one of those capabilities, the client sends a structured request, the server carries out the actual work (running the query, hitting the API, reading the file), and the result comes back to the model to use in its answer. Servers can run locally on your own machine, communicating over standard input and output, or remotely over HTTP, which is what makes it practical for both a developer's laptop and a hosted enterprise tool.

Why everyone adopted it

The honest answer is that MCP solved an N×M problem: without a shared standard, connecting N models to M tools requires roughly N×M custom integrations. A common protocol turns that into N+M — each model implements MCP once, each tool builds one MCP server once, and every combination just works. That math is attractive enough that it beat out competing approaches, and by late 2025 it had effectively become the default way agentic AI products connect to the outside world, with SDKs across Python, TypeScript, Java, C#, and other languages.

The security tradeoff that comes with it

Standardizing how AI reaches external systems also standardizes the attack surface. Letting a model execute arbitrary tools and read arbitrary data is powerful, but researchers flagged real risks early on — prompt injection hidden inside the content a server returns, and "tool poisoning," where a malicious or compromised server description tricks a model into taking an unintended action. The protocol's own specification is explicit that this is an implementation responsibility, not something the protocol enforces automatically: it requires that hosts get explicit user consent before sharing data or invoking a tool, and that tool descriptions from untrusted servers be treated with real skepticism rather than taken at face value.

The simple takeaway

MCP isn't a new AI capability — models could already call functions before it existed. What it changed is who has to build the bridge and how many times. One protocol, implemented once per model and once per tool, replaced a growing pile of one-off integrations, and that's the reason it spread as fast as it did.

Locking Exchange Rates for Multi-Currency Billing

John Ayodele — Sun, 13 Sep 2026 01:38:22 +0000

The problem

When a subscription platform bills in more than one currency, the price a customer agreed to at checkout and the amount that eventually settles in your account are not the same number by default. Between the moment a customer sees "$29/mo" and the moment your payment processor actually converts and settles that charge, the underlying exchange rate has moved — sometimes by fractions of a percent, sometimes, during a volatile week for a given currency, by several points.

Nothing about the product changed. The customer didn't get more or less value. But if you're resolving the exchange rate at charge time instead of at the time the customer agreed to a price, you've quietly turned every invoice into a small, unmanaged FX bet. Multiply that across thousands of renewals a month and it stops being a rounding error and starts showing up as unexplained variance in revenue reports.

There's a second-order problem too: unpredictability erodes trust. A customer who sees their local-currency price shift slightly from one renewal to the next — with no clear reason — is more likely to open a support ticket, dispute the charge, or churn.

Why "just re-resolve the rate" breaks down

The naive implementation looks like this: store the price in a reference currency (say USD), and at charge time, call an FX API, convert, and charge the card. It's simple, and it's wrong for billing, because it silently couples your revenue to a rate you never showed the customer and never agreed to.

*Two specific failure modes show up in practice:
*

Checkout-to-settlement drift. A customer completes checkout, sees a converted price, and authorizes payment. If the actual charge is created moments later — or, worse, days later for deferred or invoice-based flows — the rate used for authorization and the rate used for settlement can diverge. The customer was quoted one number and charged another.
Renewal drift. On a monthly or annual subscription, the price shown at signup is not necessarily the price used at each renewal if the rate is re-resolved every cycle. Customers don't expect their subscription price to float with the currency markets; they expect it to be stable unless you've told them otherwise.

Why it matters

None of this changes what the product does. It's a small architectural decision — snapshot instead of re-resolve — with an outsized effect on two things that compound over time: revenue integrity (you stop absorbing unmanaged FX risk on every single invoice) and customer trust (prices behave the way customers already expect subscription prices to behave: stable, and only changing when you say so).

Have a project in mind, or a question about this post? Reach out at johnayodelemiracle@gmail.com.

What Google Earth Engine Actually Is (and What It's Capable Of)

John Ayodele — Sun, 13 Sep 2026 01:38:21 +0000

Start with the basics

Satellites take pictures of the Earth constantly. Some take pictures of the same spot every single day. Over decades, this adds up to an enormous amount of imagery: what a forest looked like ten years ago versus today, how a city has grown, how a lake has shrunk.

The problem is that this imagery is huge. We are talking about more data than a normal computer could ever download and process. For a long time, that meant only large research institutions with serious computing power could actually work with it.

Google Earth Engine exists to fix that. It is a free (for most people) tool that lets anyone analyze decades of satellite imagery using Google's own computers, without ever downloading the images to their own machine. You write a request like "show me how this area changed between 2015 and 2025," and Google's servers do the heavy lifting and just hand you the answer.

What kind of data is actually in it

Earth Engine's library holds more than 50 petabytes of data. To put that in perspective, one petabyte is roughly one million gigabytes, so this is an almost unimaginable amount of imagery and information. Some of what is in there:

Decades of Landsat satellite imagery, going back to the 1970s
Recent, detailed imagery from the Sentinel satellites (a European satellite program)
Daily global images from a satellite system called MODIS, used to track things like plant health across entire continents
Rainfall and climate records
Elevation maps
Nighttime images of the Earth, which sounds unusual but is genuinely useful. Because brighter areas at night usually mean more human activity, this data gets used to estimate things like economic growth, or even to detect gas flares burning at oil facilities.

How people actually use it

You do not need to be a scientist to use Earth Engine, but you do need to write some code. There are two main ways people work with it:

A web-based tool where you type simple instructions and immediately see the result on a map. This is where most beginners start.
A version that plugs into Python, a popular programming language, for people who want to combine Earth Engine with other data tools they already use.

Whichever way you use it, the basic idea is always the same. You pick an area on the map, you pick a time period, and you ask a question about how that area changed. Earth Engine can even turn the result into a simple website that other people can explore themselves, without needing to write any code at all.

What people actually build with it

Almost everything people use Earth Engine for comes down to one question: how has this place changed over time, and how has it changed. Real examples include:

Tracking how much forest has been cut down in a region, year by year
Watching a city expand outward over a decade
Measuring how a lake or river has dried up during a drought
Estimating how healthy crops are across a farming region, to predict harvests
Assessing damage after a flood, earthquake, or wildfire, by comparing images from before and after

The pattern is always the same: satellites saw it happen automatically, and Earth Engine makes it possible to actually look through everything they saw.

What changed in 2026

For most of its history, Earth Engine's answer to "how much does this cost" was simple: free, as long as you were not using it for a commercial business. That is still mostly true, but 2026 brought a real change. Free users now have to pick a usage tier to keep the system fair for everyone, since so many people use it that Google needed to manage how much computing power each person gets. Anyone who does not choose a tier is automatically placed on the free default option, called the Community Tier. Businesses using it commercially have always paid separately, based on how much they use it.

If you looked into Earth Engine a few years ago and moved on, this tier system is the one genuinely new thing worth knowing about.

The simple takeaway

The reason Earth Engine matters is not that satellite pictures exist. It is that, before this, actually working with decades of satellite imagery required serious money and serious computing infrastructure. Earth Engine took that barrier away. A question that used to require a research team and a supercomputer can now be answered from a laptop, in an afternoon.

That is why it keeps showing up everywhere from climate research, to journalism, to businesses that need to understand how the physical world is changing.

Sources: Google for Developers, Earth Engine guides, Google Earth Engine, Commercial access, Google Earth Engine, Noncommercial access