Six Degrees of Albert Einstein

How I built a researcher connection finder on 450 million papers

Brian May, the guitarist from Queen, is five handshakes away from Albert Einstein.

I don't mean that in an "everything is connected" way. There's an actual paper trail: May didn't just play for Queen; he went back and finished a PhD in astrophysics, and one of his papers cites the work of a mathematician named R. B. Blackman. Blackman co-wrote a now-classic paper on measuring power spectra with a fellow named Teichmann. Teichmann, in turn, co-authored a book with David Hilbert. Yes, that Hilbert. And Hilbert's trail runs into a slim 1920 book called Relativity, translated into English (and therefore, as far as a database is concerned, "co-authored") by one Robert Lawson, whose co-author on that book was Einstein himself.

So:

Brian May, then Blackman, then Teichmann, then Hilbert, then Lawson, then Einstein.

Five hops, from a rock star to the most famous physicist who ever lived, through a chain of citations and co-authorships that absolutely no one sat down and planned.

You've probably heard the claim that any two people on Earth are separated by about six handshakes. It's a fun idea, got a Hollywood spin-off ("six degrees of Kevin Bacon"), and turns out to be roughly true. I wondered whether scientists lived in that same small world, so I built a tool to check. You give it two researchers, and it finds the shortest chain between them, drawing the surrounding network in your browser as it goes: nodes popping in, edges connecting together, and the final path lighting up as the two ends meet. It takes about 30 seconds.

Try the live demo, but guess first. Pick someone who couldn't possibly be connected to your favorite researcher, write down the number of hops you think it'll take, and then run it. You'll almost always guess too high.

---

What it does

It's simple: Two names in, one chain out.

You type in two researchers. The tool matches each name to a real academic identity, then goes looking for the shortest path between them. It counts three kinds of connection:

• Co-authorship — they wrote a paper together.
• Citation — one cited a paper the other wrote.
• Shared institution — they were once at the same university or lab.

These are the ordinary ways two academic careers end up overlapping.

Once it has a path, it draws the whole neighborhood: the other authors clustered around the chain, nodes you can grab and drag, and the connecting path lit up so you can trace exactly how two strangers turn out to be neighbors.

And the results can really surprise you. People who look like they have nothing to do with each other keep landing three or four hops apart, usually because of one very well-connected collaborator, or a single famous paper that both of their fields happened to cite.

---

Where the data comes from

None of this works without OpenAlex. It's a free, open catalog of the world's research: more than 450 million scholarly works, and their authors, and their institutions, and the citation links between them. A lot of serious research infrastructure quietly runs on it, and yet almost nobody builds fun things on top of it, which seemed like a shame.

The part that made this project possible is that it's genuinely open. No scraping, no paywall, none of the terms-of-service limitations about whether you're allowed to do what you're doing. You just ask the API about authors, papers, and citations, and it answers. The free key comes with a daily allowance that's more than generous, and you only start paying if you need a lot more than that. For something like this, the free tier never came close to running out.

---

The interesting engineering

Under the friendly surface painted by OpenAlex, three problems turned out to be worth solving properly. Each one started as an obvious naive approach, fell over, and got interesting from there.

1. Searching from both ends at once

The naive way to find a path is to start at Researcher A and fan outward. Their co-authors, then those people's co-authors, then the next ring, and so on, until you eventually come across Researcher B somewhere out there.

The trouble is how fast academic networks branch. A well-connected researcher might have hundreds of co-authors, and every one of those can have hundreds more. Three or four hops out from a single person and you're looking at millions of nodes. The search space doesn't just grow, it explodes, and it explodes exponentially with distance.

The fix is a classic trick: bidirectional search. Rather than growing one giant frontier from A until it reaches B, you grow two smaller ones at once, one from A and one from B, and wait for them to meet in the middle. Since each side only has to cover half the distance, and the cost grows exponentially with distance, cutting the depth in half roughly square-roots the total work. Two manageable searches instead of one hopeless one.

In practice, it's what lets a lot of these queries finish at all.

2. Streaming results instead of making you wait

Even with the better search, hitting a live API for all those neighborhoods takes a while, often the better part of half a minute. And a plain spinner tells you nothing during that time. You just sit there watching it spin, and towards the twenty-second mark, you start to assume the thing is broken, even when it's working fine.

So instead of making you wait for the final answer, the backend streams its progress. Every time the search discovers an edge, it sends that to the browser right away over Server-Sent Events (SSEs), which is a lightweight one-way channel that's well suited for "here's another piece of the answer." The graph builds up in front of you. Nodes pop in, edges connect them, and the highlighted path centers the graph the moment the two frontiers meet.

