Entrevista de Backend: ¿Cuándo Deberías Elegir REST o gRPC?

Enunciado y Contexto Aplicable

Una plataforma tiene tres límites de API. Los navegadores, las aplicaciones móviles y los socios externos consumen el primero, por lo que debe ser fácil de integrar, depurar y evolucionar de forma independiente. El segundo es tráfico de servicio a servicio en un entorno de centro de datos controlado. Alcanza un pico de 20,000 llamadas por segundo y necesita tanto llamadas ordinarias de solicitud-respuesta como un stream del servidor. El tercero recibe callbacks de webhooks de sistemas externos.

La cifra de 20,000 llamadas por segundo es una suposición de entrevista, no un umbral de rendimiento universal. Elige HTTP de estilo REST con JSON, gRPC nativo o una combinación justificada para cada límite, y luego explica la migración y la validación. REST es un estilo arquitectónico y no está atado a JSON ni a HTTP/1.1. “REST/HTTP+JSON” simplemente fija la implementación común que se compara en este enunciado. gRPC no es un interruptor que hace automáticamente que una operación sea rápida, idempotente o confiable.

Esta es una pregunta de backend porque su núcleo son las interfaces de servicio, la semántica de protocolos, los contratos de cliente y la gobernanza en producción. No pide un sistema de negocio completo, y una tabla memorizada de “gRPC es más rápido; REST es más compatible” no es suficiente.

Qué Evalúa el Entrevistador

La primera señal es si el candidato comienza con los consumidores y los límites de red. Los navegadores públicos y los ecosistemas de socios valoran las herramientas HTTP ubicuas, los payloads legibles, la semántica de almacenamiento en caché y el bajo costo de integración. Los clientes internos controlados pueden estandarizar más fácilmente archivos .proto, código generado, proxies y balanceo de carga. El protocolo puede seguir al límite; una plataforma no necesita exponer solo un estilo de interfaz.

La segunda señal es separar las abstracciones de las implementaciones. REST utiliza recursos, métodos HTTP, códigos de estado y semántica de almacenamiento en caché, y puede ejecutarse sobre HTTP/2 o HTTP/3. gRPC se centra en servicios y métodos, utiliza Protocol Buffers como su interfaz y definición de mensajes predeterminada, y proporciona métodos unarios, de streaming de cliente, streaming de servidor y streaming bidireccional. “REST solo usa HTTP/1.1” y “REST no puede hacer streaming” son ambos atajos erróneos.

La tercera señal es completar el contrato y el modelo de fallos. OpenAPI puede dar a una API HTTP un contrato legible por máquina y generación de código. La compatibilidad binaria de Protobuf no garantiza la compatibilidad de la aplicación. Cualquiera de las opciones aún requiere plazos (deadlines), cancelación, idempotencia, reglas de errores reintentables, autenticación, autorización, evolución de versiones e identidad de solicitud observable.

Finalmente, los candidatos sólidos piden evidencia. Hacen benchmarks de payloads representativos, concurrencia, compresión, comportamiento de conexión y fallos, y luego prueban el resultado en canary mientras miden la latencia de cola y los errores. Una migración de plataforma justificada únicamente por “lo binario es más rápido” no es ingeniería reproducible.

Preguntas para Aclarar Antes de Responder

• ¿Quién controla los clientes y las actualizaciones? Los servicios dentro de una misma organización pueden coordinar los lanzamientos de clientes generados. Los socios a los que no se les puede obligar a actualizar necesitan un límite estable que sea fácil de consumir de forma independiente.
• ¿Es la interacción unaria, de streaming o una notificación asíncrona? El CRUD ordinario no se beneficia automáticamente de gRPC. Un stream ordenado sobre una conexión de larga duración puede encajar con gRPC nativo. Un webhook de terceros es iniciado por otra entidad y normalmente debe seguir el contrato HTTP publicado por esa entidad.
• ¿Debe un navegador llamar al servicio directamente? Los navegadores no pueden proporcionar directamente todo el control de HTTP/2 requerido por gRPC nativo. gRPC-Web, la transcodificación JSON o un BFF añaden una capa que cambia la depuración, las capacidades de streaming y las operaciones.
• ¿Cuál es el problema de rendimiento real? Cambiar la serialización no eliminará un cuello de botella en la base de datos, un fan-out hacia servicios posteriores o una consulta no acotada. Pregunta por los tamaños de payload, QPS, concurrencia, p95/p99, CPU y presupuestos de red.
• ¿Qué soportan la pasarela (gateway) actual y el stack de observabilidad? El soporte del proxy para el estado de gRPC, streams, health checks y la correlación de trazas de extremo a extremo cambia directamente el riesgo del despliegue.
• ¿Cómo debe evolucionar la interfaz? Las APIs públicas necesitan una política de compatibilidad. Protobuf interno necesita reglas de números de campo y versiones mixtas. Sin pruebas entre versiones, un contrato fuertemente tipado aún puede fallar durante un despliegue continuo (rolling deployment).

