Every Software Architecture Pattern Explained (Micro-Frontends, BFF, API Gateway, Event Driven)

Summary

The video surveys software architecture styles, explaining what each is intended to solve, its tradeoffs, and how systems might evolve as they grow. Its recurring advice is to start with the simplest architecture that works: more distributed or specialized designs can help at scale, but they also add operational and development complexity.

Architecture Styles and Components

• Monolithic architecture and layered/MVC design

  • A monolith keeps the frontend, backend, and business logic together on one server, typically with the database deployed separately.
  • In a traditional MVC application, a request reaches a controller, which uses a model to retrieve data and creates a view—often pre-rendered HTML.
  • With single-page applications, the frontend is separated from the backend and communicates with it through an API. The video mentions REST, GraphQL, and gRPC, describing REST as a straightforward option and GraphQL as useful when clients need different subsets of data.

• Modular monolith

  • A monolith can be divided into modules with clear boundaries, limited context, and defined public APIs.
  • This helps teams work in parallel and makes code easier to extend and maintain, while the application is still deployed as one system.
  • Modules can be reflected in how data is organized. Shared capabilities, such as sending email, can be encapsulated behind an internal service.
  • The limitation is that modules still share the same overall deployment and can remain vulnerable to system-wide failures or scaling bottlenecks.

• Microservices

  • A modular backend can be split into independent services, each with its own API, server, and potentially its own database or runtime.
  • This allows services to scale or change independently and can reduce the impact of a failure in one service.
  • The costs include more infrastructure, deployments, and operational work. Network calls also introduce latency, and coordinating transactions across services makes strong consistency harder and slower.

• API gateway

  • An API gateway provides a controlled entry point to services, which may be kept inside a private network.
  • It can centralize concerns such as HTTPS, authentication, security, and rate limiting, rather than requiring each service to implement them.
  • This reduces repeated work for service teams, but it is another infrastructure component.

• Backend for the frontend (BFF)

  • Different clients—such as web, mobile, and back-office applications—often need different data and API behavior.
  • A dedicated BFF for each interface can shape responses for that client. The video gives a web BFF exposing GraphQL as an example.
  • A BFF can let frontend teams manage interface-specific API needs while backend teams focus on service logic. It can also combine backend requests for the client.
  • Tradeoffs include maintaining more infrastructure and adding a network hop, though the presenter notes that GraphQL queries can be parallelized and cached.

• Distributed logging and tracing

  • In a service-based system, requests may cross many services, making failures hard to locate across scattered logs.
  • The suggested approach is to use distributed logging and tracing with a correlation ID attached to the request and propagated through each service.
  • Prometheus and Grafana, as well as Datadog, are mentioned as example tools.

• Micro-frontends

  • A frontend can be split into independently developed and deployed applications that are brought together by a shell.
  • The shell can manage shared state such as authentication, theme, and language settings.
  • A shared design system, CSS, and UX patterns help keep separate applications consistent.

• Event-driven architecture

  • Services communicate by publishing events to a broker and subscribing to events they need to handle.
  • For example, an order service can publish an “order created” event; inventory, email, and analytics services can react to it and may publish further events.
  • This makes it easier to add services and lets teams work more independently. A newly added consumer may also be able to process historical events, as described in the Kafka example.
  • The tradeoff is eventual consistency: updates take time to propagate, so users may need real-time status updates. The video mentions polling, server-sent events, WebSockets, and GraphQL subscriptions as ways to provide those updates.
  • Event structure and access control matter: events should be well-defined, and access to protected events should be controlled.

• Hexagonal, onion, and clean architecture

  • These styles aim to make dependencies point inward, toward the core business domain, instead of letting business logic depend directly on infrastructure.
  • The domain contains core concepts and rules; application operations use that domain; external adapters connect it to interfaces, APIs, databases, or events.
  • Because infrastructure is kept at the edges, changing a controller or database can require fewer changes to core business logic.
  • The presenter describes hexagonal, onion, and clean architecture as variations on this dependency principle, and cautions that a simpler layered design may be sufficient for many services.

• CQRS (Command Query Responsibility Segregation)

  • CQRS separates write operations (commands) from read operations (queries).
  • A command might write an order to Postgres and emit an event; a projector can prepare a separate read model, such as one stored in Elasticsearch.
  • This can help when read and write workloads differ substantially or reads need to scale independently.
  • The tradeoff is added complexity and potentially stale read results while the read model catches up.

AI-Era Architectures

• Zero-token architecture

  • The example is classifying order events with an LLM. Calling a model for every event can be costly and slow, and reprocessing events can incur repeated costs.
  • The proposed method is:
    1. Use an LLM to analyze cases and generate classification rules.
    2. Apply those static, deterministic rules to routine events in production.
    3. Send only cases the rules cannot classify to the LLM.
    4. Use the LLM’s handling of exceptions to refine the rules.
  • The aim is to reserve model calls for unusual cases and use predictable code for routine work.

• Agent architecture

  • An agent is described as a loop that receives a request, consults a model, and continues until it reaches a stopping condition.
  • It builds model context from memory, session information, tools, skills, and MCP.
  • If the model requests a tool, the agent’s surrounding system runs it, adds the result to context, and calls the model again.

• Multi-agent supervisor pattern

  • A supervisor agent classifies a task and delegates suitable work to specialized agents.
  • Specialized agents have narrower context and task-specific tools. The supervisor receives their results rather than the full working context.
  • This can help limit context overload, though the presenter notes that AI architecture practices are still developing.

• Microkernel architecture

  • A small core exposes lifecycle hooks that plugins can use to extend or modify application behavior.
  • The style is suited to applications intended to be extended by installable plugins. Linux, VS Code, and “Cloud Code” (possibly an auto-caption rendering of Claude Code) are mentioned as examples.

Overall Lesson

Architecture choices involve tradeoffs among simplicity, scalability, independence, consistency, latency, and operational burden. The video presents modularity and distribution as responses to growing complexity, but emphasizes that each additional layer or service creates work. Use more elaborate patterns when the system’s actual needs justify them.

Speakers and Sources Featured

• Speaker: One narrator/presenter; no guest speakers or interviewees are heard. The subtitles do not identify the presenter by name.
• Named technologies and examples referenced: Ruby on Rails, Django, ASP.NET, React, Vue, Angular, REST, GraphQL, gRPC, Prometheus, Grafana, Datadog, Kafka, Postgres, Elasticsearch, Anthropic, OpenAI, Claude, Linux, and VS Code. The subtitles also mention Claude MD, memory MD, and MCP in the agent discussion.