Architecture on

Lesson 10: When Not to Use Rust — Honest trade-offs

Wed, 05 Nov 2025 11:46:00 +0000

I like Rust. I’ve written 9 lessons about using it in production. I think it’s one of the most well-designed languages of the last twenty years. And I’m about to spend an entire article telling you when you shouldn’t use it.

Because the most dangerous engineers aren’t the ones who don’t know Rust — they’re the ones who think Rust is always the answer. I’ve been that engineer. I once argued for rewriting a Flask API endpoint in Rust because “the response time was too high.” The response time was 200ms, and 180ms of that was a database query. Rust would have saved us maybe 5ms of JSON serialization. My team lead asked me to go take a walk.

Lesson 9: War Stories — Lessons from real Rust deployments

Sun, 02 Nov 2025 15:08:00 +0000

Every language looks great in blog posts. Production is where the truth comes out. I’ve been running Rust services in production for a few years now, and while I’m convinced it’s the right tool for certain problems, I’ve also hit situations where Rust did something I didn’t expect, or where its strengths became weaknesses in surprising ways.

These are real stories. Some names and details are changed, but the bugs and the lessons are exactly as they happened.

Lesson 8: Migrating Services from Go/Python/Java to Rust — When and how

Thu, 30 Oct 2025 09:33:00 +0000

I’ve been involved in three Rust migrations. One from Python, one from Go, one from Java. Two were successes. One was a disaster that got cancelled six months in after burning a quarter of the team’s roadmap capacity.

The failed one wasn’t a technical failure — the Rust code was fine. It failed because we rewrote the wrong service, at the wrong time, for the wrong reasons. “Rust is faster” was the entire justification. Nobody had measured whether speed was actually the bottleneck.

Lesson 7: Feature Flags at the Type Level — Compile-time feature control

Tue, 28 Oct 2025 13:19:00 +0000

We had a feature that was ready for staging but absolutely not ready for production. In my previous Go gig, we’d have used a runtime feature flag service — LaunchDarkly or similar. Evaluate a boolean at request time, show the new code path to internal testers, hide it from everyone else.

In Rust, we had another option. We could decide at compile time whether the feature existed in the binary at all. Not a runtime check. Not a boolean. The code literally wasn’t in the production binary. You couldn’t accidentally enable it. You couldn’t exploit it. It didn’t exist.

Lesson 6: API Versioning and Backwards Compatibility — Don't break your users

Sun, 26 Oct 2025 10:55:00 +0000

I once shipped a “minor” API change on a Friday. Renamed a JSON field from user_name to username. Seemed harmless — we were cleaning up inconsistencies. By Monday morning, we had 14 support tickets from integration partners whose parsers broke. One partner had hardcoded the field name into a system that processed payroll. People didn’t get paid because I renamed a JSON field.

That was the last time I treated backwards compatibility as optional.

Lesson 5: Multi-Crate Workspace Architecture — Scaling your codebase

Thu, 23 Oct 2025 16:42:00 +0000

Our compile times hit 8 minutes. Not from scratch — incremental. Change one line in the domain model and wait 8 minutes to see if it worked. Three engineers were actively avoiding making changes to shared code because the feedback loop was unbearable.

The problem was obvious: everything lived in one crate. The domain model, the HTTP handlers, the database layer, the gRPC server, the background workers — all sharing one Cargo.toml with 47 dependencies. Touch anything and the whole thing recompiles.

Lesson 10: Interpreter Pattern — DSLs and parsing

Wed, 22 Oct 2025 12:00:00 +0000

A few years ago I needed to let non-technical users define filtering rules for a data pipeline. The options were: embed Lua, use a YAML config with increasingly awkward syntax, or write a small domain-specific language. I picked the DSL. It took two days in Rust, and the result was a type-safe, sandboxed expression evaluator that couldn’t crash the host program no matter what users typed. Try getting that guarantee with dynamic code execution in Python.

Lesson 4: CQRS and Event Sourcing — Separating reads from writes

Tue, 21 Oct 2025 08:27:00 +0000