Marco de Respuesta en 30 Segundos

“Elegiría según el límite del consumidor, no tomaría una sola decisión para toda la plataforma. La API para navegadores, móviles y socios comienza como HTTP de estilo REST con JSON, gobernada por OpenAPI, semántica HTTP y una política de compatibilidad. El webhook de terceros también sigue su contrato HTTP público. Para la ruta interna controlada a 20,000 llamadas por segundo, elegiría gRPC nativo si los benchmarks representativos muestran que los costos de serialización o conexión importan y el stream del servidor es un requisito real. Los clientes generados no eliminan la necesidad de establecer plazos (deadlines), propagar la cancelación, reintentar solo operaciones seguras y preservar la compatibilidad de campos. En el borde, la transcodificación JSON o una pasarela ligera pueden compartir una sola implementación de dominio. Antes del despliegue, compararía el p99 de extremo a extremo, CPU, bytes y recuperación de fallos con payloads reales, y luego migraría por cliente. El protocolo no reemplaza la autenticación, la idempotencia ni la observabilidad.”

Análisis Detallado Paso a Paso

Paso 1: Decidir cada límite por separado

Utiliza HTTP de estilo REST con JSON para el límite público. Los URIs de recursos, métodos, códigos de estado, solicitudes condicionales y almacenamiento en caché son ampliamente entendidos por navegadores, CDNs, herramientas de línea de comandos y socios. OpenAPI puede ser la fuente del contrato para la documentación y los SDKs generados, por lo que describir REST como “no tipado y manual” es injusto. El costo es que el equipo debe gobernar activamente su modelo de errores, paginación, enums abiertos y la desviación respecto a la especificación.

Elige gRPC para el límite interno solo después de que se cumplan dos condiciones: los clientes y servidores pueden estandarizar el código generado y la infraestructura de ejecución, y un benchmark representativo muestra suficiente beneficio para justificar la complejidad de proxies, depuración y versiones mixtas. Este enunciado también incluye un requisito real de streaming del servidor. Los métodos de streaming de gRPC y los metadatos, estado y plazo (deadline) por llamada forman un modelo coherente para ello. El número de 20,000 QPS por sí solo no toma la decisión.

Utiliza un webhook HTTP para el callback de terceros. El emisor externo controla el protocolo, y el receptor público necesita TLS, verificación de firma, confirmación rápida y procesamiento asíncrono. Reemplazar el receptor con gRPC no hace que un socio que envía solicitudes HTTP POST pueda llamarlo. Si la ruta de procesamiento interno utiliza gRPC, el adaptador de webhook verifica y persiste el evento antes de invocar esa ruta.

Paso 2: Escribir contratos ejecutables

La interfaz de lectura pública utiliza semántica de recursos y HTTP:

GET /v1/orders/ord_123
If-None-Match: "order-v7"

200 OK
ETag: "order-v7"
Content-Type: application/json

La interfaz interna define acciones y mensajes:

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (Order);
  rpc WatchOrder(WatchOrderRequest) returns (stream OrderEvent);
}

message GetOrderRequest {
  string order_id = 1;
}

Ambos contratos necesitan autenticación, autorización, errores, reglas de paginación o terminación de stream, límites de tamaño y campos de auditoría. Un nombre de método gRPC puede ocultar el costo de red, pero los clientes aún deben tratarlo como una operación remota con latencia, tiempos de espera y fallos parciales. REST POST tampoco es automáticamente idempotente; las operaciones de creación necesitan una clave de idempotencia estable o una restricción de unicidad de negocio.

Paso 3: Diseñar la semántica de fallos

Por defecto, un cliente gRPC puede no tener un plazo (deadline), así que establece uno a partir del presupuesto de extremo a extremo. La expiración del plazo hace que el cliente deje de esperar, pero la aplicación del servidor sigue siendo responsable de detener el trabajo que inició. La propagación del plazo y de la cancelación también debe verificarse para el lenguaje y framework seleccionados. Los clientes HTTP igualmente necesitan presupuestos de conexión, respuesta y totales; los valores predeterminados de socket no son SLOs de negocio.

Las decisiones de reintento provienen de la semántica de negocio. HTTP GET, HEAD, PUT y DELETE tienen propiedades seguras o idempotentes en la especificación, pero las implementaciones deben respetar la semántica de esos métodos. POST es seguro de reintentar solo cuando una clave de idempotencia o un mecanismo equivalente hace que el resultado sea seguro. Un nombre de método gRPC no gana idempotencia automática; el contrato debe identificar estados y operaciones reintentables. Ambos enfoques necesitan límites de intentos, comprobaciones de plazo restante y protección contra la acumulación de reintentos en la pasarela, el SDK y la aplicación.

