La puerta de enlace API que construimos por nuestra cuenta nos ahorró el 38% de los costos de llamadas a terceros, pero nos llevó a tropezar con problemas de adaptación entre regiones.

La semana pasada, nuestro equipo de herramientas de comercio electrónico en el Sudeste Asiático acabó de revisar la cuenta de costos técnicos de Q1, y el colega encargado de las interfaces de pago casi salta de alegría: al reemplazar el gateway externo que utilizábamos anteriormente por uno desarrollado internamente, el costo mensual de las llamadas a la API disminuyó un 38% directamente. Sin embargo, durante las pruebas de fase gris antes de las promociones, la tasa de éxito de los pagos de los usuarios en el nodo de Singapur cayó repentinamente en un 6 por ciento. Después de investigar durante mucho tiempo, descubrimos que las reglas de fusión regional del gateway no habían sido adaptadas adecuadamente.

Primero, entendamos qué es un gateway propio (autoconstruido).

En resumen, lo que se propone es escribir un propio conjunto de programas de entrada de tráfico que procesen todas las solicitudes de API externas, las llamadas de retorno de terceros y las interacciones entre servicios, reemplazando así el servicio de gateway de terceros que se compró anteriormente. La versión que estamos utilizando ahora funciona en 4 servidores remotos con procesadores de 2 núcleos (4G), y cada uno de ellos puede manejar 1200 solicitudes por segundo, lo que cubre completamente nuestras necesidades diarias de 1.8 millones de llamadas de pago y sincronización de productos.

Los tres beneficios reales que puedes obtener

• Lo primero es que realmente podemos reducir los costos. Antes utilizábamos un gateway de terceros que cobraba por cada solicitud, lo que nos costaba 2100 dólares al mes. Ahora, con nuestro propio servidor y sistema de monitoreo, los costos mensuales son de menos de 1300 dólares, y además no estamos sujetos a aumentos de precios por categorías.
• Lo siguiente es que las reglas ahora están completamente bajo nuestro control. Antes, el límite de flujo de datos de los gateways de terceros era uniforme, y durante las promociones especiales teníamos que solicitar permisos temporales para aumentar el límite de flujo de las interfaces de pago, lo que requería un proceso de solicitud que duraba 3 días laborales. Ahora, podemos modificar la configuración en el backend y que los cambios surtan efecto en solo 10 segundos.
• Finalmente, no es necesario utilizar terceros para el manejo de datos. Al desarrollar herramientas de comercio electrónico, tenemos que manejar muchos callbacks de pago de los usuarios. Antes, todas las solicitudes pasaban por los servidores de proveedores externos, pero ahora todos los datos sensibles se procesan en nuestros propios servidores, lo que ha reducido significativamente los costos de cumplimiento con las regulaciones.

No te apresures a construirlo; primero echa un vistazo a los errores que hemos cometido.

El primer problema fue la adaptación de la red entre diferentes regiones. Al principio, colocamos el nodo principal del gateway en Singapur, y cuando abrimos la sucursal en Malasia, simplemente redirigimos todo el tráfico allí. Como resultado, las solicitudes de los usuarios locales tenían que pasar primero por Singapur antes de llegar a su destino, lo que añadía una demora de 200 ms en la conexión. Muchos usuarios, impacientes, cerraban la página de pago. Tuvimos que pasar una semana completando la configuración de los nodos de borde en Malasia.

El segundo problema es la omisión de reglas de seguridad. Anteriormente, los gateways de terceros incluían por defecto protección contra DDoS e interceptación de solicitudes maliciosas; sin embargo, al configurar nuestro propio sistema, olvidamos agregar esta protección. El tercer día después de su lanzamiento, nuestro sitio recibió 200,000 solicitudes inválidas provenientes de bots, lo que casi causó la interrupción del servicio de nuestras interfaces de inventario.

El tercer problema es que los costos de operación y mantenimiento son más altos de lo esperado. Antes, cuando había problemas con el gateway de terceros, simplemente contactábamos al servicio al cliente; ahora, los tres desarrolladores de backend tenemos que turnarnos para hacer guardias nocturnas y monitorear el gateway. El mes pasado, solo la resolución de fallos en el gateway ocupó el 15% del tiempo de trabajo de todos.

¿Qué tipo de equipo es adecuado para formar? No desperdicies tu tiempo en aquellos que no lo sean.

Si tu equipo realiza más de un millón de llamadas a la API diariamente, o si necesitas manejar una gran cantidad de datos sensibles, o si ya estás harto de las limitaciones de velocidad y los procesos de solicitud de terceros, entonces construir tu propio gateway definitivamente merece la inversión.

Pero si tu equipo tiene menos de 2 desarrolladores de backend, o si el negocio todavía está en una fase de pruebas rápidas y las reglas de las interfaces cambian cada semana, realmente no hay necesidad de invertir tiempo en ello. Puedes usar un gateway externo por ahora; puedes cambiarlo más adelante, cuando el negocio se haya estabilizado.

3 consejos prácticos para aquellos que lo hacen por primera vez

1. Comencemos con un escenario específico, sin reemplazar todo de inmediato. Al principio, solo transferimos el tráfico de las interfaces de pago a nuestro propio gateway, y funcionó sin problemas durante dos semanas antes de comenzar a migrar gradualmente otras interfaces. Incluso si surgen problemas, solo afectarán al escenario de pago y no causarán la paralización de todo el sitio web.
2. Es esencial realizar pruebas de carga a nivel regional. Esto es especialmente importante para los negocios internacionales; no basta con probar en el entorno local antes de lanzar el producto. Busca nodos de prueba en tu mercado objetivo y ejecuta pruebas de carga durante 24 horas para verificar si hay problemas con la latencia o la tasa de pérdida de paquetes.
3. No te ahorres en el panel de monitoreo. Al menos mantén un ojo atento a tres indicadores clave: la cantidad de solicitudes, la tasa de éxito y la latencia. Establece umbrales de alerta adecuados para que no esperes a que los usuarios se quejen para darte cuenta de que el gateway no está funcionando.

Problemas comuns

Pregunta: ¿Es necesario escribirlo en Go o Rust?
No es necesario, nuestra primera versión fue escrita en Node.js y puede soportar picos de carga sin problemas. Simplemente use el lenguaje con el que su equipo esté más familiarizado; si luego surgen cuellos de botella de rendimiento, siempre podremos cambiarlo.

Pregunta: ¿Cuál es mejor en comparación con los gateways de los proveedores de servicios en la nube?
Los gateways de los proveedores de servicios en la nube son más flexibles que los de terceros, pero aún así no ofrecen la misma libertad que aquellos que se construyen uno mismo. Si no quieres estar atado a un proveedor de servicios en la nube en particular, construir tu propio sistema es la opción más económica.