🏗️ Reading: Engineering Blog — Monolith to Microservices

Service boundary selection — one of the hardest microservices decisions

The blog post gives a clear engineering rationale for not extracting certain domains: "extracting these would have required cross-service transactions that our team wasn't ready to handle."

Why authentication and billing are hard to extract:

• Authentication is a cross-cutting concern — nearly every service needs to verify user identity. As a separate service, every API call might require a synchronous call to an auth service. If the auth service is slow or down, everything is slow or down.
• Billing involves financial transactions that must be atomic: debit account + update subscription + send receipt must all succeed or all fail together. Distributed transactions across services are notoriously difficult to implement correctly (two-phase commit, saga pattern) and introduce failure modes that don't exist in a monolith.
• User management is another cross-cutting concern — user IDs and profile data are referenced by nearly every other service. Without careful API design, extracting this creates tight coupling between services.

The principle behind "clear boundaries": The two extracted services (notifications, reporting) had well-defined, narrow interfaces: "send notification given these parameters" and "generate this report from this data." They could fail without breaking core flows. They didn't require coordinated state changes with other parts of the system.

Key vocabulary from the passage:

• "Fail independently" → a service failure doesn't cascade to other services (fault isolation)
• "Well-defined interfaces" → clear input/output contracts, not entangled with other domain logic
• "Cross-service transactions" → operations that must atomically span multiple services — a core microservices challenge

The hidden costs of microservices — a critical balance to understand

One of the most important engineering blog post reading skills is recognising the honest trade-off disclosures. This post is unusually candid about what the migration cost them.

Breaking down each term in the list:

• Distributed tracing: In a monolith, a single request produces a single stack trace. In microservices, a single user request might span 5 services, and diagnosing a 500ms latency spike requires tracing the call chain across all of them. Tools: Jaeger, Zipkin, Honeycomb, Datadog APM. These require instrumentation across all services and correlation of trace IDs in logs.
• Inter-service authentication: Services calling other services need to prove their identity. In a monolith, a function call is trusted by definition. In microservices, you need mutual TLS, JWTs, service accounts, or API keys — and a system to manage and rotate them.
• Retry logic: Network calls fail. Services need idempotency guarantees (retrying a payment operation must not charge twice), circuit breakers (stop hammering a failing downstream service), and backoff strategies. None of this was needed for in-process function calls.
• Observability across a heterogeneous fleet: "Heterogeneous fleet" means services in different languages, frameworks, runtimes. Getting consistent logs, metrics, and traces from all of them requires standardisation effort that a single-language monolith doesn't need.

The key takeaway for the IT English learner: When an engineering blog post lists what went wrong or what was harder than expected, pay close attention — these sections are the most honest and educational parts of the post. The "what we'd do differently" section especially is where the real engineering wisdom lives.

The strangler fig pattern — a classic software architecture term

The name comes from a type of tropical plant: strangler figs grow around a host tree, gradually taking over its structure. Eventually the original tree rots away, leaving only the fig. Martin Fowler popularised this as a software migration pattern.

How it works in a migration context:

1. The existing monolith continues serving production traffic normally
2. A new service is built alongside it, handling one specific domain or feature
3. Traffic for that domain is gradually redirected to the new service (often via a reverse proxy or feature flag)
4. Once the new service handles 100% of that traffic reliably, the monolith code for that domain is deleted
5. Repeat for the next domain until the monolith is empty and can be retired

Contrast with "big-bang extraction" (what the post says they did, and wouldn't do again):

• Big-bang: pause feature development, extract everything at once, hope it works
• Strangler fig: continuous incremental migration, always deployable, reversible

Why the post recommends strangler fig: The phrase "it lets you migrate incrementally while the monolith continues to serve production traffic" is the key — you never have a moment where you've stopped the old thing but the new thing isn't ready yet. Incremental approaches reduce risk.

Reading blog post recommendations critically: The post says "we would recommend" — this is retrospective advice based on their specific pain points. The strangler fig adds its own complexity (routing layer, running two codebases simultaneously). For a very small team with a small codebase, a thoughtful big-bang might be simpler. Always evaluate patterns against your specific context.

Other related vocabulary in the passage: "Contract testing" (verifying that API consumers and producers agree on the interface format) and "regression" (a bug introduced by a change that breaks previously working functionality) are both important terms used precisely here.