Lab

Personal projects, smaller than the cases, where I try patterns I haven't applied at work yet or want to understand in depth. They are not client work.

  1. In design

    A read model in front of a slow source

    Changes in a slow system are published as events, a consumer materialises them in Redis and the API answers from there. An idea I know from work, taken into an open project where every decision can be reviewed.

    What it should prove

    • Transactional outbox: the data and its event are saved in the same transaction.
    • Idempotency: the same event twice duplicates nothing.
    • A dead-letter queue for events that always fail.
    • Circuit breaker: if the source goes down, the API doesn't go down with it.
    • A script that measures latency before and after, with the numbers in the README.

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

  2. In design

    An AI model as an unreliable dependency

    The second phase of the project above: enriching each event with a field generated by a model, without the pipeline depending on the model answering.

    What it should prove

    • A short timeout and a circuit breaker on the model call.
    • If the model fails, the event is stored anyway, without the derived field.
    • A per-event cache, so the same call is never paid for twice.
    • Output validated against a schema before anything is written to Redis.

    Go · Redis · an LLM API