Architecture
115 items tagged with "architecture"
Best Practices28
Production-Ready Micro-services Checklist
A checklist covering operability, reliability, deployability, and observability of micro-services.
Zero Trust Architecture Principles (NIST SP 800-207)
Conceptual zero-trust model: continuous verification, least privilege, assume breach.
CQRS (Command Query Responsibility Segregation)
An architecture pattern that separates the model that writes data (commands) from the model that reads it (queries), allowing each side to scale and evolve independently.
Event Sourcing
An architecture pattern that stores every change to application state as an immutable sequence of events, making the event log the source of truth instead of current state.
Saga Pattern
A pattern for managing data consistency across microservices using a sequence of local transactions coordinated by events or a central orchestrator, with compensating actions on failure.
Circuit Breaker Pattern
A resilience pattern that stops calls to a failing dependency once errors cross a threshold, preventing cascading failures and giving the dependency time to recover.
Bulkhead Pattern
A resilience pattern that isolates resources into separate pools so a failure or overload in one part of a system cannot consume the resources others depend on.
Backends for Frontends (BFF)
An architecture pattern that gives each frontend client its own tailored backend service, instead of forcing web, mobile, and other clients to share one general-purpose API.
API Gateway Pattern
An architecture pattern that places a single entry point in front of backend services to handle routing, authentication, rate limiting, and other cross-cutting concerns.
Sidecar Pattern
A design pattern that deploys a helper component alongside the main application in the same unit, adding capabilities like proxying, logging, or config without changing the app.
Cell-Based Architecture
An architecture that partitions a system into independent, self-contained cells, each serving a subset of traffic, to limit blast radius and scale through replication.
Hexagonal Architecture (Ports and Adapters)
An architecture that isolates core application logic behind ports, with adapters connecting external concerns like databases and UIs, so the core stays independent of technology.
Domain-Driven Design (DDD)
A software design approach that models complex business domains in code, using a shared language and bounded contexts to align software structure with the business it serves.
Modular Monolith
An architecture that keeps a single deployable application but enforces strong internal module boundaries, capturing many microservices benefits without distributed-system complexity.
Retrieval-Augmented Generation (RAG) Best Practices
RAG grounds a large language model in external documents retrieved at query time, reducing hallucination and letting answers reflect current, private data without retraining the model.
Model Context Protocol (MCP)
The Model Context Protocol is an open standard that lets AI applications connect to external tools and data sources through a uniform client-server interface.
AI Agent Design Patterns
AI agent design patterns are reusable structures for LLM systems that plan, use tools, and act over multiple steps, covering reflection, tool use, planning, and multi-agent collaboration.
Richardson Maturity Model
A four-level model for grading how fully an HTTP API embraces REST, from RPC-style endpoints up to hypermedia controls (HATEOAS).
GraphQL API Best Practices
Practical guidance for designing GraphQL schemas and servers: typed schemas, pagination, error handling, query cost limits, and avoiding the N+1 problem.
gRPC Best Practices
Guidance for building high-performance gRPC services with Protocol Buffers: service design, streaming, deadlines, error codes, and backward-compatible schema evolution.
API-First Design
An approach that treats the API contract as a product designed before implementation, so teams agree on the interface, then build clients and servers in parallel.
AsyncAPI Specification
A standard, machine-readable format for describing event-driven and message-based APIs across protocols like Kafka, MQTT, and AMQP, analogous to OpenAPI for REST.
Atomic Design
A methodology by Brad Frost for building UI from five composable levels: atoms, molecules, organisms, templates, and pages, giving design systems a consistent structure.
Design Systems
A design system is a single source of truth combining reusable components, design tokens, patterns, and guidelines that keep products consistent and faster to build.
Micro-Frontends
An architecture that splits a web app into independently developed and deployed frontend pieces owned by separate teams, then composes them into one experience.
Team Topologies
Team Topologies is a model for organizing business and technology teams using four team types and three interaction modes to optimize fast flow and reduce cognitive load.
Architecture Decision Records (ADRs)
An Architecture Decision Record (ADR) is a short, version-controlled document that captures one significant architectural decision, its context, and its consequences for future maintainers.
C4 Model for Software Architecture
The C4 model is a lean, hierarchical way to diagram software architecture at four levels of abstraction: System Context, Containers, Components, and Code.
Patterns23
Saga Pattern
Manage data consistency across microservices using a sequence of local transactions with compensating actions
API Gateway
A single entry point that routes, aggregates, and secures client requests across many backend microservices.
Service Registry
A database of available service instances and their network locations, kept current as instances start, stop, and fail.
Service Discovery
A mechanism for clients to find the current network location of a service without hard-coding addresses.
API Composition
Implements a query that spans multiple services by invoking each owner service and joining the results in memory.
Aggregator
A component that invokes multiple services and combines their responses into a single consolidated result for the caller.
Choreography
Coordinates a distributed workflow through services reacting to each other's events, with no central controller.
Orchestration
Coordinates a distributed workflow through a central orchestrator that explicitly invokes each service in sequence.
Message Channel
Connects two applications with a logical pipe so a sender can transmit data to a receiver without knowing the receiver's location or identity.
Polyglot Persistence
An architecture that uses multiple, purpose-fit data stores within one system, matching each store's strengths to each data access pattern.
Command Query Responsibility Segregation (CQRS)
Separates the write model that handles commands from the read model that serves queries, letting each be optimized, scaled, and evolved independently.
Event-Driven Architecture
An architectural style where components communicate by producing and reacting to events, enabling loose coupling, asynchronous flow, and independent scaling.
Lambda Architecture
A big-data design that runs a batch layer for accurate historical views and a speed layer for low-latency recent data, merging both at query time.
Kappa Architecture
A streaming-first data design that uses a single processing path over an immutable log, reprocessing history by replay instead of a separate batch layer.
Medallion Architecture
A lakehouse data-organization pattern that refines data through bronze (raw), silver (cleaned), and gold (curated) layers for progressive quality and reuse.
Data Lakehouse
A data architecture that adds warehouse-style ACID tables, schema, and governance directly on low-cost data-lake storage, unifying analytics and ML on one platform.
Model-View-Controller (MVC)
Separates an application into a model (data and rules), a view (presentation), and a controller (input handling), decoupling concerns for maintainability.
Model-View-ViewModel (MVVM)
Separates UI from logic via a view-model that exposes bindable state and commands, with two-way data binding keeping the view and view-model in sync.
Micro Frontend
Decomposes a web frontend into independently developed and deployed pieces owned by separate teams, then composes them into one application at runtime or build time.
Island Architecture
Renders a page as mostly static HTML with isolated interactive 'islands' that hydrate independently, minimizing JavaScript shipped to the browser.
Defense in Depth
Layers multiple independent security controls so that if one fails, others still protect the system, avoiding reliance on any single defense.
Secure by Default
Systems ship with the most secure configuration out of the box, requiring deliberate action to reduce security rather than to enable it.
Zero Trust Segmentation
Eliminates implicit network trust by authenticating and authorizing every request and dividing the network into fine-grained, individually protected segments.
Anti-Patterns30
Distributed Monolith
Splitting a monolith into microservices that are still tightly coupled and must be deployed together
Golden Hammer
Using a familiar technology for every problem regardless of fit
God Object
A single class or module that knows or does too much, concentrating most of the system's responsibilities in one place and becoming a maintenance bottleneck.
Big Ball of Mud
A system with no discernible architecture, where code is haphazardly structured, tangled, and duct-taped together, making every change risky and slow.
Accidental Complexity
Complexity introduced by the solution rather than the problem — overbuilt tooling, layers, and abstractions that obscure logic that is actually simple.
Vendor Lock-In
Designing a system so deeply around one provider's proprietary services that switching becomes prohibitively expensive, eroding negotiating power and portability.
Inner-Platform Effect
Building a configurable system so general it becomes a poor reimplementation of the platform it runs on, reinventing a language, database, or framework badly.
Stovepipe System
Independently built, siloed systems that duplicate capabilities and cannot interoperate because each was designed in isolation without shared standards.
Swiss Army Knife
An interface or component with so many options and overloads that it tries to cover every use case, becoming hard to learn, misuse-prone, and impossible to evolve.
Magic Pushbutton
Putting business logic directly in UI event handlers, so a single button click handler holds validation, rules, and persistence with no separation of concerns.
Reinventing the Wheel
Building from scratch a solved, well-supported capability — like crypto, date handling, or an ORM — instead of using a proven, maintained library or standard.
Boat Anchor
Keeping a piece of obsolete software, hardware, or a dependency that no longer serves a purpose but is retained and maintained out of inertia or sunk-cost thinking.
Dependency Hell
A tangle of conflicting, version-pinned, or transitive dependencies that makes upgrading or even installing software fragile, slow, and unpredictable.
Circular Dependency
Two or more modules that depend on each other directly or transitively, forming a cycle that prevents independent building, testing, and reasoning.
Leaky Abstraction
An abstraction that fails to fully hide its underlying implementation, forcing callers to understand and depend on the details it was meant to encapsulate.
Anemic Domain Model
Domain objects that hold data but no behavior, with all logic pushed into separate service classes, draining the object model of its purpose.
Fat Controller
Web or API controllers that accumulate business logic, validation, and data access instead of delegating, becoming bloated and impossible to test or reuse.
Smart UI
Concentrating business logic, data access, and rules inside the presentation layer, fusing UI and domain so neither can change or be tested independently.
Over-Engineering
Building more generality, flexibility, or sophistication than the problem requires, adding cost and complexity for capabilities that are never actually needed.
Premature Abstraction
Extracting abstractions before enough concrete cases exist to know what they should be, locking in the wrong shape and adding indirection that obstructs change.
Nanoservices
Splitting a system into services so small that coordination, network, and operational overhead vastly exceed the value of each tiny service.
Entity Service
Designing microservices around data entities rather than business capabilities, forcing every workflow to orchestrate chatty calls across CRUD-only services.
Spaghetti Code
Code with tangled, unstructured control flow and no clear modularity, where execution jumps unpredictably and dependencies are impossible to follow.
Premature Scaling
Building for massive scale before there is load to justify it, paying the cost and complexity of distributed systems to solve problems the product does not yet have.
Big Design Up Front (BDUF)
Specifying a complete, detailed design before any implementation begins, betting that requirements are fully known and will not change.
Resume-Driven Development
Choosing technologies for their appeal on a resume or their hype rather than their fit for the problem, optimizing careers over systems.
Nanoservices (Overly Fine-Grained Services)
Splitting a system into so many trivially small services that coordination, network, and operational overhead dwarf any benefit of separation.
Synchronous Call Chains
Deep chains of blocking request-response calls between services, so latency compounds and one slow or failed service cascades into widespread failure.
Entity Services
Decomposing microservices around data entities (CRUD wrappers per table) rather than business capabilities, creating chatty, anemic, tightly coupled services.
Death Star (Distributed Big Ball of Mud)
A microservice estate where every service calls nearly every other with no clear boundaries, producing a tangled mesh impossible to change or reason about.
Tutorials4
Building Event-Driven Systems with Kafka
Create scalable event-driven architectures using Apache Kafka
Find Architectural Hubs with vg hubs
Use vg hubs to surface the most-depended-on nodes in your codebase — the high-leverage modules where changes ripple the furthest.
Detect Architectural Smells with vg oddities
Use vg oddities to surface surprising cross-area links in your code graph — the unexpected dependencies that signal architectural smells.
Discover Natural Code Groupings with vg areas
Use vg areas to reveal the natural communities in your codebase — clusters of tightly related modules that map to features and subsystems.
Blueprints2
Reference Architectures3
Event-Driven Microservices
Architecture pattern for building loosely-coupled microservices using event sourcing and CQRS
Monolith to Microservices Migration
Step-by-step architecture for decomposing monolithic applications into microservices
ML Platform Architecture
End-to-end machine learning platform for training, deploying, and monitoring models
Playbooks2
FAQs7
What are native module warnings?
Native module warnings indicate your project depends on packages that compile native code (e.g., sharp, bcrypt, node-gyp). These can cause issues when...
What is an API gateway?
An API gateway is a server that sits in front of one or more backend services and acts as a single entry point for clients. It handles cross-cutting c...
What is a microservice?
A microservice is a small, independently deployable service that owns a single business capability and communicates with other services over the netwo...
Monolith vs microservices: which should I choose?
A monolith packages all functionality into a single deployable unit, which keeps development, testing, and deployment simple and is usually the right ...
What is Domain-Driven Design (DDD)?
Domain-Driven Design (DDD) is an approach to building software that puts the business domain and its language at the center of the design. It encourag...
What is event-driven architecture?
Event-driven architecture is a style where components communicate by producing and reacting to events—records that something happened—rather than call...
What is the Twelve-Factor App methodology?
The Twelve-Factor App is a set of principles for building cloud-native, portable, and scalable software-as-a-service applications. Key factors include...
Glossaries14
Microservices
An architectural style structuring an application as a collection of loosely coupled, independently deployable services
API Gateway
A server that acts as a single entry point for API calls, handling routing, composition, and cross-cutting concerns
Container
A container is a lightweight, isolated unit that packages an application together with its dependencies and runs as an isolated process on a shared host operating system kernel.
Pod
A pod is the smallest deployable unit in Kubernetes, consisting of one or more tightly coupled containers that share a network namespace, storage volumes, and lifecycle.
StatefulSet
A StatefulSet is a Kubernetes controller for stateful applications that provides pods with stable, unique identities, ordered deployment and scaling, and persistent per-pod storage.
Control Plane (Kubernetes)
The control plane is the set of Kubernetes components that manage the cluster's overall state, making global decisions such as scheduling and responding to events to drive the cluster toward its desired state.
Data Lakehouse
A data lakehouse is an architecture that combines the low-cost, flexible storage of a data lake with the management, transactions, and performance of a data warehouse, using open table formats over object storage.
Transformer
A transformer is a neural network architecture built around self-attention that processes sequences in parallel, forming the basis of modern large language models.
Defense in Depth
Defense in depth is a security strategy that layers multiple, independent controls so that if one defense fails, others continue to protect the system.
Monolith
A monolith is an application built and deployed as a single, unified unit, where all functionality runs in one process or codebase rather than being split into independent services.
Modular Monolith
A modular monolith is a single deployable application whose internal code is organized into well-isolated modules with explicit boundaries, combining a monolith's simple operations with microservice-style separation of concerns.
Domain-Driven Design
Domain-driven design (DDD) is a software design approach that models software closely on the business domain, using a shared language between developers and domain experts and organizing the system around bounded contexts.
CQRS (Command Query Responsibility Segregation)
CQRS is a pattern that separates the model used to change data (commands) from the model used to read data (queries), allowing each side to be optimized, scaled, and evolved independently.
Event Sourcing
Event sourcing is a pattern that stores the full history of changes to application state as an immutable sequence of events, reconstructing current state by replaying those events rather than storing only the latest snapshot.