The computation isn't any faster — same thirty seconds, potentially even slower due to the addition of SSEs — but it feels different, because you're watching stuff happen instead of staring at a spinner. And the feeling is what people actually walk away with.

3. Remembering what it has already seen

This third one didn't show up until I'd played around with the tool for real: Ask about the same well-known researcher twice, and the tool would re-fetch their entire neighborhood from the API all over again, burning through my usage allowance, slowing down every search, and redoing work it had just done a minute earlier.

So now it keeps a cache of every researcher's neighbors it has ever looked up. Second time a name comes around, their connections are already in memory. And because the same handful of popular, well-connected researchers keep turning up as the bridges in everyone's paths, this pays off almost immediately. You cache someone like Hilbert once and he stays useful across every future search.

My first patch was the obvious one: keep the whole cache in memory, dump it to a JSON file on disk now and then. It worked beautifully on my laptop. And then I deployed it to a free-tier host and it fell over in two different ways.

The first was the disk. Turns out the host has an ephemeral filesystem, which means every deploy or restart deletes all local files. So the cache that was supposed to "survive restarts" was actually wiping itself clean every time I pushed a change, which was the one thing it wasn't supposed to do. The second problem was memory. The whole cache lived in RAM, a free tier gives you only a few hundred megabytes, and a cache that only ever grows is going to hit that ceiling sooner or later.

The fix was to notice that my cache was really doing two jobs at once, and to split them. Now, a bounded in-memory LRU holds just the most recently used entries, so the memory footprint stays flat no matter how big the cache gets. Behind it sits a durable database that owns the full copy. A lookup checks memory first, then the database, then finally, only if both come up empty, it asks OpenAlex. In production the durable half is a Postgres database, with writes debounced onto a background task so they never delay the search. Locally it's still just that same JSON file.

None of this is glamorous, but it's exactly the sort of thing that stays invisible right up until "it works on my machine" stops being good enough.

---

The surprising results

This is the part I'd really push you to try for yourself.

Pick two researchers who look like they have no business being connected: different fields, different countries, different centuries. Guess how many hops apart they are, out loud, before you run anything. Then run it.

You'll almost always guess too high. The research world is a genuinely small world, and it's held together by a surprisingly tiny number of extraordinarily well-connected people, plus a handful of landmark papers that somehow get cited by everybody in every discipline. Those are the bridges. And once your path routes through one of them, the distance just collapses.

For me the most interesting results are the ones where the bridge is the actual story. One collaborator, or one influential paper, standing between two people who would never recognize each other's names. In the Brian May chain it was Hilbert doing that work, an early-twentieth-century mathematician sitting between a Queen guitarist and Einstein. Try the tool yourself and find out who your unlikely connector turns out to be.

---

What I learned

The engineering that mattered most wasn't the flashiest. Bidirectional search is a well-known trick; nothing clever about knowing it exists. Caching is the first solution you learn for when lookups are expensive. The win was deciding to reach for these optimizations early, before writing the naive version, recognizing that the naive version was never going to scale. And the streaming, which is really just a presentation detail, ended up doing more for how the tool feels than any actual algorithm did.

Working against someone else's live API also forced a discipline I don't usually bother with on toy projects. When the data is free and someone else is paying to host it, you owe them a bit of care: cache aggressively, put your email in the request header so they know who's making the requests, and try not to make the same call twice if you can avoid it.

And there's plenty still rough. The ranking of which neighbors to show could be smarter. Connecting more than two people at once opens up a set of harder problems I've mostly been avoiding. The layout still tangles itself on really dense networks. But it works, it's genuinely fun to play with, and it answered the question I started with — yes, researchers live in a small world too, usually a smaller one than you'd guess.

---

Try it yourself

If you take one thing away from this, let it be that the world of research is far more connected than it looks, and the tools to explore it are sitting right there in the open.

So go try the live demo and see how close your two researchers really are. If you're curious how it works underneath, the code is open source, and the bidirectional search and streaming pieces are the parts worth reading. And if you end up building something of your own on top of OpenAlex, I'd love to hear about it.

---

Credits

This was built with a couple of friends. Eric Gao shaped the early UX, the layout and neighborhood view that are the whole reason the graph is pleasant to read. And Bruce Wen wrote the fix that stops overlapping searches from hitting the API with a pile of duplicate requests.

---

If you enjoyed this, I write about the things I build here. More soon.