<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Architecture on Hanh Pham's Blog</title><link>https://hanhpp.github.io/tags/architecture/</link><description>Recent content in Architecture on Hanh Pham's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 03 Sep 2026 09:30:00 +0700</lastBuildDate><atom:link href="https://hanhpp.github.io/tags/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Designing an Order Workflow: Putting the Patterns Together</title><link>https://hanhpp.github.io/posts/microservices-designing-an-order-workflow/</link><pubDate>Thu, 03 Sep 2026 09:30:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-designing-an-order-workflow/</guid><description>Boundaries, communication styles, technology, and sagas all sound reasonable in isolation. Here&amp;rsquo;s what it looks like to actually apply all four decisions to one real workflow, in order.</description></item><item><title>When Two-Phase Commit Isn't the Answer: Sagas for Microservice Transactions</title><link>https://hanhpp.github.io/posts/microservices-sagas-vs-two-phase-commit/</link><pubDate>Tue, 01 Sep 2026 10:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-sagas-vs-two-phase-commit/</guid><description>Splitting a monolith means splitting its database transactions too. The instinct is to reach for a distributed transaction. Here&amp;rsquo;s why that instinct is usually wrong, and what to do instead.</description></item><item><title>REST, gRPC, GraphQL, or a Broker: Picking Your Communication Tech</title><link>https://hanhpp.github.io/posts/microservices-picking-communication-tech/</link><pubDate>Thu, 20 Aug 2026 09:30:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-picking-communication-tech/</guid><description>The communication style (sync/async, request-response/event-driven) narrows the field. Here&amp;rsquo;s how the actual technologies stack up once you&amp;rsquo;re choosing among them.</description></item><item><title>Debugging Microservices: Where Did That Request Go?</title><link>https://hanhpp.github.io/posts/debugging-microservices-where-did-that-request-go/</link><pubDate>Sat, 15 Aug 2026 10:30:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/debugging-microservices-where-did-that-request-go/</guid><description>In a monolith, a stack trace tells you what went wrong. In microservices, you&amp;rsquo;re grepping across three services&amp;rsquo; logs at 2 AM trying to figure out which one lost the request. Here&amp;rsquo;s how to make that possible instead of painful.</description></item><item><title>Versioning Microservices Without Breaking Everyone</title><link>https://hanhpp.github.io/posts/microservices-versioning-without-breaking-everyone/</link><pubDate>Thu, 13 Aug 2026 15:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-versioning-without-breaking-everyone/</guid><description>In a monolith, renaming a field means updating all callers in one commit. In microservices, consumers upgrade on their own schedule, so your API has to evolve without breaking the ones that haven&amp;rsquo;t upgraded yet. Here&amp;rsquo;s how.</description></item><item><title>Running Microservices Locally Without Docker Compose Hell</title><link>https://hanhpp.github.io/posts/microservices-local-dev-without-docker-compose-hell/</link><pubDate>Tue, 11 Aug 2026 10:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-local-dev-without-docker-compose-hell/</guid><description>You split the monolith into twelve services. Now a new developer&amp;rsquo;s first week is spent getting Docker Compose to run all twelve on their laptop, and half of them crash because of a port conflict. Here&amp;rsquo;s how to make local development work without the pain.</description></item><item><title>Deploying Microservices Without the Fear</title><link>https://hanhpp.github.io/posts/microservices-deploying-without-the-fear/</link><pubDate>Sat, 08 Aug 2026 14:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-deploying-without-the-fear/</guid><description>In a monolith, deploy means pushing one thing. In microservices, every service deploys independently, which is the whole point, until you realize that &amp;lsquo;independently&amp;rsquo; also means &amp;lsquo;without knowing what the other services are doing right now.&amp;rsquo;</description></item><item><title>Database Per Service: The Pattern That's Harder Than It Sounds</title><link>https://hanhpp.github.io/posts/microservices-database-per-service/</link><pubDate>Thu, 06 Aug 2026 09:30:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-database-per-service/</guid><description>Each service owns its database. That&amp;rsquo;s the rule. But when a report needs data from four services, or a customer wants to see their complete order history, you&amp;rsquo;ve got a query problem that a single SELECT can&amp;rsquo;t solve. Here&amp;rsquo;s how to handle it.</description></item><item><title>Service Mesh: When You Actually Need One (and When You Don't)</title><link>https://hanhpp.github.io/posts/microservices-service-mesh-when-you-actually-need-one/</link><pubDate>Tue, 04 Aug 2026 11:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-service-mesh-when-you-actually-need-one/</guid><description>A service mesh gives you mTLS, traffic management, and observability without changing application code. It also gives you another piece of infrastructure to operate, debug, and explain to new hires. Here&amp;rsquo;s how to tell whether the trade-off is worth it.</description></item><item><title>The Five Ways Microservices Talk to Each Other</title><link>https://hanhpp.github.io/posts/microservices-five-ways-to-talk/</link><pubDate>Thu, 30 Jul 2026 10:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-five-ways-to-talk/</guid><description>Before picking REST, gRPC, or Kafka, you need to answer a more basic question: does this interaction block, and does the caller expect an answer? Get that wrong and no technology choice saves you.</description></item><item><title>What Actually Makes a Good Microservice Boundary</title><link>https://hanhpp.github.io/posts/microservices-boundaries-coupling-cohesion/</link><pubDate>Tue, 28 Jul 2026 10:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/microservices-boundaries-coupling-cohesion/</guid><description>Before you draw a single service boundary, you need a vocabulary for why some splits age well and others turn into a distributed monolith. Coupling and cohesion are that vocabulary.</description></item><item><title>Should You Even Use Microservices?</title><link>https://hanhpp.github.io/posts/should-you-even-use-microservices/</link><pubDate>Sat, 25 Jul 2026 10:00:00 +0700</pubDate><guid>https://hanhpp.github.io/posts/should-you-even-use-microservices/</guid><description>Microservices are a solution to organizational scaling problems, not a technology choice. Here&amp;rsquo;s how to tell whether you actually have the problem they solve, before you pay the cost.</description></item></channel></rss>