Las Multi Round-Trip Requests (MRTR) describen un patrón de interacción cliente-servidor donde la finalización de una operación lógica requiere una secuencia de intercambios de mensajes, cada uno con su propio ciclo de ida y vuelta (round-trip). A diferencia de una solicitud única que encapsula toda la información necesaria para una respuesta completa, en MRTR el cliente envía una solicitud inicial, espera una respuesta, procesa esa respuesta y luego, basándose en ella, envía una nueva solicitud, repitiendo este ciclo hasta que la operación se considera finalizada. Este modelo implica una dependencia secuencial entre las solicitudes y sus respuestas intermedias.
Este patrón se observa comúnmente en protocolos de red de bajo nivel y en interacciones con sistemas distribuidos. Por ejemplo, en el establecimiento de una conexión TCP, el 'three-way handshake' es un MRTR. Otro ejemplo es la autenticación basada en desafíos (challenge-response authentication), donde el servidor envía un desafío, el cliente lo procesa y devuelve una respuesta, y el servidor verifica. En bases de datos distribuidas, ciertas operaciones complejas que requieren múltiples fases de coordinación entre nodos (como algunas transacciones distribuidas o la recuperación de datos de múltiples particiones con lógica de agregación en el cliente) pueden manifestarse como MRTR desde la perspectiva de la aplicación cliente.
Para un arquitecto, comprender las MRTR es crucial debido a su impacto directo en la latencia y el rendimiento. Cada round-trip añade latencia de red (RTT) a la duración total de la operación. En entornos de alta latencia o con ancho de banda limitado, un diseño que favorezca MRTR excesivas puede degradar significativamente la experiencia del usuario y la eficiencia del sistema. Los arquitectos deben evaluar si es posible consolidar múltiples solicitudes en una sola (Single Round-Trip Request o SRTR) o utilizar técnicas como pipelining o multiplexing para reducir el número efectivo de RTTs. La elección entre MRTR y SRTR implica un trade-off entre la complejidad del protocolo (MRTR puede ser más simple de implementar en cada paso individual) y el rendimiento general del sistema, especialmente en arquitecturas de microservicios donde las interacciones inter-servicio pueden acumular latencia si no se diseñan cuidadosamente.