121 lines
4.1 KiB
Markdown
121 lines
4.1 KiB
Markdown
# 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
|
|
|