We had this inventory service that was doing fine until it wasn’t. Reads were simple — “how many units of product X are available?” Writes were complex — reservations, adjustments, transfers between warehouses, reconciliation with physical counts. Both read and write operations hit the same database table, the same data model, and the same set of queries that were getting increasingly gnarly.

Then we hit Black Friday. Read traffic spiked 40x. The complex write queries were locking rows that the read queries needed. We couldn’t scale reads without scaling writes. We couldn’t optimize the read path without breaking the write path’s invariants.

Lesson 9: Entity Component System — Data-oriented design

Sun, 19 Oct 2025 15:30:00 +0000

I spent years thinking about game objects the OOP way. A Player extends Character extends Entity. A Goblin extends Enemy extends Character extends Entity. Then someone asks “what if a goblin can be mind-controlled and act like a player?” and your inheritance hierarchy collapses.

ECS — Entity Component System — is the answer that the game development world converged on, and it’s fundamentally a Rust-shaped idea. Data and behavior are separated. Composition replaces inheritance. Cache-friendly memory layouts replace pointer-chasing object graphs. Rust’s ownership model maps onto ECS so naturally that Bevy — the most popular Rust game engine — is built entirely around it.

Lesson 3: Hexagonal Architecture in Rust — Ports, adapters, and boundaries

Sun, 19 Oct 2025 11:05:00 +0000

About a year ago, I had to swap out our payment provider. In Go, that would’ve been a two-week project — chasing down every place we called Stripe’s SDK, updating structs, fixing test mocks. In our Rust service, it took a day and a half. The reason wasn’t Rust itself. It was how we’d structured the code.

Hexagonal architecture (sometimes called “ports and adapters”) is one of those patterns that sounds academic until you actually need to replace a database, swap a message broker, or test your business logic without spinning up Docker containers. In Rust, traits make it feel natural rather than ceremonial.

Lesson 2: Domain Modeling with Rust's Type System — Making impossible states impossible

Fri, 17 Oct 2025 14:38:00 +0000

We shipped a bug to production that cost us about three hours of incident response and a very uncomfortable Slack thread. The root cause? Someone passed a user_id where an order_id was expected. Both were String. Both were UUIDs. The compiler had no way to tell them apart. The function signature said fn cancel_order(order_id: String, user_id: String), and someone called it with the arguments flipped.

This is the kind of bug that makes you rethink everything. Not because it’s complex — because it’s stupid. And stupid bugs that slip through a strong type system mean the type system wasn’t being used right.

Lesson 8: Middleware / Chain of Responsibility — Tower-style

Thu, 16 Oct 2025 07:15:00 +0000

If you’ve built anything with Express, Koa, or ASP.NET, you know middleware. A request comes in, passes through a chain of handlers — logging, auth, rate limiting, CORS — and eventually reaches your application logic. Each handler can modify the request, short-circuit the chain, or pass it along.

The Chain of Responsibility pattern from the GoF book is basically the same thing. The difference is branding.

What makes this pattern interesting in Rust is tower — the crate that defines how middleware works across the entire Rust async ecosystem. Axum, Tonic, Hyper — they all use Tower’s Service trait. Understanding it unlocks the middleware patterns in all of these frameworks.

Lesson 1: Structuring a Large Rust Application — Beyond hello world

Wed, 15 Oct 2025 09:14:00 +0000

The moment I knew our Rust project structure was broken was when a junior engineer asked me where to put a new endpoint. I opened the repo, stared at the src/ directory, and realized I couldn’t confidently answer. We had 40,000 lines of Rust spread across files with names like utils.rs, helpers.rs, types.rs, and the ever-popular misc.rs. Everything compiled. Nothing made sense.

Most Rust tutorials stop at “put your code in main.rs and maybe lib.rs.” That works for a CLI tool or a weekend project. It completely falls apart when you’ve got a team of eight engineers building a platform with multiple services, shared domain logic, and infrastructure that’s evolving every sprint.

Lesson 7: Repository Pattern — Abstracting storage

Mon, 13 Oct 2025 13:45:00 +0000

