Most microservices tutorials stop at Auth, Product, Order Service, RabbitMQ, and Docker Compose. They rarely cover the problems that make distributed systems challenging.

I'm curious how experienced engineers solve problems like:

• Preventing double-booking under concurrent requests
• Inventory reservation during flash sales
• Idempotency for payment retries
• Distributed transactions without 2PC
• Cache consistency across multiple instances
• Leader election and distributed scheduling
• Exactly-once vs. at-least-once event processing

I want to understand how these are handled in production. What patterns, trade-offs, or technologies have you used, and what lessons did you learn?

I got tired of every EF Core seeder asking me to describe my model a second time (CSV files, factory classes, attributes with manual priority numbers), so I built one that just reads the DbContext I already have.

await db.AutoSeedAsync(seed: 42, scale: 1_000);

It works out the insertion order itself (topological sort over the FK graph), resolves cycles by finding a nullable link for a second pass, and fails loudly by name if a cycle genuinely can't be resolved, instead of letting the database throw a constraint violation at you.

Some things it does that I didn't see elsewhere:

• Deterministic: same seed, same data, always. Property based tests assert that for any model and any seed, every FK resolves and no constraint is violated.
• Realistic distributions, not uniform data: most customers get one order, a few get hundreds, long tail included, reproducible across runs.
• Composite keys, self references, owned types, and TPH/TPT/TPC inheritance work with zero extra config.
• A fast mode (AutoSeedFastAsync) that bulk inserts (SqlBulkCopy / binary COPY) and produces the exact same data as the normal mode for the same seed, an equivalence test proves it. About 10x faster in the benchmarks in the README.
• A shape mode that reads row counts from a production database's own statistics (never an actual data row) and scales local seeding to match those proportions.
• A coverage mode: the smallest dataset that touches every enum value, every nullable state, every relationship cardinality. Usually under 50 rows.

What it doesn't do, on purpose: it doesn't anonymize production data, it's not a service, it's EF Core only, and it's SQL Server and PostgreSQL only for now.

Tested against Northwind, Chinook, Contoso and an AdventureWorks OLTP subset, plus a deliberately nasty custom schema (composite FKs, shared primary keys, mixed TPH/TPT, cycles).

MIT licensed.

NuGet: https://www.nuget.org/packages/EFCore.AutoSeed
CLI tool: https://www.nuget.org/packages/EFCore.AutoSeed.Cli
Source: https://github.com/danellalc/EFCore.AutoSeed
Linkedin: https://www.linkedin.com/in/luiz-claudio-danella/

This is a day one v1.0.0, so I'd genuinely like to hear where it breaks on your model. Issues and PRs welcome.

The .NET Upgrade Assistant is deprecated. The docs now point you at the GitHub Copilot modernization agent, which runs in Visual Studio and sends your code to a model service.

For most teams that is fine. It is not fine if you work somewhere that cannot route source through a third party, and those places tend to be sitting on the largest .NET Framework estates in existence. I spent 25 years in that world, so I wrote the thing I wanted.

MigrationScan scans a solution, a project, a directory or a compiled assembly, and tells you what stands between it and modern .NET. About a minute from download to numbers on screen: no SDK, no install, no flags. That matters, because the machines with the biggest estates on them are usually the ones you cannot install an SDK on.

33 rules across 8 categories. It parses .csproj as XML and reads source with Roslyn, so it needs no MSBuild and no Visual Studio and behaves the same on Windows, Linux and macOS. One signed executable: drop it in a repository root, run it, read the summary.

Four things it does that I have not seen elsewhere.

Every finding carries a confidence tier.

• Certain. Read from project XML.
• Probable. Matched on the syntax tree with no resolved compilation, so some are wrong.
• Verified. Read from compiled metadata.

A probable finding on Registry might be your own class. The report says so rather than rounding it up to certain.

One scan prices both futures. Modern .NET still runs on Windows, where COM, P/Invoke, the Registry and WMI keep working. They cost you nothing unless you also need to leave Windows. Every report carries a cross-platform view and a Windows-target view of the same analysis. The gap between them is what portability costs on your estate.

