DEV Community: Tummala Krishna Kishore

The one design-review question that would have caught our APIM naming collision

Tummala Krishna Kishore — Sun, 02 Aug 2026 04:49:12 +0000

"Property with the same name already exist." That's the whole error. No stack trace worth reading, no line number, just APIM refusing a PUT and a pipeline stuck red at 2pm.

The instinct was to blame the script. It's always the instinct. Somebody had touched the apiops publisher config two days earlier, so that got the first look, and it was clean. The real cause was quieter and, honestly, more interesting than a script bug: Azure API Management named values carry two separate identifiers, and almost nobody designs around the fact that only one of them is actually enforced.

There's id: whatever apiops derives from the artifact folder name during extraction. And there's name, a display property living inside that resource, which APIM enforces must be unique across the entire service, independent of id. Two axes, one enforced, one not. Somewhere in one environment, a named value already existed with name: key1. It had been created manually through the portal months earlier, sitting under a completely different id than the one our publisher was trying to write. APIM saw the collision on name and rejected the write. From the pipeline's point of view, this looked exactly like corruption. It wasn't corruption. It was two people, at two different times, both being reasonable, and the platform not telling either of them about the other.

I've now seen this shape of bug in three different systems this year, and every time it traces back to the same design-review gap.

The question nobody asks

When a design doc introduces a resource, reviewers reach for the obvious questions. Does it scale? What's the failure mode? Who owns it in prod? Fine questions, all of them, and none of them would have caught this.

The question that would have caught it is smaller and gets skipped almost every time: does this resource have more than one identifier, and if so, which one is actually unique, and at what scope?

Most engineers assume "the ID is unique" and stop there. But plenty of platforms (APIM named values being one, but far from the only one) split identity into a system-assigned key and a human-facing name, and enforce uniqueness on the one you weren't watching. Git branch names inside a protected-branch rule. DNS record names inside a zone. Feature-flag keys versus their internal flag IDs. Environment variable names across shared app-service slots. Same pattern every time: one field is globally unique, the other is scoped or arbitrary, and the design doc almost never says which is which.

That gap survives review because it doesn't fail during review. It fails three weeks later, in a different environment, when someone who's never read the design doc creates something through a portal instead of a pipeline. By then nobody's connecting the failure back to a design decision at all. It just looks like an ops incident.

What actually would have helped

Not more process. A one-line addition to the design doc template: for every resource with a compound identity, state explicitly which field is unique, at what scope, and what happens on collision.

That's it. It's a sentence, sometimes two. But writing that sentence forces the author to actually go check — which means they find out, before shipping, that name is global and id is local, instead of finding out from a failed pipeline run with a cryptic 409.

I'd also push back on the instinct to "fix" this by locking down the portal so nobody can create named values manually again. We talked about it. It's the wrong fix. Manual creation isn't the bug. Undocumented shared-identity scope is. Lock the portal and you've removed one path to the collision while leaving the actual landmine in place for the next person who imports a named value some other way, or renames a folder that changes the derived id. Governance theater instead of a fix.

What we actually did: added an idempotency check to the publisher step. Look up by name before attempting the PUT. If a named value with that name exists under a different id, fail loudly with the actual conflicting id in the error, not APIM's generic message. Twenty minutes of work. It would have turned a 45-minute production debugging session into a five-second, self-explanatory pipeline failure.

Why this belongs in a Node/Python conversation, not just an Azure one

It's tempting to file this under "Azure quirks" and move on. Don't. The exact same failure mode shows up constantly in backend services outside Azure entirely. A Python service that treats a Stripe customer ID and an internal user ID as interchangeable until a webhook arrives out of order. A Node service that keys a cache on a slug that's supposed to be unique but is only enforced unique per-tenant, not globally, until two tenants pick the same slug and one silently overwrites the other's cache entry.

Compound identity is one of the most common shapes a design doc's blind spot takes, across every stack I've worked in. It's not an Azure problem wearing an Azure name. It's a resource-modeling problem that happens to have surfaced there this time.