Every backend developer eventually writes the same code: a function that takes a database connection, runs a query, maps the rows to a struct, and returns it. Then you write another one. And another. Pretty soon your business logic is tangled up with SQL strings and connection pool handles, and testing anything requires a running database.

The Repository pattern fixes this. It’s old — Martin Fowler wrote about it in 2002 — but the way Rust implements it is genuinely different from what you’d do in Java or C#. Rust’s trait system, combined with generics and lifetimes, gives you a repository abstraction that’s zero-cost in production and trivially mockable in tests.

Lesson 6: Factory Patterns — When constructors aren't enough

Sat, 11 Oct 2025 10:00:00 +0000

Here’s a hot take: most “Factory pattern” usage in Java and C# exists purely to work around limitations of constructors. Constructors can’t have descriptive names. They can’t return a different subtype. They can’t fail gracefully. So you wrap them in a static method and call it a Factory.

Rust doesn’t have constructors at all. Every struct is constructed directly, and associated functions already do what Factory Method does in OOP. So do you even need the Factory pattern in Rust?

Lesson 5: Decorator Pattern — Wrapping with trait composition

Thu, 09 Oct 2025 16:30:00 +0000

I remember the moment Decorator clicked for me. I was reading the source for Java’s I/O library — BufferedInputStream wrapping FileInputStream wrapping InputStream. Three layers deep, each adding behavior without subclassing. Elegant. Then I tried to write the same thing in Rust and learned that “wrapping a thing while preserving its interface” is a fundamentally different exercise when you don’t have inheritance.

The good news? Rust’s version is often better than the OOP original, because composition is the default and the compiler enforces the contracts.

Lesson 4: Command Pattern — Closures as commands

Tue, 07 Oct 2025 09:20:00 +0000

The Command pattern has always struck me as one of those patterns that’s really just “wrap a function call in an object.” In Java, you create a Command interface with an execute() method, make a class for each command, and pass them around. It takes about 40 lines of boilerplate to do what a lambda does in one.

In Rust, closures are the Command pattern. But when you need undo, history, or serialization, you still need the structured version — and Rust’s ownership model makes the undo/redo part surprisingly elegant.

Lesson 3: Observer Pattern — Channels and callbacks in Rust

Sun, 05 Oct 2025 11:45:00 +0000

The Observer pattern is where Rust’s ownership model gets really opinionated. In C# or Java, Observer is simple — maintain a list of listeners, call a method on each when something happens. But “a list of mutable references to objects that can be called at any time” is basically everything Rust’s borrow checker exists to prevent. So how do you do event-driven programming in Rust? You have more options than you’d think, and some of them are better than what OOP languages offer.

Lesson 2: Strategy Pattern — Trait objects and generics

Fri, 03 Oct 2025 14:15:00 +0000

In my first real Go project, I wrote an interface for a payment processor. Two implementations — Stripe and PayPal. Simple polymorphism. When I tried the same thing in Rust, the compiler hit me with a wall of errors about dyn, Box, object safety, and sized types. It took me a full afternoon to understand what was happening. The Strategy pattern — which is trivial in most OOP languages — forced me to actually understand Rust’s type system. And I came out the other side a better programmer for it.

Lesson 1: Builder Pattern — Typestate builders and compile-time validation

Wed, 01 Oct 2025 08:30:00 +0000

I once spent three days debugging a production outage caused by a builder that silently accepted a missing host field and defaulted to localhost. In Java. The builder compiled fine, the tests passed — because they ran against localhost — and the deployment connected to nothing. That was the day I stopped trusting optional fields in builders.

Rust’s type system lets you make that entire category of bug impossible. Not at runtime. Not with validation methods. At compile time.

Lesson 8: Monolith-First — Modular monoliths in Rust

Tue, 17 Jun 2025 13:19:00 +0000

I’m going to tell you something that might sound weird after seven lessons about microservices patterns: don’t start with microservices. Start with a monolith. A well-structured, modular monolith that’s designed to be split later.

