Engineering / Knowledge hub
Existing architecture notes plus five proposed articles drawn from project decisions and platform engineering questions. Each article starts with a direct answer, then explains the trade-offs and links back to documented project architecture where relevant.
By Savi Saluwadana · Updated
These notes focus on decisions that affect correctness and operability: authority boundaries, tenant isolation, durable workflow state, service structure and developer-platform contracts.
A practical architecture for MCP tools: authenticate at the application boundary, keep authorization in domain services, record state in the system of record, and require approval for consequential actions.
How to design agentic workflows that survive retries and failures: persist state, separate proposals from side effects, make mutations idempotent, and model human approval explicitly.
A practical way to structure a Go SaaS backend as a modular monolith: organize by domain, keep transactions local, separate workers and integrations, and extract services only when operational boundaries justify it.
A platform engineering design principle: automate common delivery paths while keeping ownership, state, observability and escape hatches visible enough for engineers to debug and extend the platform.
A practical approach to PostgreSQL multi-tenancy: resolve tenant context early, scope every domain operation, enforce ownership consistently, and use database isolation as defense in depth rather than the only authorization layer.
Three project decisions and two tool-neutral platform engineering questions.
A project-backed note on routing tool actions through authenticated domain APIs rather than a second access path.
How I separated repeat delivery scheduling from payment capture and what that leaves unfinished.
A look at the Rust API, local data layer and the trade-offs between the web and desktop editions.
A tool-neutral exploration of build inputs, configuration, ownership, health and failure signals.
A tool-neutral exploration of the gap between passing checks and operating a diagnosable deployment.
The articles are based on engineering principles and the documented scope of my project work. They distinguish design guidance from measured production outcomes, link to source repositories when available, and avoid claims that are not supported by the implementation.
For implementation-level summaries, browse the product directory. For cross-project comparisons, use the architecture reference.