Engineering / Open resources
Event-driven systems
From ingestion to operations: queues, load pressure, alerts and recovery.
Selected articles
- In 2026, the model is only one component: the agent architecture I would actually run in production
- Jev, decisions instead of strings: why not every agent step needs an LLM
- MCP in production in 2026: I stopped thinking about tools as functions and started thinking about boundaries
- Enterprise AI without sending data outside: the architecture I am using to turn Excel into evidence
- Why I am learning Python for AI without abandoning TypeScript
- Monitoring e-commerce is not just pinging: how I built PulseWatch and a reliable alert pipeline
- From monolith to Kafka + ClickHouse: how I redesigned analytics for millions of events a day
- A portfolio is not a résumé: how I turned lagrotti.dev into an engineering product
Further resources
When should services use a queue?
Separate traffic spikes from processing capacity without hiding operational cost.
Modular monolith or separate services?
Choose boundaries based on operations and autonomy, with examples from ImpressãoMais3D.
Idempotency
Repeating an operation with the same identity should not duplicate its business effect.
Backpressure
Controlling work admission when consumers cannot keep up with producers.
Multi-tenant
One application serves different organizations while isolating data and permissions.
Dead-letter queue
A destination for messages that exhausted retries, supporting diagnosis and controlled replay.
What happens when arrivals exceed capacity?
Hypothesis: a queue absorbs a burst but does not fix a permanent processing deficit.
Queue, retries and recovery
Adjust arrivals, workers and failures to observe backlog and dead letters. An educational model inspired by the cases, with no production data.