If you review backend design docs, yours or someone else's, this is worth adding as a fixed line item, not something you trust yourself to remember to ask ad hoc under deadline pressure. "What's unique, and at what scope, for every identifier this resource exposes." One question. It would have saved us a debugging session, and it's cheap enough to ask on every doc, not just the ones that feel risky.

What a .NET Core service needs before it's actually production-ready

Tummala Krishna Kishore — Fri, 31 Jul 2026 04:17:34 +0000

Health checks. Structured logging. Retry policies with jitter. Everyone who writes a "production readiness checklist" for a .NET Core service reaches for the same list, and none of it is wrong. But it's the wrong list to reach for first if your services live inside a shared domain model.

I spent a chunk of this month wiring up something that's not on anyone's checklist: turning our domain projects into versioned NuGet packages, pushing them to a private Artifactory feed, and building a bot whose entire job is bumping the version number and rippling that bump out to every microservice repo that consumes it.

It sounds like plumbing. It is plumbing. But it's the plumbing that decides whether "production-ready" means anything across a fleet of services instead of just one.

Here's the problem it solves. Once you factor shared domain logic — entities, value objects, business rules that more than one service needs — out of a monolith and into a library, you've created a dependency graph you didn't have before. Every consuming service now has an opinion, implicit or not, about which version of that library it's running. Before we packaged it properly, that opinion was enforced by copy-paste and tribal memory. Nobody actually knew which service had which version of which rule.

NuGet fixes the packaging half of that. Artifactory gives you a private feed so the package doesn't leak outside the org and you get an audit trail of who pulled what, when. Neither of those pieces is interesting on its own. The interesting part, and the part that actually determines whether this approach helps you or quietly wrecks you, is the bot.

The bot watches the domain package repo. When a new version ships, it opens a PR against every downstream microservice repo, bumping the reference. That's the whole job. No cleverness, just a scripted dependency bump that used to be a manual chore somebody forgot to do half the time.

And here's where I'll disagree with the take you see in half the "microservices done right" posts: automating that bump is good, but only if you admit you've just built an internal Dependabot, and internal Dependabot needs the same discipline the external kind does — discipline most teams skip because "it's our own code, we'll catch it."

You won't catch it. Not reliably.

If the bot opens the PR and someone rubber-stamps merges on domain package bumps the way they rubber-stamp a patch bump on a logging library, you are one mislabeled semver bump away from a breaking change landing in a dozen-plus services on the same afternoon. A shared domain library isn't a leaf dependency. It's load-bearing. A major-version bump there deserves the same scrutiny as a schema migration, because functionally that's what it is.

So the real production-readiness question isn't "do we have a bot that bumps versions." It's "does every consuming service have a CI gate that runs its own integration suite against the new package version before that PR is mergeable — not after." We didn't have that gate on day one. We had the bot open the PR, a green build meaning "it compiles," and a merge button sitting right there. That's not readiness. That's speed dressed up as readiness.

Getting the gate right meant slowing the bot down on purpose. It still opens the PR immediately, but it no longer auto-merges past a minor version bump until the consuming service's full integration suite passes against the new package — not just its unit tests, the whole suite, including the slow ones nobody likes running. That one change moved the failure mode from silent breakage in production to a red CI check somebody has to look at. Not exciting. Correct.

There's a real trade-off here, and I won't pretend it away: this slows down how fast a domain fix reaches every service. In the old copy-paste world, a bug fix in a shared value object reached whichever service someone remembered to update, whenever they remembered — slow, but nobody's build broke overnight because of it. In the new world, the fix propagates fast to every service wired up to the bot, and any service where the fix collides with a local assumption finds out immediately, in CI, instead of three weeks later in an incident channel.

I'd take the second failure mode every time. Fast and visible beats slow and invisible. But the cost is real, and pretending otherwise is how these systems lose the team's trust the first time a bump breaks a build at 5pm on a Friday.

One more thing worth saying plainly: none of this replaces the usual checklist. A service still needs health checks, a sane retry policy, and logs that actually correlate across a request. What packaging and version-bump automation buys you is a production-readiness checklist that's true across the whole fleet, not just true for the one service you happened to test carefully. A service can pass every item on that list in isolation and still go down the moment a shared library changes underneath it in a way nobody flagged.

