<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Rust Microservices Patterns on Atharva Pandey</title><link>https://atharva.page/series/rust-microservices-patterns/</link><description>Recent content in Rust Microservices Patterns on Atharva Pandey</description><generator>Hugo</generator><language>en-us</language><copyright>Copyright ©</copyright><lastBuildDate>Tue, 17 Jun 2025 13:19:00 +0000</lastBuildDate><atom:link href="https://atharva.page/series/rust-microservices-patterns/index.xml" rel="self" type="application/rss+xml"/><item><title>Lesson 8: Monolith-First — Modular monoliths in Rust</title><link>https://atharva.page/post/rust/rust-micro-monolith-first/</link><pubDate>Tue, 17 Jun 2025 13:19:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-monolith-first/</guid><description>&lt;p&gt;I&amp;rsquo;m going to tell you something that might sound weird after seven lessons about microservices patterns: don&amp;rsquo;t start with microservices. Start with a monolith. A well-structured, modular monolith that&amp;rsquo;s &lt;em&gt;designed&lt;/em&gt; to be split later.&lt;/p&gt;
&lt;p&gt;This isn&amp;rsquo;t contrarianism for its own sake. I&amp;rsquo;ve seen three teams build microservices from day one. All three regretted it. One team spent more time debugging distributed system issues than building features. Another had seven services that each handled about 50 requests per day — the infrastructure cost was absurd. The third discovered six months in that they&amp;rsquo;d drawn their service boundaries wrong and had to do a painful re-architecture.&lt;/p&gt;</description></item><item><title>Lesson 7: Testing Microservices — Contract tests and integration</title><link>https://atharva.page/post/rust/rust-micro-testing/</link><pubDate>Sat, 14 Jun 2025 07:33:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-testing/</guid><description>&lt;p&gt;I deployed a change to the order service that renamed a field from &lt;code&gt;total_amount&lt;/code&gt; to &lt;code&gt;total_cents&lt;/code&gt;. Made perfect sense — cents avoid floating-point nonsense. All unit tests passed. Integration tests passed. Staging looked fine.&lt;/p&gt;
&lt;p&gt;Production broke instantly. The payment service was still expecting &lt;code&gt;total_amount&lt;/code&gt;. It deserialized the response, got &lt;code&gt;None&lt;/code&gt; for the amount, and started processing $0 charges. We caught it in four minutes, but four minutes of free orders adds up.&lt;/p&gt;</description></item><item><title>Lesson 6: Distributed Tracing Across Services — Following requests</title><link>https://atharva.page/post/rust/rust-micro-tracing/</link><pubDate>Wed, 11 Jun 2025 10:45:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-tracing/</guid><description>&lt;p&gt;&amp;ldquo;It&amp;rsquo;s slow&amp;rdquo; is the most useless bug report in a microservices world. Slow where? The API gateway? The order service? The database query inside the payment service? The message queue between inventory and shipping? When a single user action touches five services and three databases, &amp;ldquo;it&amp;rsquo;s slow&amp;rdquo; could mean anything.&lt;/p&gt;
&lt;p&gt;I spent an entire afternoon once trying to track down a latency spike. Added timing logs to every service. Correlated timestamps across hosts. Manually stitched together the request flow from six different log streams. Found the culprit: a DNS resolution that was taking 800ms because of a misconfigured resolver — in a service I didn&amp;rsquo;t even know was involved.&lt;/p&gt;</description></item><item><title>Lesson 5: Service Mesh Integration — Istio, Linkerd, and Rust</title><link>https://atharva.page/post/rust/rust-micro-service-mesh/</link><pubDate>Mon, 09 Jun 2025 16:21:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-service-mesh/</guid><description>&lt;p&gt;I&amp;rsquo;ll be honest — when someone first pitched &amp;ldquo;service mesh&amp;rdquo; to me, I thought it was over-engineered marketing. You&amp;rsquo;re telling me I need a sidecar proxy bolted onto every pod, a control plane to manage those proxies, and custom CRDs to configure traffic routing&amp;hellip; just to do what a load balancer and some retry logic could handle?&lt;/p&gt;
&lt;p&gt;Then I ran a fleet of 20+ services in production. mTLS between everything? Doing that in application code is painful. Per-route retry policies? Circuit breaking with consistent configuration? Gradual traffic shifting for canary deploys? At that scale, doing it all in app code means doing it differently in every service, with different bugs in each implementation.&lt;/p&gt;</description></item><item><title>Lesson 4: Saga Pattern — Distributed transactions without 2PC</title><link>https://atharva.page/post/rust/rust-micro-saga/</link><pubDate>Sat, 07 Jun 2025 08:48:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-saga/</guid><description>&lt;p&gt;Here&amp;rsquo;s a scenario that&amp;rsquo;ll ruin your week. A customer places an order. Your order service saves it. Your payment service charges their card. Your inventory service reserves the items. Your shipping service schedules a pickup. Then the shipping service discovers the item is oversized and can&amp;rsquo;t be shipped to that address.&lt;/p&gt;
&lt;p&gt;Now what? The card&amp;rsquo;s been charged. The inventory&amp;rsquo;s been reserved. The order exists. You need to undo three things across three services, each with their own database, each with their own failure modes. Welcome to distributed transactions.&lt;/p&gt;</description></item><item><title>Lesson 3: Event-Driven Architecture in Rust — Decoupled systems</title><link>https://atharva.page/post/rust/rust-micro-event-driven/</link><pubDate>Thu, 05 Jun 2025 11:02:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-event-driven/</guid><description>&lt;p&gt;The worst production incident I ever dealt with was a cascading failure triggered by a single slow database query. Service A called Service B synchronously, which called Service C, which ran a query that usually took 2ms but on that particular Tuesday took 45 seconds because of a missing index on a new column. Service A&amp;rsquo;s thread pool exhausted, its health check failed, Kubernetes restarted it, and for twenty minutes the entire checkout flow was down — because of a read query in a recommendation engine.&lt;/p&gt;</description></item><item><title>Lesson 2: gRPC Microservices with tonic — Production-grade RPC</title><link>https://atharva.page/post/rust/rust-micro-grpc-services/</link><pubDate>Tue, 03 Jun 2025 14:37:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-grpc-services/</guid><description>&lt;p&gt;The first time I used gRPC in production was on a Go project. The experience was fine — &lt;code&gt;protoc&lt;/code&gt; generated stubs, you implemented an interface, done. Then I tried &lt;code&gt;tonic&lt;/code&gt; in Rust, and I realized what gRPC was &lt;em&gt;supposed&lt;/em&gt; to feel like. Type-safe request/response types generated at compile time, streaming that works with Rust&amp;rsquo;s async model, and interceptors built on the same Tower middleware stack as Axum. It&amp;rsquo;s gRPC done right.&lt;/p&gt;</description></item><item><title>Lesson 1: Service Boundaries and API Contracts — Where to draw the lines</title><link>https://atharva.page/post/rust/rust-micro-service-design/</link><pubDate>Sun, 01 Jun 2025 09:14:00 +0000</pubDate><guid>https://atharva.page/post/rust/rust-micro-service-design/</guid><description>&lt;p&gt;I once joined a team that had 47 microservices for what was essentially a CRUD app with a payment flow. Forty-seven. Each one had its own database, its own deployment pipeline, its own on-call rotation. When a customer placed an order, the request bounced through eleven services before a confirmation email went out. Latency was terrible, debugging was a nightmare, and nobody could explain why the &amp;ldquo;UserPreferences&amp;rdquo; service existed separately from the &amp;ldquo;UserProfile&amp;rdquo; service.&lt;/p&gt;</description></item></channel></rss>