Every architecture decision is a bet on what the system will need. I try to make those bets explicit: name the constraint, write down the options, test the risky assumption, and say what would change my mind.
I'm Kaio, a software architect at Bloqit, where I design and build the platform behind its smart lockers. About a decade of hands-on engineering, from early-stage products to systems that have to keep running while the company grows. Current focus: distributed systems reliability, ML foundations, and AI engineering (foundation models, RAG, evaluation).
- Quality attributes (latency, availability, cost) come first and drive the design.
- Significant decisions get a record: options, trade-offs, and the conditions for revisiting them.
- Risky assumptions get a prototype, a load test, or a fault-injection run before they get a roadmap.
- AI-assisted code goes through the same tests and review as any other change.
refactoring: Fowler's 61 refactorings (2nd ed.) implemented step by step, with diffs and tests. Demonstrates safe, incremental change.stability-patterns: Release It! patterns in TypeScript, with load tests and fault injection for circuit breaker and let it crash. Demonstrates failure handling and recovery you can run, not just read about.
test-driven-development: Beck's TDD by Example, one pull request per chapter.refactoring: the full catalog, step by step.design-patterns: all 23 GoF patterns in C#, with diagrams and tests.patterns-of-enterprise-application-architecture: Fowler's PoEAA catalog, in progress.