Make trade-offs explicit
Good architecture is not a diagram. It is a set of intentional decisions across risk, cost, reliability, security, delivery speed and team maturity.
C4 modelADRsSADsWell-Architected reviews
Architecture Playbook
How I reason about senior architecture
A practical, senior-level material for regulated and high-impact systems: AWS Well-Architected thinking, cloud modernization, distributed data, event-driven integration, GenAI guardrails, DevSecOps, observability and business-aligned decisions.
Design for regulated operations
Financial systems need architecture that keeps auditability, identity, data protection, resilience and operational readiness visible from day one.
Zero TrustIAM/KMS/WAFPCI-DSSLGPD
Prefer evolutionary modernization
Modernization works best when domain boundaries, platform capabilities and migration increments reduce risk while keeping business value moving.
DDDBFFmicroservicesevent-driven integration
Use AI with guardrails
AI must be useful, observable and bounded. Abuse protection, cost controls, privacy posture and fallback behavior are part of the architecture.
BedrockRAGrate limitsS3 telemetry
Well-Architected
Operating model across the six pillars
I use the pillars as a decision lens, not as a checklist. The goal is to expose trade-offs early and make the system easier to operate, secure, recover and evolve.
Operational excellence
Architecture should make change safe: telemetry, runbooks, IaC, rollback paths and learning loops after incidents.
SLOs and error budgetsADRs and runbooksCI/CD controlspost-incident learning
Security
Identity, network boundaries, data protection and threat modeling must be design inputs, especially in financial environments.
least privilege IAMKMS and secretsWAF and rate limitsaudit trails
Reliability
Systems should degrade gracefully, isolate failure and prove recovery targets before production pressure arrives.
RTO/RPOmulti-AZ designidempotencybackoff and circuit breakers
Performance efficiency
Pick compute, storage and integration patterns from workload shape, latency needs, access patterns and team maturity.
load testingcachingasync flowsright-sized data stores
Cost optimization
Cost is an architecture signal. Good systems expose unit economics, limits, quotas and waste early.
taggingbudgetsstorage lifecycleserverless where it fits
Sustainability
Efficient architectures reduce idle capacity, unnecessary data movement and retention that no longer creates value.
managed servicesdata retentionright-sizingefficient workloads
Patterns
Patterns I use with care
Patterns are useful only when the context, trade-offs and failure modes are explicit.
Event-driven banking integration
Best for
Decoupling domains, reducing synchronous dependencies and enabling auditable business events.
Watch-out
Without schema discipline and observability, event-driven systems become distributed uncertainty.
Kafka/MSKEventBridgeSchema RegistryOpenTelemetry
BFF plus microfrontend boundaries
Best for
Digital channels that need independent evolution, clear ownership and UX-specific APIs.
Watch-out
BFFs should protect product flows, not become another shared monolith.
NestJSNext.jsReactClean Architecture
Serverless control plane
Best for
Low-ops workflows, scheduled automation, AI pipelines, newsletters and event-driven background jobs.
Watch-out
Cold starts, retries, idempotency and IAM scoping still need deliberate design.
LambdaDynamoDBS3EventBridge
AI assistant with retrieval
Best for
Explaining domain knowledge, professional profiles, internal knowledge bases and decision support.
Watch-out
Treat prompt injection, data leakage, runaway cost and hallucination as architecture risks.
Amazon BedrockTitan embeddingsRAGDynamoDB limits
Observability-first services
Best for
Microservices and distributed teams that need fast diagnosis, reliability learning and SLO conversations.
Watch-out
Dashboards do not create reliability unless traces, logs, metrics and ownership are connected.
OpenTelemetryDatadogCloudWatchSLOs
GitOps and IaC delivery
Best for
Reducing drift, improving reviewability and aligning infrastructure changes with engineering flow.
Watch-out
Automation without policy and rollback strategy can accelerate mistakes.
TerraformGitHub ActionsArgoCDAWS CDK
AWS decisions
Decision domains I keep explicit
Senior architecture is choosing with context: workload shape, domain boundaries, compliance, operability, reversibility and cost behavior.
Compute and containers
Lambda, ECS/Fargate, EKS, EC2 and Batch should be selected by runtime profile, operational model, latency, portability and deployment cadence.
Lambda for event control planes
ECS/Fargate for service teams
EKS for platform-scale Kubernetes
Data and storage
Start from access patterns, consistency, retention, analytical needs and ownership. The database choice is a product and architecture decision.
DynamoDB single-table design
Aurora for relational domains
S3 lakehouse and lifecycle
Integration and streaming
Prefer clear contracts between domains. Choose orchestration, choreography, queues or streams according to ordering, replay, fanout and audit needs.
EventBridge for domain events
SQS for buffering
MSK/Kinesis for high-volume streams
Security and governance
Security architecture should be measurable: identity boundaries, encryption, detective controls, policy-as-code and evidence for audits.
Organizations and SCPs
CloudTrail and Config
Security Hub and GuardDuty
AI, data products and GenAI
AI workloads need evaluation, abuse controls, privacy boundaries, model choice, vector strategy and cost guardrails before scaling usage.
Bedrock guardrails
RAG evaluation
token budgets and throttling
Observability and operations
Logs, metrics, traces and business events must connect technical health to product impact and incident response.
OpenTelemetry
CloudWatch
Datadog
dashboards tied to SLOs
Senior material
Capability map for modern solution architecture
The material I want my work to communicate: technical depth, cloud judgment, data reasoning, AI safety, platform thinking and strong stakeholder communication.
Architecture foundations
Architectural characteristics, styles, trade-offs, diagrams, ADRs, governance and communication with engineering and business stakeholders.
Fundamentals of Software ArchitectureSoftware Architecture: The Hard Parts
Distributed data systems
Consistency, replication, partitioning, event logs, storage engines, schemas, data products and the consequences of distributed ownership.
Designing Data-Intensive ApplicationsData Meshevent sourcing and streaming
AWS cloud-native architecture
Well-Architected thinking, decision guides, reference architectures, migration increments, resilience patterns and cost-aware service selection.
AWS Well-Architected FrameworkAWS Architecture CenterSystem Design on AWS
Modernization and platform engineering
Evolutionary architecture, paved roads, GitOps, Terraform/CDK, CI/CD, golden paths, developer experience and operational maturity.
Building Evolutionary ArchitecturesCloud Application Architecture Patterns
AI and intelligent systems
RAG, agents, Bedrock, evaluation, prompt-injection defense, rate limits, observability, MLOps/AIOps and human-in-the-loop operations.
AWS for Solutions ArchitectsBedrock patternssecure AI architecture
Library
Reading roadmap and reference stack
A pragmatic order for growing from software architecture fundamentals into AWS system design, data-intensive systems, cloud patterns and evolutionary governance.
1. Foundation
Fundamentals of Software Architecture, 2nd Edition
Builds the base for styles, architectural characteristics, trade-off analysis, diagrams, governance and the daily work of an architect.
2. Trade-offs
Software Architecture: The Hard Parts
Deepens the difficult decisions around service boundaries, coupling, distributed data, granularity and the cases where there is no perfect answer.
3. Data-intensive systems
Designing Data-Intensive Applications, 2nd Edition
Strengthens reasoning about storage, consistency, replication, streams, scalability and data architecture for large systems.
4. Cloud patterns
Cloud Application Architecture Patterns
Connects cloud-native patterns, modernization and migration with practical application architecture independent of a single provider.
5. AWS practice
AWS Well-Architected, AWS for Solutions Architects and System Design on AWS
Turns system design into AWS decisions across reliability, security, performance, cost, sustainability, GenAI, MLOps and platform operations.
6. Evolution
Building Evolutionary Architectures, Building Microservices and Designing Distributed Systems
Adds fitness functions, service evolution, Kubernetes-oriented patterns and pragmatic modernization of complex systems over time.
Decision questions
What business risk does this architecture reduce?
Where are the domain boundaries and who owns them?
What fails closed, what fails open and what degrades gracefully?
How do we prove security, reliability and cost posture after deploy?
Which decision is reversible, and which one creates long-term coupling?
What telemetry will help the team learn from production?
Source inspiration
This page synthesizes my own architecture point of view with public AWS architecture references and the architecture library I am using as a study map.