Newest first, grouped by year. Search or filter by topic.
Eleven parts of reading one commit. Inflow's dependency-inversion boundary survived a real transport swap intact - and everything ambient that used to travel with a message did not. The retrospective, the ledger, and what I would take from it.
Inflow's transport seam is one method wide and genuinely transport-agnostic, but it has exactly one implementation and no default. A four-line Null Object and one if statement would have turned a fork in the road into a configuration flag.
The extracted Customers service ships one EF migration that creates three empty tables in a brand-new database. Nothing dual-writes, nothing backfills, nothing reconciles - and the only path that repopulates the service is events that have not happened yet.
Inflow's monolith failed startup when two modules disagreed about the shape of a shared event. The microservices branch deletes that check from exactly the boundary that became remote - and it turns out the deletion was not optional.
Inflow did not delete the module it extracted. It copied sixty-odd files into a new service, flipped one boolean, and left both copies in the solution - a decision that is better than it first looks and costs more than it first looks.
Inflow publishes a message id onto the wire, RabbitMQ delivers it, and the subscriber never reads it. The response was a guard that skips deduplication rather than one that reads the id - and the correlation id that does cross is a fresh random Guid.
On Inflow's microservices branch the wire address of every event is derived from the CLR type name, computed independently on both sides of the network. Two records in two assemblies match only because someone spelled them the same way.
Inflow's queue template would have given three modules one shared queue and turned publish-subscribe into competing consumers. Eight hand-written string literals in three projects are what prevent it - and forgetting a ninth would not be an error, just silence.
The whole RabbitMQ adapter that makes Inflow's monolith talk to an extracted service is five files in one folder. Reading them shows how small a real transport swap can be - and where the fan-out quietly narrowed from every handler to exactly one.
Inflow's IMessageBroker is byte-identical on the monolith branch and the microservices branch, and not one handler, saga or controller changed to accommodate a real broker. That is a genuine result - and the reason it worked is also the reason for everything that goes wrong later.
Ask git what an extraction cost and it will confidently give you the wrong number. Inflow's microservices branch diffs at 161 files against master - the honest figure is 108, and the fifty-three-file gap is a lesson in how migration retrospectives get fabricated.
Every modular monolith promises you can extract a module later. Inflow has a branch where someone actually did it - one module lifted into its own process behind a gateway and a real broker. This series reads that branch line by line.
Four non-trivial defects appear at near-identical line numbers in both builds of the same product - a ground-up rewrite by the same authors relocated them rather than finding any.
DevMentors shipped Trill as nine microservice repos, then rebuilt the identical product as a modular monolith three months later - giving us a controlled experiment in architecture that almost never exists in public.
Trill's Blazor WebAssembly client has twenty Razor components, thirty-seven inline style attributes, two authored class names and one stylesheet containing a single rule - and the thinness is not an oversight, it is the most precise measurement of what a teaching repository is.
An honest retrospective on Trill's five services and its client - twelve xunit scaffolds with no test files and no project references, a green test script over nothing, and a defect list where almost every entry would have died to a four-line assertion.
Trill's entire advertising product resolves to one boolean on somebody else's entity - a published ad is a Stories-service story with Highlighted set true - and the flag is priced at a hundred units a day while the same field is free on the public endpoint.
Trill's Timeline service stores each story body once and fans out only the identifier into every follower's sorted set - the right hybrid design, executed as a sequential foreach with one Redis round trip per follower and no batching anywhere.
Trill's entire ranking engine is thirty-nine lines of OrderByDescending().Take(10) over counters that only ever increase - no time window, no decay, no visibility filter - so once the top ten stabilises it can never change again.
The same .NET format specifier means thirty-two hex digits on a Guid and a grouped decimal on a long - and Trill's timeline writes its sorted-set members one way then reads them the other, so every non-empty timeline throws.
Trill's User constructor stores the name trimmed but not lower-cased, and the repository looks it up lower-cased. Any account with a capital letter in its name can never be found, which means it can never sign in - and the test fixture is all lowercase.
Trill's Stories service ships a complete caller-identity abstraction - context, factory, claims, an IsAdmin flag - registers it in the container, and injects it into nothing, while every endpoint reads the user id out of the request body instead.
Trill's browse endpoint loads every rating document for every story on the page into process memory and sums them in LINQ - while the same codebase already has a server-side SumAsync that returns the number without moving a single document.
Trill creates one compound index on its ratings collection, keyed userId then storyId, and every read query in the service filters on storyId alone - so the only index that exists cannot serve the only queries that run.
Trill wraps every command handler in logging, metrics, tracing and an outbox using Scrutor's TryDecorate - and the whole arrangement only works because a single attribute keeps the decorators out of the assembly scan that registers handlers.
