RPC (Remote Procedure Call) es un paradigma de comunicación interproceso que abstrae la complejidad de la comunicación de red, permitiendo que un cliente ejecute una función o procedimiento en un servidor remoto como si fuera una llamada local. El mecanismo subyacente implica la serialización de los parámetros de la llamada en el cliente (marshalling), su transmisión a través de la red, la deserialización en el servidor (unmarshalling), la ejecución del procedimiento remoto y, finalmente, la serialización y transmisión del resultado de vuelta al cliente. Esto crea una ilusión de localidad, simplificando significativamente el desarrollo de aplicaciones distribuidas al ocultar los detalles de la red.
En el mundo real, RPC es la base de numerosos sistemas distribuidos y microservicios. Ejemplos prominentes incluyen gRPC de Google, que utiliza Protocol Buffers para la serialización y HTTP/2 para el transporte, siendo ampliamente adoptado en arquitecturas de microservicios por su rendimiento y soporte multi-lenguaje. Apache Thrift es otro framework RPC popular que soporta múltiples lenguajes y protocolos de transporte. Otros ejemplos incluyen el uso de RPC en sistemas operativos distribuidos como Sun RPC (ahora ONC RPC), y en bases de datos distribuidas o sistemas de almacenamiento donde los nodos se comunican para replicación o consistencia. Incluso las APIs RESTful, aunque conceptualmente diferentes, a menudo se implementan sobre mecanismos de comunicación que comparten principios con RPC a un nivel inferior.
Para un arquitecto, RPC es fundamental porque define un modelo de interacción clave en sistemas distribuidos. La elección de un framework RPC implica considerar trade-offs críticos como el rendimiento (serialización, transporte), la interoperabilidad entre lenguajes, la facilidad de uso, la capacidad de evolución del esquema (versioning), y la resiliencia (manejo de errores, reintentos, timeouts). Un diseño RPC eficiente puede reducir la latencia y el consumo de recursos, mientras que una mala elección puede introducir cuellos de botella y complejidad innecesaria. Es crucial entender cómo el framework maneja la semántica de la llamada (ej. 'at-most-once', 'at-least-once', 'exactly-once'), la gestión de la conectividad y la seguridad, para construir sistemas robustos y escalables que cumplan con los requisitos de disponibilidad y consistencia.