4.1 KiB
Architecture Trends (2026)
Use this reference when the user explicitly asks for "current" or "2026" guidance, or when the system design depends on ecosystem maturity (managed services, tooling, compliance, cost).
Platform Engineering and Internal Developer Platforms (IDPs)
Goal: reduce cognitive load and standardize delivery via self-service "golden paths".
Common building blocks:
- Service catalog and ownership (systems, components, dependencies)
- Templates/scaffolding ("paved roads") for new services and common workflows
- Self-service provisioning (IaC APIs, opinionated modules)
- Policy as code (security, compliance, FinOps guardrails)
- Built-in observability defaults (logs/metrics/traces, dashboards, alerts)
When to use:
- Multiple product teams with recurring platform needs
- Frequent service creation or consistent compliance requirements
- High operational overhead and inconsistent delivery practices
Avoid:
- Building a portal without paved roads (catalog without outcomes)
- Platform team as a ticket queue (no true self-service)
Data Mesh (Analytics and Data Product Architecture)
Goal: scale analytics by shifting ownership to domain teams and standardizing interoperability.
Core ideas:
- Domain-owned data products with SLAs (freshness, latency, schema stability)
- Federated governance (standards + tooling, not a central bottleneck)
- Contracts and versioning for schemas and semantic definitions
When to use:
- Cross-domain analytics is slowed by central data bottlenecks
- Multiple domains need to publish reliable datasets to many consumers
Avoid:
- Rebranding a data lake as data mesh without ownership and contracts
- Uncontrolled schema changes without consumer communication
Composable Architecture (Packaged Business Capabilities)
Goal: assemble business capabilities quickly via well-defined contracts.
Typical characteristics:
- API-first capability components with clear ownership
- Event-driven coordination for cross-capability workflows
- Composition layer (workflow engine, orchestration, or integration platform)
When to use:
- You need to rapidly combine capabilities across products or teams
- You have a stable set of reusable domain capabilities
Avoid:
- Tight coupling through shared databases or shared internal libraries
Continuous Architecture and Fitness Functions
Goal: keep architecture aligned with reality through automation and regular review.
Practices:
- "Just-enough" upfront design, iterate based on feedback and risk
- Fitness functions: automated checks that enforce architectural constraints (dependency rules, SLO budgets, cost gates)
- ADRs for irreversible tradeoffs, revisited when assumptions change
When to use:
- Any long-lived product where architectural drift is a risk
- Systems with explicit constraints (latency, compliance, cost)
Edge-First and Hybrid Edge/Cloud
Goal: meet latency, bandwidth, or offline requirements via local processing.
Common patterns:
- Edge caching and request shaping (CDN, edge gateways)
- Edge validation and filtering (reduce bandwidth to cloud)
- Hybrid pipelines (edge aggregation, cloud analytics and long-term storage)
When to use:
- Real-time UX needs, constrained networks, IoT/OT environments
Avoid:
- Splitting logic across edge/cloud without clear data ownership and observability
AI-Native System Architecture (RAG, Tools, Agents)
Use when LLMs are part of the product or internal platform.
RAG and tool patterns:
- Retrieval as a bounded subsystem (indexing, access control, evaluation)
- Tool gateway layer (rate limits, authZ, auditing, allowlists)
- Async orchestration for slow and failure-prone steps (queues, workflows)
Production requirements that are easy to miss:
- Evaluation and regression testing (golden sets, drift checks)
- Observability tailored to AI (prompt/response logging policy, safety filters, cost tracking)
- Security (prompt injection, data exfiltration, tool abuse, multi-tenant isolation)
Anti-patterns:
- Using a vector store as the source of truth for business data
- Shipping agents without termination conditions and without audit logs