ArchiFrame nació en 2019 como un proyecto interno para resolver un problema concreto: la integración de módulos biométricos en sistemas legacy. Lo que comenzó como una librería de conexión para un cliente del sector financiero, se convirtió en un framework de arquitectura que hoy documenta flujos completos de identidad digital.
La decisión clave llegó en 2021, cuando abandonamos la compatibilidad con versiones anteriores de nuestro SDK para priorizar un modelo de eventos asíncronos. Ese cambio, aunque impopular entre algunos integradores, redujo los tiempos de verificación en un 40% y nos permitió publicar esquemas de bases de datos que los equipos pueden adaptar sin reescribir su lógica de negocio.
Hoy, el repositorio de documentación incluye más de 120 patrones de integración, y cada release se acompaña de un changelog que detalla las decisiones de diseño. No buscamos ser la solución más grande, sino la más predecible para quien necesita auditar cada paso de su pipeline de identidad.
Respuestas directas sobre el uso del framework, sin rodeos legales ni promesas vacías.
La API es el punto de acceso HTTP para verificar identidades desde cualquier lenguaje. El SDK envuelve esa API en funciones nativas para Python, Node y Go, y agrega manejo de reintentos y validación local de respuestas. Si tu equipo ya trabaja con llamadas REST, la API basta. Si preferís abstracción, usá el SDK.
No almacenamos plantillas biométricas crudas. El framework guarda solo un hash irreversible de la plantilla, junto con metadatos de la captura (timestamp, dispositivo, calidad de imagen). La arquitectura de esquemas está documentada en la guía de integración, con tablas de anclaje y particionado por tenant para aislar cada cliente.
Con una conexión estable, el tiempo de respuesta ronda los 300 ms por solicitud. Eso incluye el preprocesamiento de la imagen, la comparación contra el hash y el registro del evento. Si necesitás menos de 200 ms, la sección de optimización del manual explica cómo configurar caché distribuida y conexiones persistentes.
El SDK incluye un modo de degradación controlada: podés definir una política de reintentos con backoff exponencial y un timeout máximo. Si el servicio sigue caído, la solicitud se rechaza con un código de error explícito, nunca con un falso positivo. El registro de eventos queda en la cola local para auditoría posterior.
Si tu caso no aparece acá, escribinos y te respondemos con el detalle técnico que necesitás.
La línea de tiempo resume los puntos de inflexión en el desarrollo del framework. Cada etapa responde a una decisión de arquitectura concreta, no a un calendario de marketing.
Se definió el motor de coincidencia biométrica y el esquema inicial de la base de datos. La primera prueba de concepto procesaba 200 verificaciones por minuto con una tasa de error aceptable para entornos controlados.
El SDK pasó de un prototipo interno a una librería pública con documentación completa. Los primeros integradores externos lo usaron en sistemas de control de acceso sin conexión a internet.
Se publicó la API REST con endpoints de verificación en tiempo real. En paralelo, el equipo incorporó soporte para credenciales verificables, lo que permitió a los clientes emitir y validar identidades sin depender de un servidor central.
La optimización de caché y balanceo de carga bajó el tiempo de respuesta promedio de 800 ms a 180 ms. Se habilitaron nodos en tres regiones para acercar la verificación a los usuarios finales.