Cada vez que alguien hace clic en "Iniciar sesión" en Gmail, desencadena una cadena de eventos que atraviesa decenas de sistemas distribuidos en múltiples continentes y todo ocurre en menos de 500 milisegundos.
Gmail tiene más de 1,800 millones de usuarios activos. En los momentos de mayor carga, el sistema de autenticación procesa millones de logins simultáneos. No existe un solo servidor, una sola base de datos ni una sola región que maneje todo eso. La arquitectura que lo hace posible es una de las más estudiadas en ingeniería de sistemas distribuidos, y está documentada en los propios papers de Google Research.
Esta es la Parte 1 de una serie de 3 artículos que desglosa esa arquitectura. En este artículo cubrimos el flujo de software: qué pasa desde que el request sale del navegador hasta que el usuario recibe su token de sesión.
👉🏼 Fuentes: Authentication at Scale - Google Research (2013) · Google SRE Book
El flujo completo: 8 capas entre el usuario y su bandeja de entrada
Antes de profundizar en cada capa, el mapa completo del viaje de un login:
Usuario
↓ (HTTPS request)
Global Load Balancer — Anycast IP
↓ (routing geográfico)
Edge Proxy / Frontend Server
↓ (TLS termination, validación básica)
Auth Service Layer
↓ (verificación credenciales)
Risk Engine + Anti-Abuse
↓ (score de riesgo, detección de bot)
Session / Token Service
↓ (generación de tokens)
Distributed Cache — Memorystore
↓ (cache de sesiones activas)
Persistent Identity Storage — Spanner
(fuente de verdad de identidades)
Capa 1: Global Load Balancer con Anycast
El request sale del navegador hacia accounts.google.com.
La primera decisión ya ocurrió antes de que el request llegue a
cualquier servidor de Google: el DNS resuelve esa URL a una dirección IP
Anycast.
Anycast es una técnica de routing donde la misma dirección IP está anunciada desde múltiples puntos geográficos simultáneamente. La red IP enruta el request al punto de presencia más cercano no más rápido, no más disponible, sino literalmente el más cercano en términos de hops de red. Un usuario en São Paulo llega a un PoP en Brasil. Uno en Madrid llega a Europa. El mismo IP, destinos físicamente diferentes.
Google opera más de 100 puntos de presencia globales donde termina el tráfico de usuario. Gmail servers, Spanner databases, Cloud Storage y otros servicios de Google corren sobre esta infraestructura compartida, con miles de máquinas ejecutando los mismos binarios en paralelo.
El Global Load Balancer en ese PoP hace tres cosas antes de pasar el request más adentro:
- Verifica que el request es HTTP/2 o HTTP/3 válido
- Aplica rate limiting inicial por IP de origen (protección DDoS primitiva)
- Elige qué Edge Proxy recibirá el request según capacidad y latencia interna
Capa 2: Edge Proxy / Frontend Server
El Edge Proxy es donde ocurre la terminación TLS. Todo el tráfico de usuario llega cifrado el Edge Proxy descifra el contenido, valida el certificado del cliente si aplica, y reencripta para la comunicación interna hacia los servicios backend.
Una decisión de diseño fundamental que el paper de autenticación de Google documenta es el uso de channel binding vincular la sesión de autenticación al canal TLS específico. Esto previene ataques de tipo man-in-the-middle donde un atacante roba las credenciales del wire.
El Edge Proxy también hace la primera validación semántica del request: ¿tiene el formato correcto? ¿Viene de un User-Agent reconocible? ¿La estructura de la petición es coherente con un login legítimo? Los requests que fallan aquí se rechazan sin pasar a los servicios internos.
Finalmente, el Edge Proxy agrega headers internos de trazabilidad un trace ID único que seguirá al request a través de todas las capas del sistema. Este es el mecanismo que luego usa Dapper (el sistema de distributed tracing de Google) para correlacionar lo que pasa en cada servicio durante el ciclo de vida del login.
Capa 3: Auth Service Layer
Aquí ocurre la verificación real de credenciales. El Auth Service recibe el username y password, y ejecuta la secuencia de verificación:
Paso 1: Lookup del usuario
El username (dirección Gmail) se usa para localizar el registro de identidad del usuario en Spanner la base de datos distribuida globalmente de Google. No se hace un query directo a Spanner en cada login: el Auth Service primero consulta el Distributed Cache. Si la información del usuario está en cache (salt del password, hash, configuración 2FA), no hay round-trip a Spanner. En usuarios que iniciaron sesión recientemente, el cache hit rate es muy alto.
Paso 2: Verificación del password
El password nunca viaja en claro dentro de los sistemas de Google ni siquiera en la red interna. El Auth Service computa el hash del password con el salt del usuario y lo compara con el hash almacenado. Si no coincide, incrementa el contador de intentos fallidos (persistido en Spanner para sobrevivir reinicios) y retorna error.
Paso 3: Estado de la cuenta
¿La cuenta está activa? ¿Está suspendida por violación de términos? ¿Hay una sesión existente que debería invalidarse? ¿Tiene configurado 2FA obligatorio? El Auth Service consulta todos estos estados antes de continuar.
El diseño stateless del Auth Service
Una decisión crítica: el Auth Service es stateless. No guarda estado entre requests. Cualquier instancia puede manejar cualquier login. Esto es lo que permite que miles de máquinas ejecuten el mismo binario del servicio en paralelo sin coordinación Borg (el scheduler de Google) puede agregar o quitar instancias del Auth Service en segundos según la demanda.
Capa 4: Risk Engine + Anti-Abuse
Esta capa es el diferenciador real de Google respecto a sistemas de autenticación simples. El risk-based checking es particularmente crítico para reducir lo que de otra forma sería un secuestro masivo de cuentas.
El Risk Engine evalúa cada intento de login con docenas de señales simultáneas:
- Geolocalización: un patrón geográfico de IPs de login que cambia abruptamente genera preocupación adicional si el usuario normalmente inicia sesión desde Bogotá y de repente aparece desde Moscú 30 minutos después, la física lo hace imposible
- Device fingerprint: ¿es un dispositivo conocido del usuario? ¿Tiene el browser las características esperadas?
- Behavioral patterns: velocidad de escritura del password, movimientos del mouse, tiempo entre campos señales sutiles que los bots no replican fielmente
- Network reputation: ¿la IP viene de un datacenter? ¿De una red asociada con spam histórico? ¿De un proxy/VPN?
- Account history: ¿cuántos intentos fallidos recientes? ¿Hubo un reporte de phishing reciente sobre esta cuenta?
El resultado es un risk score entre 0 y 1. Según ese score, el sistema toma una decisión:
- Score bajo -> login directo, sin fricción adicional
- Score medio -> solicitar 2FA incluso si no está configurado como obligatorio
- Score alto -> challenge adicional (CAPTCHA, verificación por email/SMS alternativo)
- Score muy alto -> bloqueo temporal y alerta al usuario
Si el 2FA y otros sistemas de dos factores comprenden "algo que sabes" y "algo que tienes", esto podría llamarse "en algún lugar donde estás" y "de alguna manera como te comportas". El Risk Engine es, en esencia, un tercer factor implícito en cada login.
Capa 5: Session / Token Service
Si el usuario pasó la verificación de credenciales y el Risk Engine aprobó el login, el Token Service genera las credenciales de sesión. Google usa múltiples tipos de tokens según el contexto:
GAIA Cookie: el token de sesión web que persiste en el navegador. Permite que el usuario siga autenticado al navegar entre Gmail, Drive, Calendar y otros servicios de Google sin re-autenticarse lo que Google llama Single Sign-On (SSO) interno.
OAuth 2.0 tokens: para aplicaciones de terceros que piden acceso a los datos del usuario. El Token Service genera access tokens (de vida corta, minutos u horas) y refresh tokens (de vida larga, días o semanas) según el scope solicitado.
Tokens de sesión móvil: para apps nativas de Gmail en iOS y Android. Tienen características diferentes a los cookies web no pueden ser robados por XSS y tienen revocación más granular.
Todos los tokens tienen tres propiedades comunes: están firmados criptográficamente (no pueden ser falsificados), tienen tiempo de expiración explícito, y están atados al user agent y dispositivo que los creó.
Capa 6: Distributed Cache
Las sesiones activas se guardan en un sistema de cache distribuido equivalente a Memcache/Redis a escala global. El objetivo es evitar que cada request autenticado del usuario (abrir un email, cargar el inbox, enviar un mensaje) tenga que verificar el token en Spanner.
El cache almacena la información de sesión con un TTL que se renueva en cada request activo. Si el usuario está usando Gmail activamente, el token nunca llega a Spanner en cada operación solo el primer request por sesión y las operaciones que requieren validación de privilegios elevados.
La coherencia del cache es crítica para la seguridad: cuando el usuario cierra sesión o revoca el acceso de una aplicación, esa información debe propagarse al cache antes de que el token expire naturalmente. Google resuelve esto con invalidación activa el logout no solo borra el cookie del browser, sino que escribe una entrada de "sesión revocada" en Spanner que el cache replica en segundos.
Capa 7: Persistent Identity Storage (Spanner)
En la base de todo está Spanner, la base de datos distribuida globalmente de Google. Spanner está diseñado para escalar hasta millones de máquinas en cientos de datacenters y billones de filas de base de datos.
Para el sistema de identidad de Gmail, Spanner almacena:
- Registro de identidad de cada usuario (username, hash de password, salt, estado de cuenta)
- Configuración de autenticación (2FA configurado, dispositivos confiables, historial de sesiones)
- Log de auditoría de logins (cuándo, desde dónde, con qué resultado)
- Tokens de larga duración (refresh tokens de OAuth)
- Lista de sesiones activas para revocación
Spanner procesa más de 2 mil millones de requests por segundo en pico y tiene más de 6 exabytes de datos bajo gestión, siendo la fuente de verdad para servicios críticos incluyendo AdWords y Search.
Lo que hace posible este volumen es que Spanner implementa consistencia fuerte con Paxos y TrueTime el reloj atómico/GPS de Google que permite que transacciones distribuidas en diferentes continentes tengan un orden global sin coordinación centralizada.
El principio transversal: Zero Trust
Un elemento arquitectónico que atraviesa todas las capas y que el SRE Book de Google documenta extensamente: la infraestructura no asume ninguna confianza entre los servicios que corren en ella. Este modelo de confianza se denomina zero-trust security model ningún dispositivo o usuario es confiable por defecto, ya sea dentro o fuera de la red.
Esto significa que el Auth Service no confía en el Edge Proxy. El Token Service no confía en el Auth Service. Cada transición entre capas requiere verificación criptográfica de identidad del servicio llamante. Si alguien comprometiera una máquina interna de Google, no podría hablar con el Token Service sin las credenciales correctas del servicio.
Lo que sigue en esta serie
- Parte 2: Borg, Spanner y el stack de infraestructura que hace posible la concurrencia absurda de Gmail
- Parte 3: Dapper y el Risk Engine cómo Google sabe que eres tú y no un atacante
¿Cómo se compara esto con la arquitectura de tu sistema? 💥Calculadora gratuita
Arquitectura de software: la decisión que lo determina todo
PostgreSQL, Redis y Spanner: cuándo usar cada tipo de base de datos
0 Comentarios