Queue Names Are the Whole Topology
One naming class in DShop.Common decides every exchange, routing key and queue in the estate - the message topology is a string-formatting problem.
Archive
Every article
Newest first, grouped by year. Search or filter by topic.
- 556 articles
All
.NET
AI Engineering
Architecture
Azure & DevOps
Data Warehousing
Engineering Practice
Microservices
Web APIs
The Framework Before the Framework
DShop.Common is the shared library nine microservices were built on - and the rough draft of a framework its authors later shipped as Convey.
The Ecosystem Around the Chassis
Convey did not appear from nowhere and it does not stand alone. DShop, Pacco, Ntrada, Chronicle, Pactify — the DevMentors constellation the toolkit grew out of and feeds into, which repo to study for what, and the close of both series.
From Clone to Chassis: The Onboarding Path
There is no dotnet new template and no CLI — Convey's onboarding is docs, samples and source. Reading the repo-of-repos layout and its packing scripts, then walking the actual path: build your first service from an empty project, one config section at a time.
Testing a Service Built on a Chassis
Twenty-two parts of source reading and not one about tests. How Convey's design choices land on your test suite: handlers that fake beautifully, an exposed host builder for integration tests, config flags as test infrastructure, and conventions that deserve a pin.
The Compose File Is the Architecture Diagram
Three toy services, ten infrastructure containers. Reading Convey's docker-compose stack as the honest bill of the chassis: what each container is for, which volumes actually persist, the per-OS variants, and what I would cut in 2026.
Two Outboxes, One Interface
The parent series covered the outbox pattern; it never compared the implementations. Entity Framework gets a real transaction, Mongo gets sessions you can switch off, expiry is three different mechanisms — and the processor that drains them all is a fire-and-forget timer.
One appsettings.json, Read Top to Bottom
Convey's real manifest is not Program.cs — it is the config file. Reading the Orders sample's appsettings.json as a single artifact: the section-per-package convention, the fleet of enabled:false switches, and what the defaults quietly tell you about production.
The Object Store in the Corner: Convey and OpenStack Swift
Convey.Persistence.OpenStack.OCS is the package the whole first series skipped — a hand-rolled Swift object-storage client with Keystone auth, an operation-result pattern, a server-side COPY verb, and a re-authentication habit worth learning from.
Three Services, One Order: The Sample System the Series Skipped
The 22-part Convey series read the packages; it never once walked the sample system that ships with them. Opening the missing chapters with the trip an order takes through Orders, Pricing and Deliveries — and what the samples quietly teach that no package README does.
Nine Versions Later — What the Star Taught Me
From an inverted foundation to the version I'd deploy, KC Star evolved through ten explicit releases in the open. The retrospective on all of it - what versioning a schema publicly taught me about drift, variants, bugs as motivations, and simplicity as the real destination.
The Wishlist — Four Engines I Haven't Built
KC Star's wishlist folder holds four future engines - a multi-engine measures platform, multi-tenancy, predictive monitoring, and automated maintenance - all marked research phase, one with 500 lines of not-ready reference SQL. An honest look at the roadmap, and which one I'd build first.
Caching Calculations, Not Permissions
V9 cached yes/no permission answers and inherited a revocation-staleness hazard. V9 Simplified caches finished calculation results instead - keyed on the employee's permission list, so a permission change changes the key and the stale entry is simply never hit. A better choice about what to cache.
A Permission Gate Inside Every Measure
KC Star V9 Simplified puts the permission check inside the measure calculation itself - a HasPermission call in the CASE that computes each aggregate. Read-time filtering, column masking, and an access level the view derives on the fly. The whole model, inlined.
Direct Permissions, No Groups
KC Star V9 Simplified's schema is four permission tables and five seeded personas - full access, online-only, store-only, delivery-and-quotes, commission-only. GetFilteredSalesData takes an employee and returns exactly their slice. Permissions you can read in one table.
The Version That Deletes the Cleverness
After nine versions of accumulating ambition, KC Star V9 Simplified does the rarest thing - it takes features away. No permission groups, no group cache, just direct permission lists. The README recommends starting here. Kicking off the series on the version I would actually deploy.
A Cache for Yes and No
KC Star V9 checks permissions on every calculation, and checking is expensive. So it caches the yes/no answers in a PermissionCache table with a one-hour TTL and an upsert on every miss. Here is how it works, the claimed 95 percent hit rate, and the real cost of caching authorization.
NULL Means You Can't See It
When KC Star V9 denies a measure, it returns NULL, not zero - and the difference matters enormously once those values flow into aggregates. Here is the semantics of denial, the PermissionContext that records it, and why a redacted zero would quietly corrupt every total downstream.
From Per-Employee to Per-Group
Fusing per-employee permissions with per-change recalculation multiplies work by headcount. KC Star V9 ships both the naive per-employee implementation and an optimised per-permission-group one that collapses a thousand employees into seven groups. The most important design call in the version.
Two Engines, One Version
KC Star V9 fuses V8's intelligent recalculation with V6's permission-aware calculations - and folds the employee and their permissions into the very hash that decides what to recompute. Kicking off the series where two engines meet in one version, and complexity meets its reckoning.
When Selective Isn't — the V8 Batch Path
KC Star V8's row-level trigger is genuinely selective. Its batch path, despite the name, loops every calculation-affecting dimension and recomputes most measures anyway. An honest audit of where the selectivity holds, where it doesn't, and a measure that zeroes itself out.
Migrating a Live Star from V7 to V8
Switching KC Star from always-rebuild to selective recalculation means dropping V7's triggers and installing V8's without losing data. Unlike V7's chaotic refactor, this migration ships a real verification function - and one landmine where dimension ids mean different things.
A Dependency Map Between Dimensions and Measures
KC Star V8's intelligence lives in one table - MeasureDimensionDependency - mapping which measures each dimension drives, with a DIRECT/INDIRECT/AGGREGATION type and an impact weight. Here is how the map is built, seeded and generated, and the priority formula that reads it.
The Update That Recalculated Nothing
The most satisfying demonstration of KC Star V8 is an UPDATE that does no work. Change PaymentMethod, a dimension nothing depends on, and the selective trigger recalculates zero measures. Here is the trigger that pulls it off - and a tautological bug sitting right beside it.
Recalculate Only What Changed
Every version through V7 rebuilt all the measures when a dimension changed. KC Star V8 recalculates only the ones that actually depend on what moved - dependency analysis, selective recalculation, and claimed 60 to 80 percent less work. Kicking off the intelligent recalculation series.