SoundCloud comparó en la sombra un nuevo protocolo RPC contra producción antes de servirlo

El backend de SoundCloud funcionaba sobre microservicios con interfaces REST/JSON construidas a mano, fáciles de depurar pero que dejaban las convenciones de cada endpoint en manos del equipo que lo creaba: método HTTP, nombres de campos JSON, formatos de marca de tiempo, formas de los errores. Las directrices internas solo ayudaban hasta cierto punto: un cliente envió una vez campos en camelCase a un servidor que esperaba snake_case y provocó una caída, y entender cualquier endpoint implicaba leer el código de la aplicación en lugar de un contrato.

SoundCloud creó Twinagle, una implementación en Scala/Finagle del protocolo RPC Twirp de Twitch, para que los ingenieros pudieran definir una API una sola vez en protobuf y generar a partir de ella el código del servidor y del cliente. Migraron primero su servicio de autorización de pistas de alto tráfico. En lugar de hacer el cambio directamente, ejecutaron REST y Twirp en paralelo detrás de un flag basado en porcentajes: con porcentajes de despliegue bajos, se llamaba a ambos endpoints y se comparaban, devolviendo solo la respuesta REST, de modo que las discrepancias afloraban como discrepancias registradas en logs, no como errores visibles para el usuario.

Replicar el tráfico hacia el nuevo endpoint, compararlo y luego hacer el cambio

Generar el código del servidor y del cliente a partir de un único contrato protobuf eliminó la clase de errores causados por equipos que inventaban sus propias convenciones de nombres de campos JSON y de HTTP.

Ejecutar ambos endpoints en paralelo con un pequeño porcentaje de tráfico antes de hacer el cambio permitió al equipo detectar discrepancias en las respuestas sin que ningún usuario viera una respuesta incorrecta.

Empezar con un servicio de alto tráfico y de un solo cliente mantuvo pequeña la superficie de integración de la primera migración y, aun así, puso a prueba Twinagle bajo carga real.

Mantener intacta la lógica de negocio existente y confinar el código nuevo a una fina capa de serialización limitó dónde podían esconderse los nuevos errores.

Antes de retirar un sistema que funciona, haz que el reemplazo responda a cada solicitud en paralelo y compáralo con el sistema en uso: los errores afloran mientras el sistema antiguo sigue sirviendo la respuesta.

El despliegue con comparación en la sombra detectó varios errores críticos antes de que llegaran a los usuarios, y SoundCloud aumentó el servicio de autorización de pistas hasta el 100% del tráfico por Twirp sin caídas y sin errores en el primer intento. El ancho de banda entre los dos servicios cayó más del 40% al pasar de JSON a protobuf binario, y el equipo eliminó todo su código de serialización JSON personalizado para el servicio. SoundCloud siguió convirtiendo sus otros servicios a Twinagle y lo convirtió en la opción predeterminada para todos los servicios nuevos en adelante.