Hi, I'm Ines Panker.
I'm a senior staff engineer at Sleuth, a SaaS observability platform (the first engineer they hired, de-facto architect), and the person who just gave this talk.
Almost two decades of building software.
Multi-tenant architecture. Circuit breakers guarding 2-3 million third-party API calls a day across about 40 external APIs. Real-time anomaly detection for hundreds of clients.
Python Go Django Celery PostgreSQL Redis RabbitMQ Elasticsearch LLM agents Conference speaking
LinkedIn is the fastest way to reach me.
Their API Went Down. So Why Is My App on Fire?
Third-party APIs are fickle and entirely out of your control. Sooner or later they will have an incident. Will your app survive their outage? Or will they drag you down with them?
References for this talk 📚
- Celery: Retrying tasks
- Elm: Compiler Errors for Humans
- golang/go#24138 — net/http's default client has no timeout
- HTTP 429 Too Many Requests
- MDN: AbortSignal.timeout()
- Node.js http.request() — timeout option
- Overriding the default Linux kernel connect() timeout (tcp_syn_retries)
- Python: BaseException.add_note()
- Release It! (2nd edition) — Michael T. Nygard
- Requests: Timeouts (official docs)
- Retry-After header
- RFC 9110 — HTTP Semantics
- RFC 9112 — HTTP/1.1
- SO_KEEPALIVE socket option (Winsock) — disabled by default
- TCP Keepalive HOWTO
- tcp(7) — Linux manual page
- TCP_RTO_MIN, TCP_RTO_MAX and tcp_retries2
- Wikipedia: Circuit breaker design pattern
- Wikipedia: Nagle's algorithm
- Wikipedia: TCP congestion control — slow start