Development PracticesConference50min
Their API Went Down. So Why Is My App on Fire?
The talk explains how to protect your app from outages in APIs you don’t control. Beyond try-except, it covers practical patterns like caching 429s, resuming syncs, and using circuit breakers to prevent external failures from cascading into your own production system.
talk.summaryAiDisclaimer
Ines Panker
talkDetail.whenAndWhere
Thursday, October 8, 17:40-18:30
TBA 8
talks.roomOccupancytalks.noOccupancyInfo
You call APIs you don't control... and sooner or later they will have an outage. Will your app survive their outage? Or will they drag you down with them?
The first step in guarding against remote outages is to wrap calls in try-except statements. As long as we catch the error and log a message, we call our guardrails done. But just "not crashing" is a very low bar, and underneath it something worse can still be happening.
Imagine you are calling GitHub and their API goes down. You have 500 background tasks that all fires a request to GitHub, wait for the socket to time out, fail, get rescheduled, and try again. Now your workers are all sitting on dead sockets doing nothing, and no other task can get a free worker. Congratulations: someone else's outage is now your outage.
This talk is about better strategies for fighting unreliable remote APIs. I won't present any heroic distributed-systems wizardry, just a handful of boring but battle-tested patterns that stop other people's failures from amplifying into yours.
How to actually honor a rate limit without rewriting your codebase (cache the 429, let Redis' TTL be the waiting period). How to resume a 5,000-record sync from page 47 instead of starting from page 1. How a circuit breaker turns "good manners for the other
company" into plain self-defense for yours.
It's all real code pulled from a multi-tenant production system. We can't make other people's APIs reliable. We can only stop their bad day from becoming ours.
The first step in guarding against remote outages is to wrap calls in try-except statements. As long as we catch the error and log a message, we call our guardrails done. But just "not crashing" is a very low bar, and underneath it something worse can still be happening.
Imagine you are calling GitHub and their API goes down. You have 500 background tasks that all fires a request to GitHub, wait for the socket to time out, fail, get rescheduled, and try again. Now your workers are all sitting on dead sockets doing nothing, and no other task can get a free worker. Congratulations: someone else's outage is now your outage.
This talk is about better strategies for fighting unreliable remote APIs. I won't present any heroic distributed-systems wizardry, just a handful of boring but battle-tested patterns that stop other people's failures from amplifying into yours.
How to actually honor a rate limit without rewriting your codebase (cache the 429, let Redis' TTL be the waiting period). How to resume a 5,000-record sync from page 47 instead of starting from page 1. How a circuit breaker turns "good manners for the other
company" into plain self-defense for yours.
It's all real code pulled from a multi-tenant production system. We can't make other people's APIs reliable. We can only stop their bad day from becoming ours.
Ines Panker
Ines takes complicated systems and finds the arrangement that makes them work like poetry.
Two decades into building software, she's learned that the hard part is rarely the code. It's making a system, and the reasons behind it, legible to the people who build on it, use it, and live with it.
She reads a lot of poetry, which turns out to be the same job: the right arrangement of words making something complex suddenly feel simple. In her talks she does that with software, blending technical depth with a focus on the people around the code.
Two decades into building software, she's learned that the hard part is rarely the code. It's making a system, and the reasons behind it, legible to the people who build on it, use it, and live with it.
She reads a lot of poetry, which turns out to be the same job: the right arrangement of words making something complex suddenly feel simple. In her talks she does that with software, blending technical depth with a focus on the people around the code.