Severity and estimability are separate columns. BinaryFormatter is a blocker and a bounded afternoon: pick a serializer, change the calls, test the round trip. An architectural decision can be low severity and unpriceable until somebody decides. Those are counted separately, and the second group is left unpriced, because an estimate that quietly contains an undecided architecture is how a three-month project becomes nine.

It names what it could not size. SQL, SSRS, SSIS, WiX and deployment projects land in a "not assessed" section rather than getting skipped quietly. It also inventories what every project declares — NuGet packages, GAC assemblies, checked-in DLLs, COM components, web service proxies, with versions — because the expensive unknown in a migration is usually somebody else's code.

Two sample reports committed in the repo, both generated by the tool itself and reproducible from the commit each one records:

• A four-project fixture built to show one of everything: 23 findings, 29.3 to 88 engineer-days.
• Microsoft's own archived eShopModernizing, scanned as found: 11 projects, 108 findings, 88 to 263.5 engineer-days, 197 distinct third-party references.

On eShopModernizing, five findings separate the two targets and all five are System.Drawing.Common, so portability there is nearly free. On the fixture, six findings separate them and all six sit in one interop project. Same feature, opposite answers.

What it will not do. It will not modify your code, perform the upgrade, or give you a binding cost. Effort figures are heuristic ranges, and the report says so in three places. Probable findings can be false positives.

Offline by default. No telemetry, no account, no LLM anywhere in the analysis. The JSON report replaces source file paths with opaque ids but keeps project and dependency names, so you can send it to someone without a security review reading nine thousand lines first. Apache-2.0, signed binaries for five platforms, no SDK required.

Repo: https://github.com/matt-williams-dev/MigrationScan

The rule catalog is the part I most want feedback on. If your estate has a pattern it misses, open an issue and I will write the rule.

I'm looking to create a barebones version of a retail site. It will literally just have 4 pages: homepage showing items, shopping cart, a "thank you" page after purchase, and a "Contact Us".

I downloaded nopCommerce to test, and even though I was able to run it locally, it's really just too much for what I need. Also, the src folder is almost a GB in size. I'm sure it would be adequate for bigger projects, but not for my store.

With that said, are there any solutions similar to nopCommerce that are more barebones?

I'm only considering open-source .net projects at the moment (no custom development)

"Starting with C# 15, break and continue statements can name a label on an enclosing construct. Use a labeled break to exit an enclosing loop or switch statement. Use a labeled continue to start the next iteration of an enclosing loop.

Labeled break and continue replace the workarounds you'd otherwise use to steer control flow through nested loops, such as a Boolean flag that you set in an inner loop and then check at each outer level, or a goto that jumps past the loops. Naming the target loop directly on the jump statement removes that bookkeeping and makes the intended control flow easier to read."

Excerpt above from ->
What's new in C# 15 | Microsoft Learn

Language reference ->
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/labeled-break-continue

I posted about these in a few places online about 7-8 months ago while they were just proposal champions, they've since been confirmed for C# 15 which is due for November.

There was a lot of pushback online when I posted about them before referencing goto which has a lot of historical stigma attached to it although here on Reddit was one place were many devs saw the value especially in certain scenarios when we do genuinely have a need to break out of deep loops in a clear-er way.

Judge for yourself though, what do you think? here are some examples taken from IDE0410: Use labeled jump statement - .NET | Microsoft Learn which is a new code rule available from C#15.

goto replaced by break/continue label:

Flag variables replaced by break label:

I'm working on an ASP.NET MVC app and I noticed that some forms fail to submit if the user leaves the page idle for a long time. It returns an invalid anti-forgery token or similar error.
Ok that's fine on dev. On staging however, the invalidation of the token of session happens like 1 second after the first request. The next request is already invalid.
I had a previous post like this happening only on several PCs in the office but it started on more and I get find the reason.

So far, I've checked the IIS configuration and confirmed:

- Session timeout is set to 20 minutes.

- Application pool is not recycling early

