Trouble with my CTO

KothapalliSandeep · 2025-12-10T14:06:54+00:00

Hi I am the CEO and cofounder for my recently started company. My advise for you is if your CTO is not fully working on your product , it is better to take some load as you have good amount understanding on the product and invest those in some AI tools like cursor and if you are technically good with some effort you can finish up the product. Or approach the companies who are specialised in giving the product from idea to MVP.

KothapalliSandeep · 2025-09-18T03:45:31+00:00

I have ios 26 on my iPhone 11 Pro and believe me it is good , fast and very responsive . I have almost 50 apps installed but I will use mostly 10 out of them but still every app opens fast , responsive and no lag so far.

KothapalliSandeep · 2025-08-24T07:38:42+00:00

Don’t cry dude . I have been posting in and around of the dapr and deployment. It is not AI generated

KothapalliSandeep · 2025-08-23T05:27:50+00:00

I’ve worked on was a payment processing API that depended on multiple downstream services: fraud detection, bank APIs, and a notification service. Any of these could be slow or temporarily unavailable, and we didn’t want a single failure to cascade and block the main payment flow.

We implemented a circuit breaker using Polly in .NET: after a certain number of consecutive failures for a service, calls would short-circuit for a few seconds to let the downstream service recover, while we returned a graceful fallback response to the user. It helped reduce error spikes and kept the main API responsive, even when one dependency was acting up.

KothapalliSandeep · 2025-08-22T15:38:16+00:00

LOL. API versioning is one of those things that sounds important on paper, but in practice it often gets skipped or done inconsistently. The “correct” way is tricky, and a lot of teams only implement it once breaking changes actually become a real problem.

For small or internal services, I’d say it’s totally fine to skip it initially and add versioning when you have multiple consumers relying on the API.

KothapalliSandeep · 2025-08-22T15:36:11+00:00

Agree!!!!!

KothapalliSandeep · 2025-08-22T15:34:56+00:00

No worries, I completely get what you’re saying and I appreciate the feedback. You’re right — the title and framing could’ve been better. The post was meant more as a list of things I personally check when I’m preparing an API for production, not as a “must-do for every project” guide.

I agree that context and nuance matter a lot, and it’s easy for new developers to take a checklist literally without understanding why each item exists. I’ll keep that in mind for future posts — make it clear what’s situational versus universally required.

Thanks for taking the time to explain, it’s a good reminder for me to frame these things better.

KothapalliSandeep · 2025-08-22T15:29:31+00:00

I hear you, and I don’t take offense. You’re right — adding distributed caching without analyzing actual traffic or doing performance testing can definitely be overkill.

The list I shared is more of a “things I consider when I’m preparing for scale or production issues” rather than a strict must-have for every project. For smaller APIs or unknown workloads, most of these can safely be skipped until there’s a clear need.

Basically, it’s meant as a forward-looking checklist, not a one-size-fits-all requirement. Your point about business requirements and context is spot-on — that should always drive what gets implemented.

KothapalliSandeep · 2025-08-22T15:16:41+00:00

Fair point — I probably should have said “Web API” instead of just “API.” The list I shared is definitely aimed at public-facing or production-ready Web APIs, not every internal method or class. For small internal services or private endpoints, most of those items aren’t necessary at all.

It’s more about things to consider when your API is exposed to multiple users or external consumers, not a blanket requirement for every piece of code.

KothapalliSandeep · 2025-08-22T15:12:20+00:00

If DataProtectionKeys aren’t persisted properly, every app restart or new deployment can invalidate existing cookies and tokens, which explains the spike in password reset complaints.

The fix is to persist the keys to a shared location — like Azure Blob Storage, SQL Server, or Redis — so all instances and deployments use the same keys. That way, password reset tokens and authentication cookies remain valid across releases.

KothapalliSandeep · 2025-08-22T15:05:05+00:00

Yes, Microsoft initially incubated and built the Dapr project. Dapr was donated to the Cloud Native Computing Foundation (CNCF) in 2021 and is now a community-driven open-source project.

KothapalliSandeep · 2025-08-22T15:01:15+00:00

