Behind the Architecture
Deep dives, how-tos, and architectural playbooks for real-world builders
Swazzy is a technical blog written for practitioners
It’s built for the developer navigating platform gaps, the architect balancing roadmap vs. reality, and the consultant whose fix needs to work yesterday.
I’m Alexander D. Mahabir, a Solutions Architect with over 20 years of experience designing systems that hold up under pressure. At AWS, Alfresco, and Ushur, I’ve led modernization projects, built cloud-native platforms, and stabilized multimillion-dollar customer engagements—often by writing the docs, code, or integration that didn’t exist.
This blog documents what I’ve learned in the field. The hows, the whys, and the gotchas.
What is Swazzy?
Swazzy (adj.): Technically sharp. Operationally sound. Built with style and intent.
It describes code that holds up under pressure, docs that make sense on first read, and architecture that doesn’t crumble under real-world constraints.
Swagger, Savvy, Scalable
What You’ll Find Here
Swazzy focuses on practical content with strategic context:
- How-to guides for AWS, Python, serverless, DevOps, and identity integration
- Postmortems on real-world delivery problems (and how we solved them)
- Reusable docs, design templates, and architectural reference patterns
- Delivery frameworks for scoping, escalation management, and partner integrations
- Lightweight code that fills product gaps when engineering is overloaded
Every article aims to save you time—whether you’re building from scratch or debugging a live system.
Why This Exists
Swazzy exists because I enjoy writing things down.
For me, documentation isn’t a chore—it’s part of the build. Whether I’m sketching a system design, explaining a workaround, or simplifying a messy integration, writing is how I make sense of the work.
This blog started as a place to collect notes. Over time, it’s become something more: a logbook of systems I’ve built, problems I’ve solved, and patterns worth reusing. I write here the same way I write for my teams—clear, direct, and with enough context to help someone else pick up the thread.
It’s a hobby. But it’s also how I sharpen my thinking, reflect on what matters, and share what’s worked.
If it helps someone else build faster, avoid a mistake, or just write better docs—that’s a win.
Who This Is For
- Cloud architects designing beyond the diagram
- Engineers asked to solve “just one more thing” outside the product
- Consultants delivering under pressure
- Product-minded technologists who care about how things land
If you’ve ever been told “That’s not supported out of the box” and made it work anyway—you’ll feel at home here.
Swazzy 