Newest first, grouped by year. Search or filter by topic.
Inflow's request collection contains a captioned request that grants full administrative permissions to an anonymous caller. The mechanism is four lines long, the documented happy path requires it, and the repository nowhere says it is on purpose - here is all of that, and the case for the defence.
GET /payments returns a 404 in Inflow's own root request file. The reason is not a typo - it is the Payments module exercising exactly the architectural freedom the README advertises, which makes this 404 the best evidence in the repository that the claim is true.
Getting money into a wallet in Inflow takes five HTTP requests and nine in-process reactions nobody documents. Reconstructing that path from source is the only way to get it - and every failure along it returns 204 No Content.
Inflow ships an executable request collection - five .rest files, thirty-seven requests. On a fresh clone nine of them return a 2xx, and eight of those nine are in one file. This series reads the repository itself as the artefact.
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.
One sentence describes every failure convention in Inflow's shared framework - startup misconfiguration throws, runtime message failure is logged and dropped. The retrospective on fourteen parts of source-reading, including what to steal, what to avoid, and where this design should not go.
Inflow reads every configuration section by building and disposing an entire service provider - twenty-two of them during startup. Two of those calls do not read anything; they mutate a registry, and they only work because of how three singletons were registered.
Inflow's inbox writes a row only after the handler succeeds, which makes its own duplicate-check predicate dead code and its name wrong. It is a good Idempotent Receiver with a one-hour memory, a decorator that resolves from the wrong provider, and an orphaned brace pair.
Two booleans govern Inflow's messaging spine. Taking their product gives four behaviours - one shipped and working, two working differently, and one that throws a NullReferenceException every second forever because the component that would prevent it only exists in another cell.
Inflow ships a complete transactional outbox - table, poller, cleanup jobs, type registry - and one CreateScope() call means the outbox row commits on a different DbContext from the state change it is supposed to be atomic with.
Inflow registers every handler by assembly scan and then wraps them in decorators. Those two techniques are incompatible unless something tells the scanner to skip the decorators - and in this codebase that something is a marker attribute with no tests and no comment explaining what it prevents.
Inflow carries request identity across its async message boundary in a static AsyncLocal. The line that populates it uses null-coalescing assignment inside a long-lived loop, so every message after the first runs under the first one's correlation id, trace id and user.
Inflow's message broker is eighty-eight lines with a three-way branch, backed by an unbounded channel and a single background reader. Reading it shows where the delivery guarantee actually is - and that on shutdown, whatever is still queued is discarded without a log line.
Inflow's boot-time contract verifier is excellent and almost unused. A census of every consumer-side type copy in the estate shows four protected and fourteen not - and the two failure modes are a startup crash and a silently null property.
