Mukesh Murugan

Mukesh MuruganSep 15, 2026

Pick microservices too early and you'll spend a year fighting your own setup instead of shipping. Architecture is a tradeoff, not a trophy. Here is how I decide for a new .NET project. Monolith. One deployable app, all the code in one place. This is where you start. CRUD apps, internal tools, anything small or early. You get one codebase to build, one thing to deploy, and you ship fast. The "downside" people warn about only shows up at real scale, and most apps never get there. Modular Monolith. Still one deployable app, but the code is split into clear modules behind an API or facade. Each module owns its own logic and its own slice of the database, and they talk through a shared kernel and common libraries. You get clean boundaries without the pain of running ten services. This is my default for almost everything serious. It keeps the team organized and leaves the door open if you ever need to split a module out later. Microservices. Separate services, each with its own database, talking over a gateway and a message broker, with their own monitoring and tracing. This solves one real problem: parts of your system need to scale and deploy independently. That is it. If you don't have that problem yet, you are buying network calls, distributed bugs, and a heavy ops bill for nothing. The honest rule: start with a modular monolith, draw your module boundaries well, and only split into services when one module truly needs to scale on its own. If your last project went to microservices, what was the actual problem that pushed you there?

Mukesh MuruganSep 18, 2026

I put every .NET interview question I've written in one place. 300+ questions. All free. No signup. Quick check before you scroll: Why does the order of middleware matter? What goes wrong when you call ToList too early? If you had to stop and think, this list is for you. .NET interview questions - the full guide ↳ https://lnkd.in/eQqJnsMb Free mock interview - pick your level, see where you're weak ↳ https://lnkd.in/eZQz7ppg Web API - 45 questions ↳ https://lnkd.in/gsnggNbS ASP .NET Core - 30 questions ↳ https://lnkd.in/eEyJyhU8 EF Core - 30 questions ↳ https://lnkd.in/eUWMkhAM LINQ - 30 questions ↳ https://lnkd.in/eu7nu2bU Microservices - 30 questions ↳ https://lnkd.in/eyTaw6dW Senior .NET - 35 questions ↳ https://lnkd.in/eyV_cgu6 Take the mock interview first. Then read only the topics you got wrong. Save this for your next interview and share it with your network. All the best for your next job!

Mukesh MuruganSep 14, 2026

A database password sitting in one variable can end up in git history forever. Seven of the common ones are in the image. Here are the four I see hurt people the most. Storing secrets in code. An API key or a database password sitting in a variable feels harmless while you build. The problem is it ends up in git history forever, and anyone with repo access (or a leaked repo) now has your production keys. Keep secrets out of source. User secrets in development, a vault or environment variables in production. No input validation. If you trust whatever the user sends, you let bad data straight into your logic and your database. An age field that accepts -999, an email field that accepts a SQL statement. Validate every input on the server. Never assume the client checked it for you, because an attacker skips your UI entirely. SQL injection. This is what happens when you build a query by gluing strings together with user input. Someone types a value that closes your query and adds their own, and now they can read or delete your tables. The fix is simple: use parameters, or let EF Core build the query for you. Never concatenate user input into raw SQL. Exposing stack traces. A full error page with file paths and exception details is a gift to an attacker. It tells them your structure, your libraries, your weak spots. Show a clean error message to users. Log the real details somewhere only you can see. The other three in the image (weak password hashing, missing HTTPS, and over-permissive CORS) are just as worth fixing. Save this and run it down the next time a code review touches anything that handles user input.