If you're building shared .NET domain libraries and haven't worked out who reviews a major version bump, what test suite has to pass before that bump merges, and who's accountable when the bot's PR breaks something two services downstream, you don't have a production-ready fleet. You have a production-ready service, once, and a bot quietly deciding when that stops being true.

Subscription-per-environment was never the real question

Tummala Krishna Kishore — Wed, 29 Jul 2026 02:41:05 +0000

Every landing zone conversation eventually lands on the same fork: subscription-per-team or subscription-per-environment. Pick one, defend it in the design review, move on. I used to think that fork was the decision. It isn't. It's a proxy for a question nobody actually asks, which is whether your environments are things you have or things you make.

We hit this a few weeks back building out a branching strategy for a product that needed to ship in phases — not one big release, several overlapping ones, each needing its own slice of infrastructure to validate against before merging up the chain. The instinct in every Azure reference architecture I'd read was to stand up a fixed set of subscriptions — dev, qa, uat, prod — and let teams queue for access to the shared ones. Clean org chart. Terrible fit for what we were actually doing, which was running three or four release branches at once, each wanting its own isolated environment for a week or two and then wanting to disappear.

So, we didn't fix the environments. We templated them.

The branching strategy and the environment strategy ended up being the same decision, which surprised me at the time. Every release branch got a corresponding environment spun up from Terraform, wired into the pipeline automatically the moment the branch existed, torn down automatically once it merged or went stale. No ticket. No "can I borrow QA for the afternoon." The subscription-per-environment debate assumes environments are scarce and long-lived enough to be worth governing carefully as static things. Once provisioning is cheap and repeatable, that assumption just stops holding.

Here's the number that made the case for me, not some theoretical justification. Before this, we were running four non-prod subscriptions, always on, mostly idle outside business hours, because nobody wanted to be the one who tore down an environment someone might still need. After moving to on-demand provisioning tied to branch lifecycle, we typically had one to two environments alive at any given moment instead of four sitting there permanently. That's not a rounding error. That's roughly half the standing footprint gone, for infrastructure that was doing the same job.

I won't pretend this is free. Ephemeral environments push a lot of discipline requirements onto your IaC that a static model lets you get lazy about. If your Terraform templates aren't actually idempotent — if there's some manual step, some hand-configured firewall rule, some secret someone pasted in once and forgot to script — dynamic provisioning will find that gap for you, repeatedly, at the worst time. We found ours in a Key Vault access policy that had been set by hand eight months earlier and never made it into the template. First time a fresh environment failed a smoke test, it took an afternoon to figure out why "prod-like" environment #3 didn't behave like the original.

There's also a real counterpoint here, and it's not a strawman: audit and compliance people like fixed environments. A subscription that's existed for two years with a known history is easier to reason about for a SOC 2 review than one that spins up Tuesday and dies Friday. If your organization's compliance posture depends on long-lived resource identity — not just "the config was correct" but "this specific resource has been continuously monitored since provisioning" — ephemeral environments genuinely complicate your story. That's a real cost. I'm not going to hand-wave it away with better logging. You need to decide whether your compliance framework cares about resource continuity or just about proving the right controls were in place at time of use and design your audit trail around whichever one it actually is.

For us, it wasn't. The controls mattered, the specific subscription's birthdate didn't. So, the trade-off was worth making.

What I'd push back on is treating subscription-per-team vs subscription-per-environment as the primary architectural decision in the first place. It's a structural question about naming and boundaries. The actual lever — the one that changes your cost profile, your pipeline design, and how fast a team can validate a branch before it merges — is whether "environment" means a durable thing you provision once and then manage, or a disposable output of your pipeline that happens every time you need it. Landing zone docs spend pages on the former and barely mention the latter, probably because it's harder to draw on a slide. A static subscription topology is easy to diagram. "Environments are ephemeral outputs of the release pipeline" doesn't fit neatly into an org chart, so it gets left out of the reference architecture even when it's the more honest answer for a fast-phased release model.