This isn’t contrarianism for its own sake. I’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’d drawn their service boundaries wrong and had to do a painful re-architecture.

Lesson 7: Testing Microservices — Contract tests and integration

Sat, 14 Jun 2025 07:33:00 +0000

I deployed a change to the order service that renamed a field from total_amount to total_cents. Made perfect sense — cents avoid floating-point nonsense. All unit tests passed. Integration tests passed. Staging looked fine.

Production broke instantly. The payment service was still expecting total_amount. It deserialized the response, got None for the amount, and started processing $0 charges. We caught it in four minutes, but four minutes of free orders adds up.

Lesson 6: Distributed Tracing Across Services — Following requests

Wed, 11 Jun 2025 10:45:00 +0000

“It’s slow” 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, “it’s slow” could mean anything.

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’t even know was involved.

Lesson 5: Service Mesh Integration — Istio, Linkerd, and Rust

Mon, 09 Jun 2025 16:21:00 +0000

I’ll be honest — when someone first pitched “service mesh” to me, I thought it was over-engineered marketing. You’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… just to do what a load balancer and some retry logic could handle?

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.

Lesson 4: Saga Pattern — Distributed transactions without 2PC

Sat, 07 Jun 2025 08:48:00 +0000

Here’s a scenario that’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’t be shipped to that address.

Now what? The card’s been charged. The inventory’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.

Lesson 3: Event-Driven Architecture in Rust — Decoupled systems

Thu, 05 Jun 2025 11:02:00 +0000

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’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.

Lesson 2: gRPC Microservices with tonic — Production-grade RPC

Tue, 03 Jun 2025 14:37:00 +0000

The first time I used gRPC in production was on a Go project. The experience was fine — protoc generated stubs, you implemented an interface, done. Then I tried tonic in Rust, and I realized what gRPC was supposed to feel like. Type-safe request/response types generated at compile time, streaming that works with Rust’s async model, and interceptors built on the same Tower middleware stack as Axum. It’s gRPC done right.

Lesson 1: Service Boundaries and API Contracts — Where to draw the lines

Sun, 01 Jun 2025 09:14:00 +0000

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 “UserPreferences” service existed separately from the “UserProfile” service.

Lesson 7: go.work and Workspace Mode — Developing multiple modules without replace hacks

Tue, 25 Feb 2025 00:00:00 +0000

Before go.work existed, developing across multiple local Go modules was genuinely painful. You were working on a library in one directory and an application that depended on it in another. Every time you changed the library, you had to add a replace directive to the application’s go.mod, run your tests, and then remember — always remember — to remove the replace before committing. I have seen replace directives committed to production go.mod files more times than I would like to admit.

Lesson 6: Dependency Direction — Always depend inward, never outward

Thu, 02 Jan 2025 00:00:00 +0000

We fixed cycles in lesson 2. But removing cycles is a necessary condition for good architecture, not a sufficient one. You can have a perfectly cycle-free dependency graph where every arrow points in the wrong direction, and the result is still a system that is painful to test, extend, and reason about.

Dependency direction is about more than just “does A import B.” It is about which layer owns the core business rules and which layers are allowed to know about which other layers. Get this wrong and your domain logic ends up tangled with your database driver. Get it right and you can replace your entire HTTP layer, or swap Postgres for a different store, without changing a single line of business logic.

Lesson 3: CQRS + Event Sourcing Together — When the combination makes sense

Sun, 24 Nov 2024 00:00:00 +0000

CQRS and event sourcing are often discussed together, presented as a single package, and that conflation is responsible for a lot of unnecessary complexity in codebases that should have stayed simple. I’ve seen teams adopt both because they read a blog post, without being clear on why they needed either. I’ve also seen teams who should have used both and instead built elaborate workarounds that were essentially CQRS and event sourcing with worse ergonomics. The question isn’t “should I use CQRS and event sourcing?” — it’s “do I have the specific problems these patterns solve?”

Lesson 5: Monolith vs Multi-Module — One go.mod or many? It depends.

Fri, 08 Nov 2024 00:00:00 +0000

