#software-engineering

Pay by bank looks like two taps in the pitch deck. In production it's five hand-offs across three companies, and every one of them loses people.

Your ledger says a payment succeeded. The provider's settlement report, days later, disagrees. Which one is right?

Save to the database, then publish an event: two lines, two systems, and nothing that makes them agree. What happens when the process dies in between, and why every obvious fix still leaves a gap.

A checkout handler that calls the ledger, the warehouse, the email service and analytics in a row is as slow as all of them added together and as fragile as all of them multiplied. And every team that cares about payments makes it a little worse.

Two requests read the same row, both do their maths, both write back. One of them silently disappears. How the system should resolve that isn't one answer: it depends on whether the write is a delta, a quick piece of logic, or a human edit made minutes after the read.

One app, many customers, one WHERE clause keeping them apart. Forget it once and nothing crashes: tenant A just sees tenant B's invoices. How to make isolation something the system enforces, not something engineers remember.

You tap your card, the machine freezes, you tap again. Were you charged twice? An HTTP payment endpoint faces the same question on every retry, and without an idempotency key it gets it wrong.

AI made me ship faster, and for a while it also made me approve code I couldn't defend. Speed isn't progress if nobody owns the decisions.

A `Result<T, E>` union plus `tryCatch` wrappers that turn a throwing call into a value the caller has to inspect: the failure path becomes part of the return type instead of an invisible jump.

A client that retries a POST after a timeout can create the resource twice or charge a card twice. An idempotency key lets the server spot the retry and replay the first response instead of doing the work again.