
In May, a friend shared an idea: wouldn't it be great to cheer on a friend running the NYC Marathon without having to be there in person? What if you could pay for a custom sign when you can't make it?
I thought it was a great idea. So I bought an LED sign, a stand, a gigantic power bank, and set up a website to purchase the messages.
I teamed up with another friend and we built software to power our cheering system. We decided to test everything on smaller races first to work out the kinks. Initially, we tried using location data from the NYRR (the race organizers) app, but it proved far too inaccurate.
We changed strategies. Now we'd stand 100 feet ahead of the sign, spot runners as they approached, punch in their bib number, query the NYRR API to match the number to their name, and display a custom message on the LED board. In our demo the day before the race, it worked perfectly.
Then race day arrived. With tens of thousands of people using the NYRR app simultaneously to track runners, the API started buckling under the load. Our name lookups slowed and then failed entirely. Our system was useless.
Looking back, we should have asked ourselves: "What systems external to us are we relying on here, and is there a way to remove that dependency?" If we had asked this, we could have downloaded all the participant records beforehand and stored them in our own database, freeing ourselves from the network traffic of the API.
In business, being beholden to others is the killer of excellence. External dependencies create points of failure outside your control. They force you to accept compromises and work around problems instead of solving them at the root.
The lesson: own your critical path, or it will own you.
>100 subscribers
Share Dialog
Dylan Brodeur
1 comment
that’s such a classic builder story started with pure heart and ran straight into dependency hell still though the core idea’s gold owning your stack is the real endurance training