Posts

Your Network Is Not Uniform

Image
Why the Edge Must Understand the World the Core Ignores In the previous article, we deliberately made the core less intelligent. That sounds counterintuitive at first glance, but it was entirely by design. Business logic should never have to reckon with raw HTTP headers, Redis caches, Kafka partitions, regional failovers, vendor SDK quirks, or database connection pool limits. The domain core must understand the business rules and strictly nothing more. That is the Rule of Anonymity : it produces an uncompromised domain model composed solely of accounts, payments, entitlements, and state machines, completely isolated from whether the underlying platform runs on AWS, Postgres, or a message broker. Yet, there is an unavoidable tension at play: while the core has the luxury of ignoring the outside world, your user does not. The Same Payment, Two Radically Different Journeys Consider a simple $5 payment executed under two different physical conditions. Customer A taps Pay while...

If Your Business Logic Knows AWS Exists, It Isn’t Business Log

Image
Open up your payment service codebase right now and check the imports. What do you see? Odds are, your core domain knows intimately that it lives in AWS. It knows that the request arrived over HTTP, that sessions reside in Redis, and that transaction records settle into Postgres. It knows the exact merchant gateway SDK it talks to, and it knows Kafka is waiting to broadcast the result. PaymentService → AWS + HTTP + Postgres + Kafka + Redis At first glance, this feels harmless. We tell ourselves, "Of course it knows these things—the code has to actually run somewhere." We build fast, wire frameworks directly into domain classes, and celebrate shipping the feature on time. If the sole responsibility of your service is to decide whether money can legally and safely transfer from Account A to Account B—why does that decision care about the names of AWS, Kafka, or Postgres? None of those tools change the fundamental ...

Your Microservices Haven't Failed. They Have Forgotten Why They Exist.

Image
The alert fires: the payment service is timing out. You pull up distributed tracing, bracing to debug a payment gateway failure or a database lock. Instead, the trace hands you a bewildering breadcrumb trail: Payment ↳ Tokenization ↳ User Profile ↳ Legacy Rules Engine ↳ Kafka Partition ↳ [TIMEOUT] That overloaded Kafka partition has nothing to do with processing payments. Yet somehow, it’s holding up real money. On paper, everything was done "by the book." The services live in independent repositories. They deploy through separate CI/CD pipelines, run in isolated containers, report to dedicated dashboards, and belong to different teams. Yet when an unrelated dependency stumbles, the core user flow halts. Your microservices haven’t failed technically. They’ve just forgotten why they were split up in the first place. We Confused Deployment Independence With Real Decoupling For years, the industry treated the mo...

The Silence After the Write

Image
The charge succeeded. The customer never heard about it. Ten seconds later, they pressed Pay again. Somewhere between those two events lies one of the hardest problems in distributed computing. The Transit Gate Dilemma A phone sends a request to charge $5 . The server validates, commits the ledger write, and moves the money. The train enters a tunnel—connectivity drops instantly. The 200 OK never reaches the client. Server View Transaction Committed (Succeeded) Client View Nothing Happened (Timeout) SYSTEM ENTERED STATE: UNKNOWN Retry risks a double-charge. Refusing the retry risks failing a transaction that never executed. “Networks fail. The problem is not the broken pipe—it is that our architecture assumed the response would always arrive to tell us the truth.” This Is How Architectural Dementia Begins The failure at the transit gate is no...

Cross-border payments

Image
  Cross-border payments are not fundamentally slow or expensive because we lack faster payment technology; they are slow and expensive because independently designed payment systems, regulations, compliance regimes, currencies, institutions, and governance models do not interoperate.

Learn to Think in Diagrams with DrawDiagrams

Image
A diagram does not just make a report look clean—it reveals how your mind works. When you map a system, you are forced to answer the hard questions: Where does data originate? Who owns state? What fails when a network call drops? The best engineers, architects, and technical leaders do not think in paragraphs—they think in systems, boundaries, and flows. DrawDiagrams is a free, zero-friction, browser-native tool built to turn visual thinking into muscle memory. No accounts, no locked proprietary formats, and no bloated setup: just clean, human-readable code that instantly renders into production-ready diagrams. Why Visual Literacy Sets You Apart In coursework, technical interviews, and engineering teams, plain prose breaks down quickly: Algorithms: Hide behind nested conditionals instead of clear control flow. Distributed systems: Disguise race conditions and single points of failure. Team workflow...

Are you looking for research oppurtunity?

Image
  2nd or 3rd year engineering students: Looking for real-world research experience? Drop a comment below to get involved in an upcoming initiative.