If you're mid-debate on subscription topology right now, my actual advice is to shelve that question for a week and instead ask whether your team could provision a working non-prod environment from scratch, unattended, in under half an hour. If the answer is no, fix that first — the subscription boundary question becomes almost irrelevant once you can. If the answer is yes, you've probably already made the topology decision without realizing it, because ephemeral environments don't care much which subscription boundary they sit inside. They just need somewhere to land and a template that doesn't lie about what production actually looks like.

Cherry-picking your hotfix twice is the real pipeline smell

Tummala Krishna Kishore — Mon, 27 Jul 2026 03:20:58 +0000

We had a gitflow pipeline that looked clean on paper: develop feeds a release branch, the same build artifact promotes through dev, qa, sit, uat, and prod, and once prod is green we tag the commit on main. Textbook. Then a production bug showed up on a Tuesday afternoon, and the diagram stopped mattering.

The standard gitflow answer is to branch a hotfix off the tag, PR it back into release, run it through the pipeline, and once it's proven in UAT, merge to main and cherry-pick the same commit back into develop. We built exactly that. It works. Until you ask the question nobody wants to answer out loud: release still has whatever was mid-flight when you cut the last tag. Untested code. Feature work three sprints deep in QA, sitting on the same branch you're now supposed to route your hotfix through.

So the real question we ended up arguing about wasn't "how do we release a hotfix." It was "do we trust the release branch enough to put a hotfix through it." Most of the time, the honest answer is no.

The gate everyone obsesses over is the wrong one

Five environments, five sign-offs, a change ticket for each one: that's the smell people point at first when a pipeline feels slow. It's real. It's just not the dangerous one. A slow gate costs you time. A gate you route around because you didn't trust your own process costs you an incident.

Here's what we landed on after the argument: release the hotfix directly from the hotfix branch, not through release. On Azure, that means deploying to the UAT slot, smoke-testing against production data shape, then toggling the slot. Same infrastructure, same config, none of release's baggage riding along. Once it's live, cherry-pick the commit into both develop and main, retag, and let the normal pipeline catch up on its own schedule whenever it gets there.

That's a smaller number of gates (one real test in the slot, one human sign-off) that actually mean something, instead of five theatrical ones inherited from a process built for planned releases, not for a Tuesday-afternoon incident.

Cherry-picking backward is the part that actually breaks

Cherry-picking isn't free. It's a manual merge decision, done twice, under time pressure, by whoever's on call. Miss a file, resolve a conflict wrong, and you've silently reintroduced the bug three weeks later when release finally catches up to main. We've had this happen. Not often. Twice in about eighteen months. Both times the root cause was identical: the hotfix touched a file that had also changed on develop, and the person doing the cherry-pick trusted the diff instead of running the test suite against the merged result.

The fix wasn't "be more careful." Telling people to be careful under incident pressure doesn't work. The fix was making the cherry-pick a PR like any other, gated by the same CI as a normal merge, instead of a git command someone runs from their laptop at 6pm. One automated check catches what a tired engineer won't.

The trade-off nobody states plainly

Deploying straight from a hotfix branch means shipping less-tested code than your normal pipeline would allow. That's the actual cost, and it's worth saying plainly instead of dressing it up. If your org's risk appetite says every production deploy needs the full five-stage gauntlet, this approach is wrong for you. Don't adopt it because it sounds efficient. Adopt it because you've decided the trade-off is acceptable for a defined, narrow class of change.

But when the choice is "wait six hours for a full pipeline run while the bug keeps costing money" versus "deploy a scoped, reviewed, slot-tested fix in twenty minutes," speed usually wins the math. We're not skipping testing. We're skipping the parts of testing that exist to catch problems unrelated to the fix: the ones baked into whatever else happens to be sitting on release that particular week.

What I'd tell a team setting this up today

Don't design your hotfix path as a stripped-down version of your normal release path. Design it as its own thing: its own artifact, its own single meaningful gate, its own explicit rule for re-entering the trunk.

Ours is three rules. Hotfix branches from the last production tag, never from release. It deploys through slot swap, never through the shared release pipeline. It re-enters develop and main through a real PR with CI attached, not a raw cherry-pick run from someone's terminal.

Three rules. They fit on a sticky note. The gitflow diagram we started with had no room for any of them, because it assumed every deploy was a planned one, and incidents don't wait for the plan to catch up.

