Microservices patterns resurface
A widely shared thread distilled nine practical microservices patterns—Database‑per‑Service, Event Sourcing, API Gateway, Saga, BFF and others—while follow‑ups emphasised BFFs to avoid over‑fetching on mobile and the staff‑level need to master tradeoffs (e.g., Postgres vs DynamoDB, Kafka vs SQS). The conversation combined concrete patterns with guidance on sequencing ambiguous problems into actionable designs. (Shalini Goyal thread BFF discussion senior topics
Microservices are back in the timeline, but the discussion is less about splitting code and more about choosing a small set of patterns that keep distributed systems from drifting into chaos. A widely shared X thread from Shalini Goyal distilled nine patterns, including database per service, event sourcing, API gateway, saga and backend for frontend. (x.com) A microservice is a small application that owns one business job, like billing or inventory, and talks to other services over a network. The hard part is not the split itself; it is data ownership, request routing and what happens when one step fails halfway through a transaction. (martinfowler.com) (microservices.io) Database per service is the simplest example: each service owns its own data store and other services reach it through an application programming interface or events, not direct database queries. Microsoft’s architecture guidance says that isolation lets teams scale and change schemas independently, but it also makes cross-service consistency harder. (learn.microsoft.com) (microservices.io) That is where saga comes in. Instead of one big database transaction, a saga breaks a workflow into local transactions and uses follow-up actions to compensate if a later step fails, either through choreography with events or orchestration with a coordinator. (microservices.io) (docs.aws.amazon.com) Event sourcing solves a different problem by storing every state change as an event log, so a system can rebuild past state and explain how it got to the present. Martin Fowler’s long-running description of the pattern says the benefit is not just current state, but a record of every change in order. (martinfowler.com) On the request side, an API gateway gives clients one entry point instead of forcing a phone or browser to call dozens of backend services directly. Chris Richardson’s microservices.io describes the gateway as a single entry point that can route and compose requests across services. (microservices.io) (learn.microsoft.com) The follow-up discussion focused on backend for frontend, or BFF, which creates a separate backend for each client type, such as mobile and web. Microsoft’s pattern guide says teams use BFFs when one shared backend starts forcing different clients to accept the same payloads, the same latency profile and the same release cadence. (x.com) (learn.microsoft.com) That detail matters on mobile, where over-fetching means downloading fields and objects the screen never uses, and chatty networks mean too many round trips over slow connections. Microsoft’s recent Azure community post on curated APIs lists over-fetching and chatty calls as two common reasons teams add a BFF layer. (techcommunity.microsoft.com) (x.com) Another strand of the conversation moved from patterns to judgment: staff-level engineers are expected to pick the right tradeoff, not recite a catalog. That means knowing when PostgreSQL fits transactional data better than DynamoDB, or when Apache Kafka’s event stream is solving a different problem from Amazon Simple Queue Service, which is a managed message queue. (x.com) (aws.amazon.com) The thread’s staying power came from sequencing. Instead of jumping from a vague prompt to a finished architecture, it walked from problem shape to pattern choice to infrastructure choice — the kind of step-by-step design work that turns “use microservices” from a slogan into an actual system. (x.com 1) (x.com 2)