Un RPC de streaming añade manejo de consumidores lentos, contrapresión (backpressure), límites por mensaje, posiciones de reanudación y eventos duplicados. Si los consumidores deben reanudar desde un cursor, los eventos necesitan IDs estables o números de secuencia. Reabrir un stream por sí solo no puede demostrar que no haya brechas o duplicados.

Paso 4: Hacer que los contratos sobrevivan a la evolución continua

La compatibilidad de REST/JSON incluye estructura y semántica. Agregar un campo de respuesta es seguro solo si los clientes toleran campos desconocidos. Cambiar la paginación predeterminada, el orden o el significado de un enum puede dejar el JSON analizable mientras rompe la aplicación. Valida los lanzamientos con diferencias (diffs) de OpenAPI, el último SDK público, repetición de solicitudes registradas y aserciones de extremo a extremo.

Agregar un campo Protobuf normalmente es seguro a nivel binario en la red porque los lectores antiguos ignoran los campos desconocidos, pero el código de la aplicación aún puede romperse con nuevos enums o valores predeterminados. Nunca cambies el número de un campo existente. Reserva el número y el nombre de un campo eliminado para que ninguno se reutilice. Durante los lanzamientos continuos, prueba el cliente antiguo con el servidor nuevo y el cliente nuevo con el servidor antiguo; las pruebas de la misma versión son insuficientes.

Cuando los clientes del borde e internos necesitan la misma capacidad, comparte la lógica de dominio y una fuente de contrato explícita, y luego expón HTTP a través de transcodificación JSON o un adaptador ligero donde sea apropiado. El adaptador debe mapear el estado HTTP al estado gRPC, los encabezados a metadatos, los nombres de campo, la autenticación y las limitaciones de streaming. Dos implementaciones de negocio sincronizadas manualmente divergirán.

Paso 5: Dejar que la evidencia con forma de producción decida la migración

Utiliza la distribución real de payloads y la mezcla de métodos, no un microbenchmark que serializa un solo objeto diminuto. Contra la misma lógica de dominio, mide el rendimiento de extremo a extremo, p50/p95/p99, CPU de cliente y servidor, bytes transferidos, conexiones y memoria. Cubre llamadas unarias, mensajes pequeños y grandes, compresión, streams de servidor, consumidores lentos y tráfico entre zonas. Mantén el trabajo de base de datos y downstream idéntico para poder aislar el efecto del protocolo.

Ejecuta un método interno de bajo riesgo en modo de doble stack y realiza canarios por cliente. Compara los resultados de negocio, la clasificación de errores, los eventos de plazo excedido, el trabajo que continuó después de la cancelación, la amplificación de reintentos y la exhaustividad de las trazas. Expande solo después de cumplir con los umbrales de beneficio y confiabilidad por escrito. Mantener la API HTTP cuando la ganancia es insignificante es un resultado válido.

Respuesta de Ejemplo de Alta Calidad

“No etiquetaría toda la plataforma como REST o gRPC. Comenzaría evaluando quién llama a cada límite, quién controla las actualizaciones y el patrón de comunicación.

Para navegadores, aplicaciones móviles y socios, usaría HTTP de estilo REST con JSON. Funciona con el amplio ecosistema HTTP, mientras que OpenAPI proporciona un contrato legible por máquina, generación de SDKs y comprobaciones de compatibilidad. El webhook de terceros sigue siendo un HTTP POST porque el protocolo del emisor es una restricción externa. El ingreso verifica la firma, deduplica por ID de evento, persiste el evento y lo procesa de forma asíncrona.

El límite interno tiene 20,000 llamadas por segundo y un stream del servidor. Haría benchmarks con payloads con forma de producción. Si todos los clientes pueden usar clientes generados, los proxies, balanceadores de carga y monitoreo entienden gRPC, y el p99, la CPU o el ancho de banda mejoran lo suficiente como para alcanzar un umbral por escrito, usaría gRPC allí. Los métodos unarios y de streaming residen en .proto, pero cada llamada sigue recibiendo un plazo (deadline), la cancelación detiene el trabajo iniciado y solo se reintentan las operaciones contractualmente seguras.

Para la evolución, la API HTTP utiliza diffs de OpenAPI, SDKs antiguos y repetición semántica para detectar rupturas de paginación o enums. Los números de campo de Protobuf nunca cambian, los campos eliminados se reservan y los pares de cliente-servidor antiguos/nuevos se prueban de forma cruzada. Si las interfaces pública e interna comparten una capacidad, una sola implementación de dominio sirve a un adaptador HTTP y a un servicio gRPC, o utiliza transcodificación JSON después de que se verifica el mapeo.

