Laboratorio

Proyectos propios, más chicos que los casos, donde pruebo patrones que todavía no apliqué en un trabajo o que quiero entender a fondo. No son trabajos para clientes.

  1. En diseño

    Un modelo de lectura delante de una fuente lenta

    Los cambios de un sistema lento se publican como eventos, un consumidor los materializa en Redis y la API responde desde ahí. Una idea que conozco del trabajo, llevada a un proyecto abierto donde cada decisión se puede revisar.

    Qué quiero demostrar

    • Outbox transaccional: el dato y su evento se guardan en la misma transacción.
    • Idempotencia: el mismo evento dos veces no duplica nada.
    • Una cola de mensajes muertos para los eventos que siempre fallan.
    • Circuit breaker: si la fuente se cae, la API no se cae con ella.
    • Un script que mide la latencia antes y después, con los números en el README.

    Go · PostgreSQL · Pub/Sub · Redis · Docker Compose

  2. En diseño

    Un modelo de IA como dependencia poco confiable

    La segunda fase del proyecto anterior: enriquecer cada evento con un campo generado por un modelo, sin que el pipeline dependa de que el modelo responda.

    Qué quiero demostrar

    • Timeout corto y circuit breaker en la llamada al modelo.
    • Si el modelo falla, el evento se guarda igual, sin el campo derivado.
    • Caché por evento, para no pagar dos veces la misma llamada.
    • Salida validada contra un esquema antes de escribir en Redis.

    Go · Redis · API de un LLM