<?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 wid's blog</title><link>https://wid-blog.github.io/en/posts/tech/architecture/</link><description>Recent content in Architecture on wid's blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 09 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://wid-blog.github.io/en/posts/tech/architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Microservices Architecture</title><link>https://wid-blog.github.io/en/posts/tech/architecture/microservices-architecture/</link><pubDate>Sat, 09 May 2026 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/microservices-architecture/</guid><description>MSA is a decision about which criterion to use to decompose the system. Domain boundary, data ownership, scale pattern, failure isolation — the chosen criterion creates the service boundaries, and those boundaries decide communication and data in turn.</description></item><item><title>Event Sourcing and CQRS</title><link>https://wid-blog.github.io/en/posts/tech/architecture/event-sourcing-and-cqrs/</link><pubDate>Thu, 07 May 2026 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/event-sourcing-and-cqrs/</guid><description>ES and CQRS address how a system&amp;rsquo;s source of truth is shaped and how its views are separated from it. Adoption cost spreads across the system, so I lean toward adopting only when the value can be stated explicitly.</description></item><item><title>Distributed Transactions</title><link>https://wid-blog.github.io/en/posts/tech/architecture/distributed-transactions/</link><pubDate>Tue, 05 May 2026 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/distributed-transactions/</guid><description>Distributed transactions are about how a single ACID transaction decomposes across services and how its pieces are reassembled. The roles and trade-offs of 2PC, Saga (Choreography vs Orchestration), and Outbox.</description></item><item><title>Zero-Downtime Data Transition Pattern</title><link>https://wid-blog.github.io/en/posts/tech/architecture/zero-downtime-data-transition/</link><pubDate>Tue, 15 Apr 2025 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/zero-downtime-data-transition/</guid><description>A three-step pattern combining dual write and fallback read to transition data formats in live services without downtime.</description></item><item><title>Horizontal vs Vertical Slicing</title><link>https://wid-blog.github.io/en/posts/tech/architecture/horizontal-vertical-slicing/</link><pubDate>Sun, 10 Mar 2024 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/horizontal-vertical-slicing/</guid><description>The difference between splitting code by technical layers (horizontal) and by features or domains (vertical). Trade-offs and selection criteria for each approach.</description></item><item><title>Layered Architecture and Dependency Inversion</title><link>https://wid-blog.github.io/en/posts/tech/architecture/layered-architecture/</link><pubDate>Fri, 23 Feb 2024 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/layered-architecture/</guid><description>Layered architecture separates code into horizontal layers by technical responsibility. A summary of the four-layer structure, dependency direction rules, and how DIP decouples layers.</description></item><item><title>Implementing Hexagonal Architecture in Go</title><link>https://wid-blog.github.io/en/posts/tech/architecture/go-hexagonal-architecture/</link><pubDate>Wed, 21 Feb 2024 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/go-hexagonal-architecture/</guid><description>Core concepts of Hexagonal Architecture and its idiomatic implementation in Go using implicit interfaces and package structure for dependency direction control.</description></item><item><title>Incremental Cache Refresh Pattern</title><link>https://wid-blog.github.io/en/posts/tech/architecture/incremental-cache-refresh/</link><pubDate>Sat, 20 Jan 2024 00:00:00 +0000</pubDate><guid>https://wid-blog.github.io/en/posts/tech/architecture/incremental-cache-refresh/</guid><description>A pattern for switching from full cache refresh to incremental refresh. Separating data by update frequency and applying change detection reduces network costs.</description></item></channel></rss>