Haría despliegues canary por cliente y vigilaría el p99 de extremo a extremo, CPU, bytes, mapeo de estado, amplificación de reintentos y exhaustividad de trazas. Si la mejora solo existe en un microbenchmark mientras el cuello de botella en producción sigue siendo la base de datos, no expandiría la migración solo por uniformidad de protocolo.”

Errores Comunes

• Igualar REST con HTTP/1.1 → Se confunden la semántica HTTP y las versiones de transporte → Indica que una API REST puede ejecutarse sobre HTTP/2 o HTTP/3.
• Afirmar que gRPC siempre es más rápido → El almacenamiento, la lógica de negocio o los proxies pueden dominar → Haz benchmarks del trabajo de dominio idéntico con payloads representativos y latencia de cola.
• Decir que REST no tiene un contrato fuerte → Esto ignora la descripción, generación y pruebas con OpenAPI → Compara flujos de trabajo de contratos reales, no una especificación descuidada con una mantenida.
• Llamar a gRPC nativo directamente desde un navegador → El navegador carece del control necesario de gRPC nativo → Utiliza gRPC-Web, transcodificación JSON o un BFF y ten en cuenta las limitaciones.
• Omitir un plazo (deadline) de gRPC → Un cliente puede esperar indefinidamente y consumir recursos → Deriva un plazo a partir del presupuesto de extremo a extremo y verifica la cancelación.
• Tratar la compatibilidad a nivel de cable de Protobuf como compatibilidad de la aplicación → Nuevos enums, valores predeterminados y significados aún pueden romper el código → Prueba versiones cruzadas y reserva números de campo.
• Habilitar reintentos en cada capa → Los fallos amplifican el tráfico y las escrituras pueden repetirse → Centraliza los reintentos y delimita las operaciones seguras, el tiempo restante y los intentos.
• Mantener un solo protocolo solo por uniformidad → Se sacrifican el costo de integración pública o las necesidades internas de streaming → Utiliza un borde HTTP explícito y un límite interno gRPC cuando esté justificado.

Preguntas de Seguimiento y Respuestas

Pregunta de seguimiento 1: ¿Debería una API interna con solo 500 QPS seguir utilizando gRPC?

El QPS por sí solo no puede decidir. Una organización con una plataforma gRPC madura, contratos generados en múltiples lenguajes y un requisito de streaming aún puede beneficiarse a 500 QPS. Un equipo con un servicio CRUD simple, herramientas HTTP maduras y amplio margen de rendimiento probablemente tenga un costo operativo menor con REST/HTTP+JSON. Escribe la métrica objetivo primero; no migres si la ganancia no se puede demostrar.

Pregunta de seguimiento 2: Una aplicación móvil pública puede usar un cliente gRPC generado. ¿Puede gRPC ser la API pública?

Puede ser un candidato para clientes móviles controlados, pero prueba proxies, redes empresariales, herramientas de depuración, manejo de certificados, compatibilidad de versiones y cadencia de lanzamientos. Los socios y navegadores aún pueden necesitar una API HTTP, por lo que gRPC público no elimina automáticamente el costo del protocolo dual. Decide por grupo de clientes en lugar de tratar la “Internet pública” como un solo cliente.

Pregunta de seguimiento 3: ¿Cómo puede un solo .proto exponer también una API JSON?

Anota los métodos con mapeos HTTP y utiliza transcodificación JSON o una pasarela. Antes del despliegue, verifica los nombres de campo, el comportamiento de nulos y valores predeterminados, el mapeo de estados HTTP y gRPC, metadatos y encabezados, autenticación, almacenamiento en caché y limitaciones de streaming. Una fuente de contrato .proto reduce la duplicación, pero la semántica del adaptador aún requiere pruebas.

Pregunta de seguimiento 4: ¿Cómo se reanuda un stream gRPC sin perder eventos?

El protocolo proporciona streaming y ordenamiento dentro de una sola RPC, no una suscripción de negocio duradera. Asigna a los eventos números de secuencia estables, conserva un log reproducible y haz que el cliente persista o envíe su cursor consumido al reconectarse. Define retención, manejo de cursores expirados y deduplicación. Si esos requisitos dominan, compara un log de mensajes o una cola en lugar de forzar una RPC para que actúe como tal.

Pregunta de seguimiento 5: Un benchmark muestra un mejor p99 con gRPC, pero en producción no es así. ¿Qué inspeccionas?

Desglosa la latencia en encolamiento del cliente, trabajo de DNS y conexión, proxies, serialización, lógica de aplicación, base de datos y llamadas downstream. Comprueba si los payloads de producción, la compresión, la reutilización de conexiones, TLS, el enrutamiento entre zonas y los reintentos ocultos coinciden con el benchmark. Si el protocolo es una fracción pequeña de la latencia total, optimiza el componente dominante en lugar de expandir la migración.