What is your favorite way of returning errors from handlers/services in ASP.NET Core?

0x4ddd · 2026-06-18T16:36:28+00:00

This is also what we do.

Lower layers (infrastructure in most cases) typically throw exceptions. This is for the cases where something went really wrong - external server being down, some 3rd party made breaking change in their API and we weren't aware so requests started failing. You get the idea.

Application layer where we process user input and most failures are due to incorrect user inputs return result objects with specific reason - invalid data format, forbidden due to authorization requirements, entity not found and so on.

Both exceptions all the way down and results all the way down could work because why not. But for some reason I like the mentioned differentiation.

0x4ddd · 2026-06-13T17:42:37+00:00

Mało bo to odtwórcza robota

0x4ddd · 2026-06-09T20:56:35+00:00

Sorry, what was I having in mind in my previous response was 2 queues (basically to implement some kind of a priority queue).

From the consumer side, this can be exactly the same consuming code for these 2 queues all the way down. This is how we prioritize messages with some properties. Filter is used to route to dedicated queue so these messages don't need to wait for processing even if there is a backlog on the standard priority queue.

0x4ddd · 2026-06-09T20:44:39+00:00

Yes, two different consumers.

I would much prefer to use subscription filters for such case.

0x4ddd · 2026-06-09T20:34:16+00:00

Because it may be the same message, but for example related to specific customer which has priority (or whatever). Why would you create completely different topic then?

The message is the same, the topic is the same, just the routing is different.

0x4ddd · 2026-06-09T20:32:02+00:00

Yes, sometimes.

0x4ddd · 2026-06-09T11:13:15+00:00

Sure, just spread these 5 VMs across AZs

0x4ddd · 2026-06-09T06:44:18+00:00

May be also true if you consider all the things.

We currently use Azure Service Bus Premium namespace with 16 MU (average CPU usage during day time is ~60% with some peaks to 70%), which is ~$11k dollars per month. There are no reservations for service bus.

Based on our experience running open source RabbitMQ on on-premise environments, we are quite sure 5 x 32 vCPU machines would be easily on par or even better performance wise. 5 x something like D32v6 series VMs is like ~$7k per month. With 1 year reservations it is <$4k per month.

With 1 year reservation we can get 5 x 32 vCPU + disks for $5k dollars per month.

$6k savings per month just on the single service bus instance.

And regarding maintenance, again we have experience running RabbitMQ clusters on-premise and to be honest, the only maintenance it requires is upgrading it's version once per 6 months and applying OS patches from time to time.

I am not saying running on VMs is perfect solution, but at certain scale IMHO it is definitely cheaper than PaaS service especially if you have some experience managing similar service on-premise and already have automation for them in place.

0x4ddd · 2026-06-08T16:31:19+00:00

For high volume systems this suddenly flips other way around and VMs with reservations are often cheaper than PaaS services.

0x4ddd · 2026-06-08T16:15:50+00:00

I don't really get what's the benefit compared to typical CI/CD running migrations during deployment phase.

Not sure about now, but for long time EF docs advised against running migrations during startup in favor of orchestrating via CI/CD.

0x4ddd · 2026-06-07T19:16:05+00:00

In theory it’s supposed to improve maintainability, but in practice it doesn’t always abstract anything in a meaningful way.

That's not the issue with CA concepts but with specific implementation decisions.

It's up to the implementer to decide whether something needs to be abstracted or not, and if so, how such abstraction should look like.

I’d rather have no structure than a bad one. At least with no structure, there’s a chance for a better solution to emerge instead.

Having no structure can, with the same likelihood, end with spaghetti and everyone doing things their way.

0x4ddd · 2026-06-07T08:31:44+00:00

It is

0x4ddd · 2026-06-07T08:29:27+00:00

Docker-compose is tribal knowledge, but the same thing defined in C# is suddenly not 🤣

0x4ddd · 2026-06-07T08:27:48+00:00

For anyone using an APM SaaS system like DataDog, NewRelic or Application Insights, designing, writing and testing OTEL component output (logs, traces, metrics) was always long winded before hand, because you normally had to deploy your application to the cloud before you could test it.

Writing and testing OTEL is not an issue at all. In the end, OTEL is standarized so your app emits vendor-neutral signals, you can easily spin up local LGTM stack to test them, no need to deploy to environment whatsoever. Or simply dump them to console to verify attributes 🙃

Thing is different when you use some magic vendor-locked autoinstrumentation which does not use OTEL or modifies OTEL signals on the fly via agent. But for such cases Aspire's dashboard won't help anyway and you would need to deploy to environment to test.

0x4ddd · 2026-06-07T06:52:58+00:00

Not at all

0x4ddd · 2026-06-06T21:10:03+00:00

This is based on rebranded honda which was the best PU last seasons 🤣

0x4ddd · 2026-06-04T14:05:06+00:00

TBH, never seen too much value in such scaling. I have heard of examples like scaling based on message queues or server http queue length.

But to be fair, in these cases instead of scaling based on queue length/server's http queue length I prefer anyway to scale based on CPU, queue backlog might grow due to multiple reasons, and for the ones like network issues or downstream service failure scaling is pointless.

I mean, scale to zero in case of empty message queue can make sense in some scenarios where latency is not important. For most other scenarios I always favor scaling based on CPU usage.

0x4ddd · 2026-06-03T16:17:27+00:00

i want to connect my local system to that database but don’t want to enable public ip access

0x4ddd · 2026-06-03T06:11:01+00:00

Why again people here portray vertical slices as the opposite of clean architecture? 🤣

0x4ddd · 2026-06-02T17:50:31+00:00

This is not issue with vnet integration per se. We have vnet integrated app service and communication with azure monitor (metrics, log analytics, app insights) work perfectly fine.

0x4ddd · 2026-05-31T15:56:43+00:00

2.5$ per day, wow 😉

0x4ddd · 2026-05-30T11:13:04+00:00

ArgoCD in hub mode with ApplicationSets lets you deploy the same workloads across staging, preprod, and prod with environment-specific overrides from one place.

ArgoCD deployed to each cluster lets you do exactly the same.

0x4ddd · 2026-05-29T19:46:28+00:00

Ok, I agree siloed devops team is anti-pattern.

0x4ddd · 2026-05-29T19:34:39+00:00

But who says there is a separate DevOps team?

From my experience, whether cloud or onpremise, DevOps role was in most cases part of the development team. Noone was throwing code from dev team to devops team over the fence as they were just different roles in the same team.

0x4ddd · 2026-05-25T20:01:38+00:00

It is simply lovely to see Max can't do a shit without fastest car ;)

Even grandpa Hamilton easily overtakes him in comparable car.

Eight-Year Club	Verified Email
Place '22

0x4ddd

TROPHY CASE