The pitch and the physics

Someone forwards a link in the engineering channel and writes "we should move to an edge database". The page they linked is good. It talks about putting your data close to your users, and it isn't lying about anything.

The question it can't answer for you is whether the slowness you're experiencing comes from where your data sits. Most of the time it doesn't, and the way to know is a piece of arithmetic that takes about a minute.

Start with the one number nobody can negotiate

Light in a vacuum covers 299,792.458 kilometers per second. Fiber is glass, not vacuum, and glass slows light down by its refractive index, which for the silica used in long-haul fiber is close to 1.46.

So the signal in the cable travels at 299,792.458 divided by 1.46, which is 205,337 km per second, or 205 km per millisecond.

Round that to 200 km per millisecond and carry it around with you. It's the only number in this course that no vendor, no protocol and no amount of money can improve.

Two city pairs, worked out

Take São Paulo and Ashburn, in northern Virginia, where a large share of the internet's servers physically live. The great-circle distance between them is about 7,665 km.

One way: 7,665 / 205 = 37.4 ms.
There and back: about 75 ms.

Now take London and Sydney, about 16,994 km apart.

One way: 16,994 / 205 = 82.9 ms.
There and back: about 166 ms.

State the assumptions out loud, because they matter. Those figures assume a straight line along the earth's surface, a refractive index of 1.46, no routing detour, no queueing at any hop and zero processing time at either end. Every one of those assumptions is generous. Real cables follow coastlines and existing rights of way, so the fiber path is routinely 1.3 to 1.6 times the great-circle distance. Real measured round trips on those routes land well above these numbers.

That's the point. These are floors, not predictions. A measurement can be worse than the floor for a hundred reasons. It can never be better.

Why the floor is the useful number

A floor turns an argument about products into an argument about arithmetic.

Say someone tells you a request from Sydney to London can feel instant while the database stays in London. You don't need to evaluate their architecture. One round trip costs 166 ms before anyone does any work. If your budget is 100 ms, no configuration reaches it, and the conversation moves on to which of you is wrong about where the data has to be.

That's a much better conversation than the one that starts with a product name.

The reframing this course is built on

Here's the part that surprises people. A page that takes two seconds from São Paulo is almost never slow because the database is 7,665 km away. One round trip to Virginia is 75 ms. Two seconds is roughly twenty-seven of them.

So the interesting question is "why are we crossing the distance twenty-seven times?", more than "how do we shorten it?"

Almost every time, the answer is that the application makes many small sequential queries. Each one waits for the previous one to come back, and each one pays the full round trip. Moving the database closer divides that bill. Removing the round trips deletes most of it, costs nothing in consistency and can usually be done in an afternoon.

What this course covers

Lesson 2 makes the multiplication explicit: why round trips, not kilometers, dominate a real request, and how to count yours.

Lesson 3 is the asymmetry that makes this hard. Reads move near the reader easily. Writes need a primary, and the moment you have more than one, you've picked a consistency model whether or not anyone said so.

Lesson 4 is what breaks when writes are far: the user who can't see the form they just submitted, sessions, uniqueness and the sequential writes Active Record produces without being asked.

Lesson 5 names the categories of product on offer and what each one changes about the floor, without naming features that will be different next year.

Lesson 6 gives the honest answer for almost every application. Then it covers the two cases where an edge database is the right call, one of which is legal rather than technical.

Lesson 7 turns all of it into an ordered list of what a Rails team should do, and hands you to the last course of this series.

Before any of that, go and find out how many queries your slowest page makes. You'll need the number in lesson 2, and it's usually the number that ends the discussion.