When I first started structuring larger Go projects, I defaulted to what felt natural: one repository, one go.mod. It worked for a long time. Then I joined a project with four services in a single repo, each with different dependency requirements, and suddenly the single go.mod was pulling in every dependency of every service for every build. Tests for the email service were slow because the go test run was loading the ML inference library needed only by the recommendation service. That was when I started thinking seriously about module boundaries, not just package boundaries.

Lesson 4: Interface Placement — Define interfaces where they're used, not where they're implemented

Sat, 28 Sep 2024 00:00:00 +0000

This is the Go idiom that surprises people coming from Java or C# the most. In those languages, you define an interface in the same place as (or even before) the implementation, and consumers import the interface. Go’s approach is the exact opposite, and it takes a while to internalize why. Once it clicks, it changes how you think about dependencies fundamentally.

The rule is: define an interface in the package that needs it, not in the package that satisfies it. It sounds backwards. It is not. It is one of the most powerful design decisions the language enables.

Lesson 2: Projections and Read Models — Build any view from your event stream

Fri, 13 Sep 2024 00:00:00 +0000

After I shipped the event-sourced account system, the first question from the product team was: “Can we have a page that shows all accounts that have been dormant for more than 90 days?” In a traditional system, this is a query: SELECT * FROM accounts WHERE last_activity < NOW() - INTERVAL '90 days'. In event sourcing, there’s no last_activity column — there’s an event stream. My first instinct was to query the event store directly, find the latest event per stream, and filter. It worked. Then they asked for the top 100 accounts by balance. Then active accounts by geography. Then a real-time dashboard with all of the above simultaneously. Querying the event store for each of these is either very slow or very complex. The answer is projections — pre-computed read models built from your event streams.

Lesson 8: Technical Debt — When to pay, when to live with it

Fri, 23 Aug 2024 00:00:00 +0000

The term “technical debt” gets used to mean everything from “this code is a mess” to “we made a pragmatic shortcut we need to revisit” to “this system has grown organically and nobody understands it anymore.” These are different problems requiring different responses. Treating all technical debt as something that must be paid now, or all of it as something acceptable to defer indefinitely — both lead to bad outcomes. The skill is knowing which debt to address, when, and how.

Lesson 3: internal/ Usage Patterns — Compiler-enforced encapsulation

Sun, 18 Aug 2024 00:00:00 +0000

Go does not have access modifiers in the Java or Kotlin sense. There is no protected, no package-private, no friend classes. You get exactly two visibility levels: exported (capital letter) and unexported (lowercase letter). That simplicity is a feature. But it creates a gap: how do you share something across packages within your own module without accidentally exposing it to the outside world?

The answer is internal/. It is one of the most underused and underappreciated tools in Go’s package system, and it is enforced by the compiler itself.

Lesson 7: Migration Strategies — Strangler fig and feature flags

Wed, 07 Aug 2024 00:00:00 +0000

Rewrites are seductive. The existing system is messy, it’s slow to change, and the new system in your head is clean and fast and well-designed. Then you start the rewrite. Six months in, you’ve rebuilt 40% of the functionality and the remaining 60% is more complex than you thought. Meanwhile, the old system keeps shipping features. The new system falls behind, gets cancelled, and you’re back where you started, except now you’ve lost six months and the team is demoralized. I’ve seen this happen twice. The third time, we used the strangler fig pattern instead, and it worked.

Lesson 6: API Versioning — URL, header, or content negotiation

Wed, 24 Jul 2024 00:00:00 +0000

The first time I shipped a breaking change to a production API without a version, I got an incident at 2am because a partner integration stopped working. They’d been calling /api/orders for six months. I changed the response shape. Their code broke. That was when “API versioning” moved from “thing to do eventually” to “thing to do before you ship anything external.”

There’s no universally right answer to how you version APIs. There are tradeoffs, and the choice you make will shape your codebase for years. Here’s how I think about it.

Lesson 2: Avoiding Cyclic Dependencies — If packages import each other, your design is wrong

Fri, 12 Jul 2024 00:00:00 +0000

