El Recovery Point Objective (RPO) es una métrica fundamental en la estrategia de continuidad del negocio y recuperación ante desastres (BCDR). Representa el punto en el tiempo más reciente al que se pueden recuperar los datos de un sistema después de una interrupción o fallo. En esencia, cuantifica la cantidad máxima de datos (medida en tiempo, por ejemplo, 1 hora, 15 minutos, 0 segundos) que una organización puede permitirse perder sin incurrir en daños inaceptables. Un RPO de 0 significa que no se permite ninguna pérdida de datos, lo que generalmente requiere replicación síncrona o técnicas de "zero data loss".
En el mundo real, el RPO se implementa y gestiona a través de diversas tecnologías y estrategias de replicación de datos. Por ejemplo, para un RPO de varias horas, las copias de seguridad diarias o la replicación asíncrona de bases de datos (como en PostgreSQL con WAL shipping o MySQL con binlog replication) son comunes. Para RPOs más estrictos (minutos), se utilizan soluciones como la replicación continua de datos (CDR) o la replicación basada en snapshots frecuentes (ej. ZFS snapshots, AWS EBS snapshots). Para un RPO cercano a cero, se emplean la replicación síncrona (ej. Oracle Data Guard en modo síncrono, clústeres de almacenamiento SAN con replicación síncrona entre sitios) o sistemas distribuidos con consenso fuerte (ej. Apache Kafka con replicación y ACKs a múltiples réplicas, Google Spanner).
Para un arquitecto de sistemas, el RPO es una consideración crítica que impulsa decisiones de diseño fundamentales y trade-offs significativos. Un RPO más bajo (menos pérdida de datos) generalmente implica mayor complejidad, mayores costos de infraestructura (más ancho de banda, más almacenamiento, hardware más potente) y potencialmente mayor latencia en las operaciones de escritura debido a la necesidad de replicación síncrona o confirmaciones de múltiples réplicas. Por el contrario, un RPO más alto es más económico y simple de implementar, pero conlleva un riesgo mayor de pérdida de datos y un impacto potencial más severo en el negocio. El arquitecto debe equilibrar los requisitos del negocio (definidos por el impacto de la pérdida de datos) con las limitaciones técnicas y presupuestarias, seleccionando las tecnologías y patrones de replicación adecuados para cumplir con el RPO objetivo sin sobre-diseñar ni sub-diseñar la solución.