If your next incident retro says "we need more approval gates," check first whether the actual failure was a rushed cherry-pick nobody tested. In our case, it always was — and no amount of extra sign-off in the normal pipeline would have caught it, because the bug never went through the normal pipeline at all.

What actually belongs in an architecture decision record (and what doesn't)

Tummala Krishna Kishore — Sat, 25 Jul 2026 06:35:30 +0000

Most architecture decision records fail for the opposite reason people think. The issue usually isn't that teams forget to write them. It's that the ones they write are filled with the wrong content. The key information a reader needs—why this option instead of the others—often gets buried on page three under a list of API changes.

An ADR has one job: capture a decision that is costly to reverse, along with the reasoning that led to it, while that reasoning is still fresh. That's all. It isn't a design document, a specification, or a collection of research. If you keep that focus, everything else about what to include or leave out will follow naturally.

The format that still works
Michael Nygard's original ADR template from 2011 (title, status, context, decision, consequences) has lasted for a reason. It directly addresses the key questions a future reader has: What was the situation? What did we decide? What did we give up? Teams that add ten extra sections, like owners, review dates, risk matrices, or approval lists, usually end up with a document no one finishes reading, which defeats the purpose. If your ADR template is longer than the time it takes to fill it out for a simple decision, cut sections until it’s more concise.

A useful rule of thumb is that an ADR longer than a page and a half is often a design document masquerading as an ADR. This isn’t a strict rule, but I haven’t seen a truly good ADR exceed 600 words. The decisions worth documenting this way can be stated, justified, and owned in about a page. If that's not possible, the record isn’t the issue. The decision is probably still tied up with other unresolved matters.

What belongs
The decision, stated clearly. "We will use event-driven integration between the order and inventory services instead of synchronous REST calls" is a decision. "The order service integrates with inventory" simply describes the current state and belongs in a wiki, not an ADR.

The challenges faced. Describe the two or three actual constraints that were in conflict, not a comprehensive literature review. For example, a latency budget versus consistency guarantees, team ownership boundaries versus a shared database that made those ownership lines unclear, or cost limits versus the vendor lock-in that comes with a cheaper option. If there was no real conflict, you probably didn't need an ADR.

The alternatives you seriously considered, along with why they weren’t chosen. Focus on the options a competent engineer would likely ask about six months later. For example, "We looked at a shared database with row-level locking; we rejected it because it recreated the coupling we wanted to eliminate between the two teams' deployment cycles." This simple statement saves the next person from rehashing a decision that's already been made.

The consequences, including the ones you’re not thrilled about. This is often the section teams skip, but it offers the highest value. Every genuine architectural decision comes with costs. If you adopt event-driven integration, you trade the simplicity of synchronous actions for eventual consistency and a tougher debugging process when a message is lost. Document that. An ADR that lists only the benefits isn't a valid record of a decision. It's a sales pitch to your future self, and future-you won’t be fooled more than once.

What doesn’t belong
Implementation details. Class names, endpoint paths, table schemas, retry counts—these change frequently and can quickly make the document outdated. If the ADR needs a code example to clarify its point, it likely indicates that the decision being documented is more about implementation than architecture, and it should belong in the code or design document instead.

Decisions that are not settled yet. If three options are still in play and no one has chosen one, that's a design document or a spike ticket. Writing an ADR for a decision still in progress creates a record that contradicts itself by the time it gets approved. Contradictory records are worse than having no records; they mislead the following reader.

A decision made after the fact to meet process requirements. This rubber-stamp scenario is more common than teams want to admit. Someone builds the solution and then creates the ADR retroactively because it's required by the checklist. The "alternatives considered" section becomes fictional, as nothing was actually considered. The option that got released is the only one that ever existed on paper. Readers can tell the difference. An ADR written after the code is merged feels different from one written beforehand. Once a team’s ADRs acquire a reputation for being just for show, people stop reading them, which is worse than never having them required.

Every decision, regardless of its importance. This is the trade-off people often avoid stating clearly: requiring an ADR for every non-trivial pull request leads to a pile of records. For example, both the choice to follow field-naming conventions and the decision to go fully async receive the same template and attention. The signal-to-noise ratio diminishes, and the truly important records—those concerning team boundaries, data ownership, or long-term platform choices—get lost among many similar entries about logging formats. Save ADRs for decisions that are genuinely challenging to reverse: those that affect team boundaries, data ownership, or a platform choice you'll live with for years. Smaller considerations can go in a pull request description or a design note.

The crucial test
Before you write the next one, ask yourself: if this decision turns out to be wrong in eighteen months, would the person troubleshooting it appreciate this document? If the answer is that they would skim through the generic content looking for the paragraph explaining why the obvious choice wasn’t made, write that paragraph first and build the rest of the record around it. Everything else, like the status field, review date, and approval chain, is optional. The reasoning is the key part; treat it that way, and the format will fall into place.

Open In-line video in fullscreen

Tummala Krishna Kishore — Tue, 01 Feb 2022 05:55:24 +0000

Its been a long time i have written my posts, so got some free time to publish some articles which are usefull for the people who are implementing In-line video and make it fullscreen in Ionic.

In the Config.xml we need to Add this Block of code to Make it full screen

<preference name="AllowInlineMediaPlayback" value="true" />

Which Triggers the Native app to play in Inline. while coming to the HTML5 there is a intresting fact that was stated in Apple Developer Site

on iPhone and iPod touch, which are small screen devices, Video is NOT presented within the Web Page

Publish from Visual Studio and automatically encrypt appSettings using aspnet_regiis

Tummala Krishna Kishore — Tue, 17 Aug 2021 06:04:18 +0000

After going through your all edits and a bit of research from me , you want to execute the following command after the publish from the Visual Studio

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -pe "appSettings" -site Default -app "/"

If I understood right , You can try wrapping the ItemGroup in a Target with AfterTargets set to AddIisSettingAndFileContentsToSourceManifest

<Target Name="executeinHosts" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
    <ItemGroup>
      <MsDeploySourceManifest Include="runCommand">
       //here would be your path that need to run after the publish
      </MsDeploySourceManifest>
    </ItemGroup>
  </Target>

So in Your case this is how that part should look:

<Target Name="executeinHosts" AfterTargets="AddIisSettingAndFileContentsToSourceManifest">
    <ItemGroup>
      <MsDeploySourceManifest Include="runCommand">
         <path>C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -pe "appSettings" -site $(DeployIisAppPath) -app "/"</path>
      </MsDeploySourceManifest>
    </ItemGroup>
  </Target>

Additional Info:

AddIisSettingAndFileContentsToSourceManifest target works just right before Web Deploy copying files from local to server.
aspnet_regiis can be run in node by .

Example:

<Exec Command="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef connectionStrings $(ProjectDir)obj\Debug\Package\PackageTmp" WorkingDirectory="$(publishUrl)" />

Display datetime correctly in iOS/Safari using ionic2/angular2

Tummala Krishna Kishore — Tue, 06 Jul 2021 07:58:39 +0000

The issue is caused by the Intlapi because DatePipe for Angular 2. Release is working fine only for FireFox and Chrome with custom format strings. it Doesn’t work on Safari due to lack of Intl. so as a temporary work around is to include the Intl polyfill

<script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Intl.~locale.en"></script>

Solution 2 You can use the moment.js which can format your required date as follows

moment(singleTable[0].FromCurrentDate).format("dd/MM/yyyy,h:mm:ss a")

Pass multiple Eval field in one command argument in Repeater Control

Tummala Krishna Kishore — Thu, 01 Jul 2021 10:11:47 +0000

This is the most common problem that generally users face while dealing with Repeater control. I gave this solution in Stackoverflow. want to post it here for users coming from search

Add the below snippet in in template

CommandArgument='<%#Eval("ScrapId")+","+ Eval("UserId")%>'

In code behind you can use retrieve values like this

protected void GridViews_RowCommand(object sender, GridViewCommandEventArgs e)
{
    if (e.CommandName == "Comment")
    {
        string[] commandArgs = e.CommandArgument.ToString().Split(new char[] { ',' });
        string scrapid = commandArgs[0];
        string uid = commandArgs[1];
    }
}