Radhakrishnan Perumal

  Using Claude Code Efficiently An Architect’s Guide to AI-Assisted Software Development AI coding tools are changing software development, but there is an important distinction: Using an AI coding tool is easy. Using it efficiently on a real production codebase is an engineering discipline. Claude Code is more than a place to type: Create an API for me. It is an agentic coding environment capable of reading a codebase, modifying files, executing commands, exploring dependencies, and integrating with development tools. That creates enormous productivity potential—but it also creates a new architectural challenge: How do we give an AI enough freedom to accelerate development without giving it so much freedom that it creates unnecessary code, architectural drift, security problems, or expensive rework? After working with AI-assisted development workflows, I have found that the most effective approach looks less like: Prompt → Code and more like: Understand ↓ Plan ↓ Constrain ...

  Azure Cosmos DB Partition Keys Explained A Practical Guide for Architects and Developers When developers first start using Azure Cosmos DB, the term partition key often sounds like just another database configuration. It is not. In Azure Cosmos DB, the partition key is one of the most important architectural decisions you will make. It directly influences: Scalability Query performance Request Unit (RU) consumption Data distribution Transaction boundaries Hot partitions Storage limits Cost Future growth A poorly chosen partition key may work perfectly when your application has 10,000 records and then become a serious performance problem when it grows to hundreds of millions of records. The easiest way to understand partitioning is to think about one simple question: Where should Cosmos DB place this piece of data, and how can it find it efficiently later? That is essentially what the partition key helps Cosmos DB decide. 1. Why Does Cosmos DB Need Partitioning? Imagine an e-comm...

  Clean Architecture in .NET: It's Not Just About Folder Structure One common misconception about Clean Architecture is that it simply means creating folders like: 📁 Domain 📁 Application 📁 Infrastructure 📁 API But Clean Architecture is much more than organizing files. The real objective is to protect business logic from technical dependencies. A typical .NET enterprise application can be structured around: 🔹 Domain Business entities, rules, and core business logic. 🔹 Application Use cases, interfaces, commands, queries, and application workflows. 🔹 Infrastructure Database, external APIs, messaging, storage, and other technical implementations. 🔹 API / Presentation HTTP endpoints, authentication, validation, and communication with clients. The key principle: Dependencies should point inward. Your business logic should not depend directly on: ❌ SQL Server ❌ Entity Framework ❌ Azure ❌ REST APIs ❌ Messaging infrastructure Instead, the core application defines abstractions, whil...