The Go compiler refuses to build a program with a cyclic import. It is not a warning. It is not a lint violation. It is a hard failure. I used to find this annoying when I was newer to the language. Now I consider it one of Go’s greatest gifts. The compiler is telling you something important: if package A needs package B and package B needs package A, you have not yet understood what the relationship between these two concepts really is.

Lesson 5: DDD Essentials — Bounded contexts and aggregates

Sun, 07 Jul 2024 00:00:00 +0000

The concept of “customer” meant something different in every team I talked to at one company. To the billing team, a customer was a billing account. To the support team, a customer was a person who filed tickets. To the identity team, a customer was an authenticated principal. Every team had their own Customer struct, and syncing them was a full-time job. That’s the problem DDD’s bounded context concept solves — and it’s one of those ideas that sounds academic until you’ve suffered without it.

Lesson 1: Event Store Design — Append-only logs that are your source of truth

Sat, 29 Jun 2024 00:00:00 +0000

My first encounter with event sourcing was a financial system that needed a complete audit trail. The business requirement was clear: every change to an account balance had to be traceable — who changed it, when, why. The first approach was an audit log table alongside the main accounts table. We’d write to both in a transaction. Within six months, the audit table was out of sync with the accounts table. Bugs in the dual-write logic, a migration that updated account records without touching the audit log, a direct database fix that bypassed the application layer. The audit log was nearly useless. The core insight I eventually arrived at: the audit log shouldn’t be a secondary record — it should be the primary record. That’s event sourcing.

Lesson 4: CQRS — When reads and writes need different models

Fri, 21 Jun 2024 00:00:00 +0000

I maintained an e-commerce admin dashboard that had a query so complex it took 12 seconds to run. It joined seven tables across the orders, inventory, and customers domains to build a summary view of “all orders pending fulfillment, with customer tier, item details, and warehouse stock levels.” Every time the admin loaded the page, twelve seconds. We tried indexes, caching, materialized views — all helped at the margins. The fundamental problem was that we were asking our write-optimized relational model to answer a read-optimized reporting question. Separating the read model was the only real fix.

Lesson 3: Event-Driven Architecture — Events vs commands

Tue, 04 Jun 2024 00:00:00 +0000

I used to use “event” and “command” interchangeably. A message is a message, right? Then I started debugging an event-driven system where the payment service was publishing ProcessPayment events, the order service was publishing CreateShipment events, and two teams were arguing about who owned the workflow. The problem was naming: they were publishing commands disguised as events. The distinction isn’t pedantic — it determines who owns the workflow and how the system evolves.

Lesson 1: Package Boundaries — One package, one responsibility, zero excuses

Mon, 03 Jun 2024 00:00:00 +0000

I have refactored a lot of Go codebases — my own included. And the single most common structural mistake I see is the utils package. Or helpers. Or common. Or sometimes the worst offender of all: a package named after the entire application domain with fifty unrelated files sitting inside it. When I first started writing Go seriously, I made all of these mistakes. This lesson is about why package boundaries matter and how to get them right.

Lesson 2: Clean Architecture — Not the textbook version

Sun, 19 May 2024 00:00:00 +0000

I’ve read the Clean Architecture book. I’ve also seen teams implement it so literally that they had six layers of indirection for a CRUD endpoint: a controller called a use case, which called a domain service, which called a port, which went through an adapter, which called a repository, which hit the database. Each hop had its own error mapping. Changing a database column required touching eight files. That’s not clean. That’s engineering theater.

Lesson 1: Monolith First — Starting with microservices is usually wrong

Fri, 03 May 2024 00:00:00 +0000

I’ve seen two teams start new products with microservices. One spent four months before they had anything deployed — Kubernetes setup, service discovery, distributed tracing, a CI/CD pipeline for twelve repos, and debates about how to split domains they hadn’t fully understood yet. They ran out of runway. The other team I worked on started with a monolith, shipped their first real user feature in three weeks, and only extracted services when the actual pain of growth made the benefit obvious. We’re still running that system, and it handles tens of millions of requests a day.