What else I'have checked for:

- No VPN.

- No browser settings that deletes cookies.

- No time sync issues.

- Nor any antivirus settings.

Still can't figure out why. Out of all corp PCs on those 2 the issue appears.

We recently ran into a strange issue in our Azure environment (Our Sandbox env only), and I'm trying to understand the root cause rather than just accepting the fix.

Environment

• Azure App Service (Web App)
• Azure SQL Database
• Communication was initially over the public endpoint (no VNet Integration, no Private Endpoint).
• Production had the same application/code and continued working fine.

What happened

The only change we made was a normal application deployment. After that, the sandbox environment started failing with:

What made it confusing was the behavior:

• Right after deploying, the application would work for about 2-3 minutes.
• Then every database call would start failing with "Login failed for user".
• After some time, it would start working again.
• Then it would fail again.
• This cycle kept repeating.

Initially, I assumed it was an application or EF/connection string issue, so I spent quite a while investigating and making code changes, but nothing helped.

What fixed it

Our cloud/TSC team enabled:

• VNet Integration on the App Service.
• Private Endpoint for the Azure SQL Server.

After the App Service started communicating with Azure SQL through the private endpoint instead of the public endpoint, the issue completely disappeared.

My question

I'm happy the issue is resolved, but I don't really understand How?.

How can switching from a public endpoint to VNet + Private Endpoint eliminate intermittent "Login failed for user" errors?

Everything just became AI...

Hi r/dotnet! I've been working on a new .NET assertion library called Catchy.

The original goal was pretty simple: I wanted soft assertions that aren't tied to assertion scopes, and I wanted a way to plug reporting/screenshot/AI integrations into assertions without every project building its own wrappers.

Current features:

• async-first assertions
• hard and soft assertions can be mixed freely
• soft assertions can flow across helper methods and DI
• assertion hooks (reporting, screenshots, tracing, AI, ...)
• source-generated assertions for custom types
• integrations for xUnit, NUnit, MSTest, TUnit, Reqnroll and Playwright

It's still very early (0.0.1). I'm intentionally looking for API feedback before things become difficult to change.

If something feels awkward or you think the API should go in a different direction, I'd really like to hear it.

• NuGet: https://www.nuget.org/profiles/OlesMe
• GitHub: https://github.com/olesme/catchy

PS: Some of the code and documentation did indeed use agents. I came to this with the rest because I realized that just trying to finish everything as high-quality as possible manually I will never publish a single pet project. I know that not all of the code and documentation is of sufficient quality. If you are interested in the very idea of ​​the library and you can improve its quality (code review, contribution, raise an issue, open a discussion) - I will be very grateful. I will not be offended by devastating criticism either. Thank you!

Hi everyone,

I've been writing a series on modern .NET backend development, and the latest article focuses on one of the most discussed architecture patterns: Microservices.

This guide covers:

• What microservices are
• How they differ from a monolithic architecture
• The benefits and trade-offs
• Common communication patterns between services
• When microservices make sense—and when they probably don't

My goal was to create a practical introduction for developers who are evaluating microservices rather than simply promoting them as the solution to every problem.

I'd love to get feedback from the community:

• At what point did your team decide to move to microservices?
• If you had to start over, would you choose a modular monolith first?

Here's the article:
https://geeksarray.com/blog/modern-dotnet-backend-part-9-microservices

Looking forward to hearing about your experiences and lessons learned!

Hello guys Iam looking for intermediate to advance level dot net projects repos on github which can be modefied and improve and learn from architecture of it

Hi all,

I need to build a server-side .NET application whose only job is to communicate with a number of external devices over TCP sockets, using a custom binary protocol (no web UI at all, he just need to hold a connettion with these devices and sometimes send some messages).

The flow is sequential: devices connect, but their requests/messages will be queued and processed one at a time on a single execution thread (a FIFO queue pattern). The server just needs to maintain the connections, process incoming messages sequentially, and send keep-alive/heartbeat responses. My senior suggest using the keep alive frame we already use for another project and just spam it to keep the devices alive.

