DNS: Old Solution for Modern Problems
summary
LinkedIn implements a distributed, highly available DNS-based service discovery written in Go that fronts multiple topology backends via plugins, uses in-memory cache plus on-disk persistence, gossip for consistency between resolvers, and a distributed health checker. It serves roughly 100–800 qps per service while traffic tiers generate ~25,000 qps, tracks about 2000 unique service names, and cuts new-service rollout from about a day to 3 seconds in production.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:40Who are we
- 2:33Service Discovery
- 4:15Multitenant
- 6:00Sources of truth
- 6:45SRV records
- 7:48Runtime priorities
- 9:43Service contract
- 13:28Questions
- 15:43Implementation
- 16:28Python
- 18:37First Users
- 19:07Problems
- 19:56Metrics
- 22:16Outcomes
- 25:03Load Balancing
related talks
34mThe Day the DNS Died
27mScalable DNS With CoreDNS Plugins: A Deep Dive
29mService Discovery with CoreDNS Plugins in Golang
34mIt’s Always DNS: So Let’s Break It On Purpose
22mDos and Don’ts: Designing an XDS Backend for the LinkedIn Scale
27mCoreDNS Deep Dive
09mDNS is the entry point for every application on the internet
38mIntro + Deep Dive: CoreDNS