Tokencars

Introducción

Tokencars era una startup que tokenizaba autos de lujo y de colección: cada auto se dividía en tokens, y cualquiera podía comprar una parte y después venderla.

Hicimos el producto completo: la app mobile, el backoffice, la API y la infraestructura.

Qué hacía la app

• Catálogo de autos, con fotos, precio del auto, precio del token y cantidad de tokens disponibles.
• Compra de tokens y un mercado secundario, donde los usuarios publicaban órdenes de venta y otros las compraban.
• Billetera con el balance, el portfolio de tokens y el historial de operaciones.
• Depósitos y retiros con tarjeta de crédito y con stablecoins.
• Un PIN para confirmar cada transacción, y comentarios y favoritos en cada auto.

Enfoque técnico

Lideré el proyecto técnicamente: definí la arquitectura, lideré al equipo y programé con ellos las partes más difíciles.

• La API era un monolito modular en Kotlin con Javalin y MongoDB. Tenía cuatro módulos (marketplace, exchange, ledger y seguridad), cada uno con sus capas de aplicación, dominio, HTTP e infraestructura.
• Cada módulo exponía una facade: una clase con las operaciones que los demás podían usar. Por ejemplo, la del ledger permitía crear billeteras, emitir tokens y registrar operaciones de compra y venta. Por dentro, la facade ejecutaba los comandos y queries del módulo a través de un bus. Los módulos se armaban en un solo lugar, que le pasaba a cada uno las facades de los módulos que necesitaba, así las dependencias entre módulos quedaban explícitas.
• Los módulos también reaccionaban a eventos. Por ejemplo, cuando entraba un depósito cripto, exchange lo convertía a dólares y lo acreditaba en el ledger.
• Cada comando declaraba qué roles podían ejecutarlo, y un middleware del bus verificaba los permisos.
• Desarrollamos la API con TDD. Los casos de uso se testeaban con repositorios en memoria y con las facades de los otros módulos simuladas, así cada módulo se probaba de forma aislada. Además, los endpoints tenían tests end-to-end.
• La propiedad de los tokens se registraba en un ledger externo, los pagos con tarjeta pasaban por Decidir y los depósitos cripto por CryptoCheckout. Las integraciones estaban detrás de interfaces del dominio, con implementaciones simuladas para desarrollo y tests.
• Las tareas asíncronas se procesaban con un worker y RabbitMQ.
• La app estaba hecha en React Native y el backoffice en Next.js, los dos con TypeScript.
• La infraestructura corría en AWS sobre Kubernetes (EKS) y estaba aprovisionada con Terraform.
• Había un pipeline en GitHub Actions para cada componente: API, backoffice, app e infraestructura.