Una de las funcionalidades mas complejas de Admin Finance es su sistema de sincronizacion peer-to-peer (P2P). A diferencia de las aplicaciones que dependen de un servidor central, Admin Finance permite que dos dispositivos se conecten directamente entre si para sincronizar datos financieros, incluso en redes sin internet.

Modelo Offline-First

La filosofia de diseno del sistema es offline-first: toda la datos vive localmente y las operaciones siempre funcionan, incluso sin red.

SQLDelight como Fuente de Verdad

Toda la informacion se almacena en SQLite a traves de SQLDelight:

-- Transaction.sq
SELECT * FROM Transaction
  WHERE date BETWEEN :startDate AND :endDate
  ORDER BY date DESC;

INSERT INTO Transaction (type, amount, categoryId, date, description, companyId)
VALUES (:type, :amount, :categoryId, :date, :description, :companyId);

DELETE FROM Transaction WHERE id = :id;

Los usuarios pueden crear, editar y eliminar transacciones sin necesidad de conectividad. Los cambios se sincronizan cuando se restablece la conexion.

Protocolo de Sincronizacion

El protocolo se implementa sobre sockets TCP y define un conjunto de mensajes serializados:

Mensajes del Protocolo

MensajeDireccionDescripcion
DISCOVERCliente → ServidorAnuncio de broadcast para encontrar dispositivos
DISCOVER_ACKServidor → ClienteRespuesta al descubrimiento con informacion del dispositivo
SYNC_REQUESTCliente → ServidorSolicitud de sincronizacion con timestamp local
SYNC_DATAServidor → ClienteDatos del servidor para sincronizar
SYNC_ACKCliente → ServidorConfirmacion de datos recibidos
ERRORVariableMensaje de error en cualquier paso
CLOSEVariable Cierre de conexion

Fase de Descubrimiento

  1. El dispositivo emite un mensaje DISCOVER via broadcast UDP
  2. Todos los dispositivos con Admin Finance responden con DISCOVER_ACK
  3. El mensaje incluye: nombre del dispositivo, version de la app, timestamp de ultima sincronizacion
  4. El usuario selecciona el dispositivo con el que desea sincronizar

Fase de Sincronizacion

  1. El cliente envia SYNC_REQUEST con su ultimo timestamp de sincronizacion
  2. El servidor busca transacciones modificadas desde ese timestamp
  3. Los datos se serializan en formato JSON y se envian via SYNC_DATA
  4. El cliente recibe y aplica los cambios
  5. El cliente confirma con SYNC_ACK
  6. El servidor envia actualizaciones del cliente al servidor (bidireccional)

Algoritmo de Fusion (SyncMerger)

Cuando ambos dispositivos modifican la misma transaccion, se necesita un algoritmo de fusion:

class SyncMerger {
    fun merge(
        localTransaction: Transaction,
        remoteTransaction: Transaction
    ): Transaction {
        // Si ambos modificaron el mismo campo,
        // gana el mas reciente por timestamp
        return if (remoteTransaction.updatedAt > localTransaction.updatedAt) {
            remoteTransaction
        } else {
            localTransaction
        }
    }
}

Las reglas de fusion son:

  • Registro nuevo en un dispositivo — Se agrega automaticamente al otro
  • Registro eliminado en un dispositivo — Se elimina en el otro
  • Registro modificado en ambos — Gana el mas reciente (last-write-wins por timestamp)
  • Registro modificado localmente + eliminado remotamente — Se elimina (elimination prevalece)

Arquitectura de Implementacion

SyncService (orchestrador)

Clase principal que gestiona todo el ciclo de vida:

  • Escucha de descubrimientos
  • Manejo de conexiones TCP
  • Orquestacion del protocolo de sincronizacion
  • Gestion de estados de conexion
  • Reconexion automatica en caso de fallo

SyncProtocol (protocolo)

Define el handshake y la comunicacion de datos:

  • Serializacion/deserializacion de mensajes
  • Control de flujo (backpressure)
  • Manejo de errores de red
  • Timeouts y reintentos

SyncMerger (fusion)

Implementa el algoritmo de fusion de datos:

  • Compara timestamps de modificaciones
  • Aplica reglas de eliminacion y actualizacion
  • Genera lista de cambios aplicados
  • Log de operaciones para auditoria

Seguridad y Confiabilidad

Control de Version

Cada mensaje de sincronizacion incluye la version de la app. Si las versiones no son compatibles, la sincronizacion se rechaza para evitar corrupcion de datos.

Integridad de Datos

Antes de aplicar datos remotos:

  • Se valida el esquema de datos
  • Se verifica la integridad referencial
  • Se realiza todo dentro de una transaccion SQL
  • En caso de error, se revierte la transaccion completa

Estado de Sincronizacion

Cada transaccion tiene un campo de estado que indica:

  • PENDING_SYNC — Modificada localmente, pendiente de sincronizar
  • SYNCED — Sincronizada con el ultimo peer
  • SYNC_ERROR — Error al sincronizar, reintento pendiente

Limitaciones y Consideraciones

  • Conexion directa — Requiere que ambos dispositivos esten en la misma red local
  • Unico peer a la vez — La implementacion actual soporta sincronizacion con un solo dispositivo a la vez (no multi-peer)
  • Datos en claro — Los datos se transfieren sin encriptacion (consideracion de seguridad para futuros pasos)

Resultados

El sistema de sincronizacion permite a los usuarios mantener sus datos financieros actualizados en multiple dispositivos sin depender de servicios cloud externos. La arquitectura offline-first garantiza que la aplicacion siempre funciona, independientemente de la disponibilidad de red.