Nikita Letov, arquitecto de sistemas fintech, Java Tech Lead, miembro sénior de IEEE y Hackathon Raptors Fellow, compartió sus enfoques para crear una autorización confiable y explicó qué principios tecnológicos forman la arquitectura de los servicios bancarios y de pago modernos. El 5 de abril, usuarios de toda Rusia se enfrentaron a fallos en el funcionamiento del sistema de pagos rápidos (SPB), así como en el funcionamiento de las aplicaciones de Alfa-Bank y T-Bank.
Para las grandes aplicaciones bancarias, el funcionamiento ininterrumpido es fundamental, ya que cualquier tiempo de inactividad y fallo está directamente relacionado con los riesgos de pérdidas financieras. Es precisamente en estos momentos cuando se hacen evidenciales los nodos más vulnerables, uno de los cuales es la autorización: el punto de entrada de los usuarios a la aplicación, dice Nikita Letov, ingeniero de software y experto en la construcción de sistemas tolerantes a fallos. Como líder técnico y responsable del desarrollo de Java en Rosbank, coordinó el trabajo de varios equipos, fue responsable de la arquitectura de la banca móvil y de los elementos clave del sistema , desde la autorización hasta la disponibilidad del servicio. Consiguió aumentar significativamente la estabilidad de la aplicación y reducir en decenas de veces las quejas de los usuarios sobre dificultades con la autorización. Nikita es miembro de las asociaciones internacionales de ingenieros de desarrollo IEEE y Hackathon Raptors, que exigen altos requisitos a sus candidatos: su nivel debe corresponder a los estándares mundiales. En una entrevista, el experto explicó qué soluciones arquitectónicas permiten evitar la mayoría de los problemas típicos de autorización y soportar la carga sin fallos, en qué se diferencia el desarrollo en fintech de otros sectores y qué direcciones técnicas estarán en la cima de la demanda en los próximos años.
Los usuarios esperan un funcionamiento rápido e ininterrumpido de las aplicaciones bancarias: 10 segundos de retraso al iniciar sesión ya causan irritación. Usted ha diseñado la arquitectura de autorización en una aplicación con millones de usuarios y conoce la cocina que hay detrás de una pantalla lacónica: altas cargas, seguridad, integraciones. ¿Qué tareas se consideran hoy en día las más difíciles en su desarrollo?
Los requisitos para las soluciones fintech se han vuelto realmente altos, y los equipos de TI se enfrentan a una serie de desafíos importantes. Uno de los más importantes es garantizar la alta disponibilidad del servicio. Las aplicaciones bancarias deben funcionar 24 horas al día, 7 días a la semana y soportar miles, y a veces millones, de sesiones de usuario simultáneas. Al mismo tiempo, la seguridad sigue siendo una prioridad. Los datos financieros siempre son de interés para los atacantes, cualquier vulnerabilidad puede acarrear graves consecuencias financieras y de reputación. Otra característica importante es que los productos fintech no viven aislados. Casi siempre están relacionados con muchos sistemas externos: desde agencias gubernamentales hasta compañías de seguros y plataformas de socios. Estas integraciones no solo deben configurarse, sino también construirse de forma que se garantice una transitividad de datos fiable y una resistencia durante las actualizaciones. Un desafío aparte es la escalabilidad. La base de usuarios crece constantemente: cada día, y a veces cada minuto, llegan nuevos clientes o regresan los antiguos, y las soluciones que funcionaban bien ayer pueden no soportar esta carga mañana. Por lo tanto, la arquitectura debe diseñarse inicialmente teniendo en cuenta el crecimiento: flexible, ampliable, basada en un profundo conocimiento del diseño del sistema. Y, por supuesto, no hay que olvidar el cumplimiento de los requisitos reglamentarios. Esta es, quizás, una de las tareas más difíciles y menos queridas. Los bancos, corredores y otras organizaciones fintech operan bajo la atenta supervisión de los reguladores estatales, por lo que hay que tener en cuenta muchas normas legislativas. Muy a menudo, esto reduce en gran medida la elección de tecnologías que se pueden aplicar para resolver una u otra tarea.
Usted mencionó garantizar la escalabilidad y la estabilidad de la arquitectura como una de las tareas clave. En su caso, se trata de una aplicación utilizada por casi 3,5 millones de clientes. ¿Qué cambia en el diseño de la autorización con una carga elevada? ¿A qué situaciones no estándar hay que enfrentarse y cómo protegerse de ellas ya en la fase de arquitectura?
Cuando el sistema tiene una base de usuarios de millones, la autorización deja de ser simplemente una comprobación de nombre de usuario y contraseña: se convierte en un servicio completo de alta carga, que está sujeto a los mismos requisitos que otros componentes críticos del sistema: debe ser rápido, fiable y seguro. Lo primero que cambia es la escala y el almacenamiento de las sesiones. Los enfoques clásicos, como el almacenamiento de sesiones de usuario en la memoria, ya no son adecuados: no se escalan horizontalmente. Por lo tanto, la autorización debe ser stateless, y todas las solicitudes deben autenticarse mediante tokens, por ejemplo, JWT. Al mismo tiempo, la autorización se divide en dos modos: completo, con comprobación de contraseña y 2FA, y rápido, cuando el usuario inicia sesión con un token emitido anteriormente. En ambos casos, es fundamental garantizar un intercambio seguro de tokens para que un atacante no pueda interceptarlo. Otro punto importante es la irregularidad de la carga. Por ejemplo, el lunes por la mañana o el último día del mes, cuando se cobra el salario, la carga al iniciar sesión en la aplicación móvil puede ser anormalmente alta en comparación con el tráfico normal. Estos picos deben poder gestionarse sin permitir el fallo en cascada del servicio. Aquí ayudan soluciones como Circuit Breaker, para aislar los componentes defectuosos, o el autoescalado dinámico, que permite aumentar rápidamente el número de copias de los servicios en función de las cargas. Y, por supuesto, no se puede prescindir de los mecanismos de fallback. Los fallos son posibles incluso con un sistema diseñado a la perfección, y es importante que se gestionen de forma transparente para el usuario: ya sea mediante lógica de reserva o, si es realmente crítico, con la oferta de pasos alternativos para que el usuario pueda completar la tarea.
En Rosbank hubo un período en el que los usuarios se enfrentaban regularmente a problemas al autorizar la aplicación. Usted consiguió resolver el problema: las quejas sobre este tema prácticamente desaparecieron. ¿Qué problemas con el punto de entrada a la aplicación detectó, cómo se manifestaron y qué hizo?
Este fue uno de esos casos en los que, aparentemente, todo funciona, pero en realidad los clientes se enfrentaban a errores todos los días. Para mí, este fue precisamente el caso en el que necesitaba "profundizar" y no aceptar la arquitectura como algo dado. Los problemas se manifestaban en el lado del usuario: alguien no podía iniciar sesión después de actualizar la aplicación, a alguien la autorización le llevaba hasta 15 segundos, y a algunos clientes no les pasaba nada: simplemente una pantalla en blanco. Estas solicitudes llegaban constantemente al soporte técnico y representaban hasta un tercio de todos los tickets. Lo primero que hice fue rastrear las solicitudes de los clientes. Implementamos el rastreo distribuido y mejoramos el sistema de registro en todas las etapas clave del proceso de autorización, desde la gateway hasta los servicios de backend responsables. Esto nos permitió determinar con precisión dónde se "rompía la cadena". Como resultado, resultó que había muchos problemas en el proceso de autorización. Uno de ellos estaba relacionado con una routing inconsistente: la gateway dirigía a los clientes a versiones de servicios no coincidentes. Otro, con una fuga de contexto de seguridad durante la autorización. Además, hubo problemas con la disponibilidad de la caché en la red, en la que se almacenaba temporalmente metainformación sobre los tokens. La mayoría de los problemas se resolvieron reescribiendo el código de la gateway y los filtros del servicio de autorización. Y el fallo con el acceso a la caché resultó estar causado por una razón banal: la ausencia de reglas de red en el orquestrador de servicios de backend. Este caso me demostró lo importante que es desarrollar las áreas críticas del sistema no solo como una característica separada, sino como una plataforma de ingeniería completa, donde todo está pensado, desde la UX hasta el SLA.
Durante su trabajo en el banco, su aplicación se volvió notablemente más estable: la disponibilidad aumentó hasta el 99,97%. ¿Qué tecnología aplicó y cómo logró una estabilidad de funcionamiento tan alta?
Después de que me enfrenté a un routing inconsistente y comencé a construir la transparencia de las solicitudes, decidí implementar Spring Cloud Gateway. Pero es importante entender que la estabilidad y la alta disponibilidad de la aplicación no se logran con una sola tecnología, no existe la llamada "bala de plata" que resuelva todos los problemas a la vez. Spring Cloud Gateway no dio un aumento instantáneo o "mágico" de la disponibilidad, pero jugó un papel en el logro de este indicador. El resultado se logró gracias al trabajo coordinado y sistemático de todos los equipos de desarrollo. Desde el principio, trabajando como líder técnico, construí los procesos de tal manera que minimizara la probabilidad de errores y defectos ocultos. Y en caso de que ocurrieran, garantizar una reacción lo más rápida posible. Fue entonces cuando tomamos la decisión de cultivar nuestros propios ingenieros SRE dentro del equipo, y implementamos con éxito esta dirección. Como resultado, una combinación de factores: la difusión de la arquitectura basada en eventos en toda la parte backend de la plataforma de banca a distancia, un fuerte liderazgo técnico, procesos de desarrollo y pruebas maduros, así como una elección inteligente de tecnologías, nos permitieron alcanzar indicadores de disponibilidad muy altos para una aplicación bancaria de alta carga.
Nikita, usted se comunica activamente con la comunidad profesional: participa en conferencias especializadas, es miembro de las asociaciones IEEE y Hackathon Raptors, donde solo se aceptan especialistas de alto nivel que ya se han probado a sí mismos. ¿Hay alguna tendencia actual en el desarrollo de fintech que usted llamaría sobrevalorada, y qué, por el contrario, se está desarrollando silenciosamente, pero pronto "disparará"?
Sí, es una pregunta interesante. En mi opinión, en este momento está muy sobrevalorada la dirección de la implementación de modelos LLM en aplicaciones sin una comprensión clara de los objetivos y las limitaciones. Y esto es cierto no solo para la industria fintech, sino también para todo el sector de TI en general. Muy a menudo se ve así: "Añadamos IA porque está de moda", pero al mismo tiempo no se resuelve un problema empresarial real. Sí, la tecnología es potente, pero debe aplicarse de forma consciente, teniendo en cuenta los requisitos reglamentarios, la interpretabilidad y la seguridad. Como resultado de este uso irreflexivo de la IA, a menudo vemos hermosas versiones de demostración y MVP, pero muy poca utilidad real en producción. Pero lo que, en mi opinión, está infravalorado y seguramente "disparará" en un futuro próximo, y en algunos lugares ya ha disparado, es la difusión de arquitecturas basadas en eventos y el procesamiento asíncrono de eventos. Especialmente en los bancos, donde antes todo se basaba en solicitudes REST síncronas. Ahora, cuando la carga está creciendo y millones de operaciones se realizan en paralelo, la transición a enfoques reactivos y el uso de brokers de mensajes como Apache Kafka o Pulsar se están convirtiendo no solo en una "ventaja", sino esencialmente en una necesidad. Ya se observa una tendencia: en muchos proyectos, el event sourcing permite realizar retrocesos a cualquier punto de restauración, garantizar una auditoría flexible y recopilar análisis cercanos al tiempo real sin cargas sofocantes en las bases de datos. Además, con este enfoque no hay vinculación a una base de datos específica: se puede configurar en cualquier momento el consumo de eventos desde el broker a cualquier base de datos adecuada, cambiando al mismo tiempo la estructura de datos. Otra tendencia "silenciosa", no tanto relacionada con el desarrollo como con la infraestructura, es la creciente popularidad de los enfoques serverless dentro de las corporaciones. Antes esto parecía el destino de las startups, pero ahora incluso las grandes empresas fintech están empezando a utilizar activamente FaaS y contenedores lightweight para resolver tareas: desde escenarios AML hasta la generación de informes. Todo esto acelera el time-to-market y proporciona flexibilidad, especialmente en condiciones de presupuestos limitados y equipos pequeños. Así que el ruido no siempre es un indicador de madurez, y viceversa: las cosas más útiles a menudo llegan en silencio, pero para quedarse.
Ahora en la página principal