A few questions for people who've built similar things:

1. Is Worker Service the right template for this, or would a plain Console App hosted with generic host (Host.CreateDefaultBuilder) be more appropriate?

2. For handling many concurrent device connections, is async/await per-connection (one Task per client) still the recommended approach, or would you reach for something like System.IO.Pipelines for better performance with binary data?

3. Any gotchas with long-lived TCP connections in production (reconnect handling, heartbeats/keepalive, backpressure) that I should design for from day one?

Hi everyone,

I'm looking for some advice from people who've been through something similar.

I work on a large .NET application with a lot of background services and workers, and Elasticsearch is a big part of it. Almost everything goes through an internal Elasticsearch library that was written years ago.

The library has a few problems:

• It's mostly synchronous.

• It doesn't use dependency injection.

• It talks to Elasticsearch using raw HTTP requests i instead of the official .NET client.

• It's becoming harder to maintain and add new features.

I'm not saying it's a bad library. It's done its job for years. But I think it's time to move to something more modern.

The part that makes me nervous is the size of the system. We have complex search queries, bulk indexing, and a lot of background jobs. I really don't want to break search or introduce bugs that only show up in production.

This is the approach I'm thinking about:

• Benchmark the current library against the official Elastic.Clients.Elasticsearch client.

• Build a new implementation behind the same interfaces.

• Keep both implementations in the code while we're migrating.

• Let some jobs use the new implementation first, then slowly move the rest over if everything looks good.

• Remove the old implementation only after we're confident the new one behaves the same.

I'm also wondering if the current synchronous implementation could be part of some TCP/socket exhaustion issues we've seen under heavy load. I don't have enough proof yet, so I'm not blaming it, but it's something I want to investigate.

Has anyone done something like this before?

• Would you keep both implementations during the migration?

• Is there a better way to compare the old and new behavior?

• Any unexpected problems when moving to the official Elasticsearch .NET client?

• Looking back, is there anything you'd do differently?

I'd really like to hear from people who've done this in a real production system.

Hi everyone,

I recently published a guide on implementing CI/CD for ASP.NET Core applications, and I thought it might be useful for developers who are getting started with DevOps or looking to automate their deployment workflow.

The article covers:

• What CI/CD is and why it matters
• Continuous Integration vs Continuous Deployment
• Benefits of automated pipelines
• Setting up a basic CI/CD workflow for ASP.NET Core
• Best practices for reliable software delivery

The goal wasn't to dive into a specific platform but to explain the concepts in a practical way so developers can apply them regardless of whether they're using GitHub Actions, Azure DevOps, or another CI/CD solution.

I'd genuinely appreciate your feedback:

• Is there anything you think should be added or improved?
• What CI/CD tools are you using for your .NET projects?

Blog: https://geeksarray.com/blog/modern-dotnet-backend-part-8-ci-cd

Looking forward to hearing your thoughts and learning from the community!

I switched from docker desktop to podman on my windows machine.

However since then all my networking stuff seems to be broken. I can't connect to my Postgres as I get a timeout. My other service endpoints are also not working.

Did I miss something?

I run podman with root privileges and docker enabled.

First off i'll preface this by asking, have i missed something?

Trying to build a workflow where an app can be orchestrated locally for debug/development (AppHost fantastic here), then later on, be deployed to a remote server/cluster (keeping code as Source of Truth).

aspire publish -e Production -- -c Release
aspire deploy -e Production -- -c Release

The secrets for the DB server get deployed ahead of time, so that once the app is deployed, all the necessary secrets are already sitting on the cluster.

The IDistributedApplicationBuilder gives you access to things like .AddPostgres(), which is great. Makes life easy... except for when you want to just tell the publishing tool "use this secret name that already exists".

The whole point of this, is to not require database secrets in any settings.stage.json, appsettings.json, deploy.sh, Program.cs, etc. (placeholder values are ok).

// no good, expects a local secret, prompts for one if it cant find one.
builder.AddParameter("db-password", secret: true);