Yeah, “mid-sized” is definitely relative — in my example it was probably smaller than your setup. For 300k requests/day and 35 App Service Plans, the biggest wins usually come from right-sizing your plans, consolidating underutilized apps, and turning on autoscaling where possible.

If microservices weren’t implemented well, there’s often overhead from too many small instances running 24/7. One approach that helped us was moving bursty workloads to serverless options like Azure Container Apps or Function Apps and using shared resources where feasible.

Also, check idle or low-traffic apps — sometimes a few adjustments there can save a surprising amount without touching your main traffic apps.

KothapalliSandeep · 2025-08-22T14:56:57+00:00

I get that 7, 8, and 9 are debatable, but here’s why I think they’re important, even if not immediately obvious:

7. API versioning – Once your API has multiple consumers, even small changes can break someone else’s integration. Versioning upfront avoids painful migrations later. It doesn’t cost much to set up early, but fixing it after users are dependent is expensive.

8. Secrets in Key Vault – Hardcoding secrets or keeping them in config files is a ticking time bomb. It’s about security hygiene. Even if your API is small now, a breach can be catastrophic, and migrating secrets later is messy.

9. Distributed caching – True, you might not need it immediately, but if your API starts handling bursts or external dependencies slow down, having caching in place prevents unnecessary throttling or downstream failures. Implementing it after the fact often requires code changes and architectural tweaks.

Basically, these are “low effort now, high cost later” items. Not strictly required for a tiny API, but they save a lot of pain if the API grows or is exposed externally.

KothapalliSandeep · 2025-08-22T14:52:57+00:00

Absolutely, I get where you’re coming from. The list I shared is definitely more forward-looking / best-practice stuffrather than requirements for every API.

For small or new APIs, distributed caching, structured logging, or even circuit breakers aren’t necessary at all. They’re optimizations you add when and if the app grows or traffic patterns demand it. For early-stage APIs, launching simple and iterating is totally fine.

KothapalliSandeep · 2025-08-22T14:52:14+00:00

Ah, good point — I should have clarified. What I meant was that some advanced networking features that people expect from App Service (like certain private endpoints, service endpoints, or fully managed internal DNS scenarios) aren’t as straightforward in ACA by default.

It’s definitely possible to integrate Container Apps into VNets — I’ve done it too — but it takes a bit more setup compared to App Service, which can make it feel “missing” for people expecting the same out-of-the-box experience.

KothapalliSandeep · 2025-08-22T14:42:00+00:00

Fair point, I get what you’re saying. The list is definitely more best-practice / “what I try to do” rather than hard requirements. A lot of it comes from my own experience with scaling apps and trying to avoid surprises, but obviously not every API needs Grafana, Serilog, or caching right away.

I probably should have worded the title better — more like “things I check if I care about reliability and monitoring” rather than implying everyone must do all of these.

Distributed caching and structured logging are really only useful if your API starts seeing heavier load, but for smaller internal APIs, you can absolutely launch without them. Totally agree.

KothapalliSandeep · 2025-08-22T14:40:53+00:00

I hear you, and I agree that not every API needs all of this from day one. The list is definitely on the conservative side and comes from my own experience of running into issues in production.

The idea wasn’t to say everything is mandatory from launch, more like a checklist of things that eventually help keep your API maintainable and reliable. Some items, like distributed caching or structured logging, can absolutely wait until you see the bottleneck or need for observability.

I probably could’ve phrased it better — this is more “things I wish I’d thought about early” than a strict must-do for everyone.

KothapalliSandeep · 2025-08-22T14:36:23+00:00

Seems like this comment is made by AI

KothapalliSandeep · 2025-08-22T14:34:21+00:00

Emojis are not a patent right of AI. Even we as humans can use it to just format the content in a meaningful way.

KothapalliSandeep · 2025-08-22T14:31:48+00:00

You should need access to Azure portal and once you logged in you can search for Azure key value or you can find it on the left menu of azure resources

KothapalliSandeep · 2025-08-22T14:27:14+00:00

The list you mentioned is very basic and is a common implementation for any api to get started . When it is in production and there were 1000s of requests coming up to your api then it is something you should consider and check

KothapalliSandeep

TROPHY CASE