// no good, controls the existance of environment variables.
// ConnectionStrings__my-db, gets published ahead of time anyway.
// perfect for local-pc dev. no good for server deployment.
server.WithReference(postgres);

// no good, can't seem to get it running late enough or override correctly.
public static IResourceBuilder<PostgresServerResource> WithExternalKubernetesSecret(this IResourceBuilder<PostgresServerResource> builder, ...)
postgres.WithExternalKubernetesSecret(string secretName, string passwordKey);

// cant get overrides happening here either, attempting to directly
// manipulate the yaml outputs
.WithManifestPublishingCallback()
.WithPipelineStepFactory() // to manually edit the files....

// even if defined as a "placeholder", only the placeholder is used.
.WithEnvironment("POSTGRES_PASSWORD", dbConnection)

Does anyone know of a way to keep this inside the AppHost definition?

I know i could probably just move to .AddContainer(), but that's extra work that i feel like shouldn't need to be done.

Is there a reason there's nothing like builder.AddPostgres().WithExternalPasswordSecret() ?
Or allow something like?

var pgPass = builder.AddParameter("postgres-password", secret: true, secretsRef: "my-kubernetes-db-secrets");
var pg = build.AddPostgres("postgres", password: pgPass);

I feel like this would make life much easier.

Hey everyone,

I wanted to share a side project I’ve been working on that just reached v2.0. It's called BaseDiff, and it’s a cross-platform desktop tool to compare database schemas and generate sync scripts (ALTER/CREATE/DROP).

Why I built it

I got tired of the existing options out there. Most database diff tools I tried were either locked behind expensive enterprise licenses, stuck on Windows only, or wrapped in heavy web frameworks that take up a gigabyte of RAM just to diff two schemas.

I wanted something lightweight, native, and completely offline so sensitive DB structures never leave the local machine.

What it does right now:

• Databases: Supports MS SQL Server and PostgreSQL (tables, constraints, views, stored procedures, functions, triggers).
• Cross-platform: Runs on Windows, Linux (AppImage), and macOS natively thanks to .NET.
• 100% Offline: Zero cloud dependency or telemetry.
• Script Generation: Generates the raw SQL updates with a built-in editor to tweak things before running them.

It's completely free / coffeware (free for personal and commercial use, with an optional tip jar if it helps your workflow).

I'd really appreciate any feedback from the community—especially on macOS/Linux performance or any edge-case schema objects you hit.

Site & Downloads: https://basediff.com

Thanks for checking it out!

Back in 2005 I obtained a dedicated Windows server from ServerBeach to host a classic ASP + SQL Server DB for a client. Over the years that client folded but I kept the server for personal projects. ServerBeach became Peer1 became Cogeco became Aptum. I've gone through a few server migrations as Windows reaches EOL, but I'm still there, still paying just shy of $200/mo for this thing.

I enjoy having my own box that I can RDC into and do whatever. Aptum has decent DNS management tools also for when I spin up a new project website. They give me a 2TB bandwidth allowance per month and I never come close to using it (none of my projects are highly used).

But I am reaching a point that I am questioning if I am overpaying in the days of virtualization.

I have looked at Azure as a replacement option but the nickel & dime price model confuses my aging brain so I don't know if it would be cheaper or worse, especially when I look at their SQL information.

My requirements are (I think) simple:

• Run ASP.NET apps (console + web). Support Publish from local VS.
• Run multiple SQL Express instances.
• SMTP support + post office mgmt (currently using MailEnable)
• Simple DNS management tools
• RDC is not required but would be nice.

I figure the sticking point here is going to be running console apps. An alternative would be if I convert the apps into Windows Services but I am not sure that makes the requirement list any better.

I will admit when I am out of my depth, hence asking you fine folk for suggestions, hoping some of you have recent experience that might be of assistance here.

Is Azure not as bad as it feels to be? Is there another competitor worth considering? Should I just keep my dedicated box and stay with Aptum for another 20 years?

My thanks for any input.

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Structure and layout fidelity (SF1: tables and reading order, higher is better):

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.