- Architecture is a change in scope of thinking, not a move away from engineering.
- Strong architects understand implementation deeply enough to challenge unrealistic diagrams and estimates.
- Learn NFRs, distributed systems, cloud, observability and failure modes before memorizing technology lists.
- Architecture communication—HLD, ADRs, sequence diagrams and trade-off records—is part of the engineering work.
- The transition becomes real when you can improve the decisions of an entire team, not only your own code.
Developers often ask me which technology they should learn to become a Solution Architect. My answer is that architecture is not another framework. It is a change in the level at which you think about technology.
A developer is often responsible for making a component work. An architect has to think about whether the entire system will continue working when traffic increases, dependencies fail, teams change, requirements evolve, security threats appear, deployments fail and budgets become constrained.
Stage 1: Become technically strong first
Do not rush away from coding. The strongest architects I have worked with understand implementation deeply enough to recognize when a beautiful diagram is unrealistic. You should be strong in at least one backend ecosystem—Java/Spring Boot or Node.js/NestJS are good examples—and understand frontend and data architecture well enough to evaluate end-to-end trade-offs.
You do not need to be the best developer in every technology. You do need to understand what your decisions will cost the engineers who must implement and operate them.
Stage 2: Learn databases beyond CRUD
Move beyond schema creation and ORM usage. Learn indexes, transactions, isolation levels, locks, replication, partitioning, connection pools, execution plans, normalization and denormalization.
Stop asking “Which database is best?” and start asking “Which consistency, query and operational behavior does this workload need?”
Stage 3: Learn distributed systems
This is where architectural thinking changes significantly. Understand timeouts, retries, circuit breakers, idempotency, eventual consistency, distributed transactions, SAGA, outbox, CQRS, message ordering, backpressure and rate limiting.
If service B is unavailable while service A is in the middle of a business transaction, the architecture must explain what happens next.
Stage 4: Learn integration architecture
Most enterprise platforms are integration systems. Learn REST, GraphQL, WebSocket, webhooks, Kafka, API gateways, service discovery, OAuth2/OIDC, JWT and mTLS. More importantly, understand when asynchronous integration is better than a synchronous chain of calls.
Stage 5: Learn cloud capabilities, not vendor menus
Cloud architecture is not memorizing hundreds of service names. Learn capabilities: compute, networking, storage, databases, load balancing, autoscaling, identity, secrets, monitoring, queues, event streaming, CDN and disaster recovery. Then map those capabilities to AWS, Azure or GCP.
Stage 6: Understand Kubernetes—and when not to use it
Learn images, containers, pods, deployments, services, ingress, ConfigMaps, secrets, readiness/liveness probes, autoscaling, rolling deployments and resource limits. But remember that architecture includes saying no to complexity. A small application may be better served by a simpler runtime.
Stage 7: Start every design with NFRs
An architecture without non-functional requirements is mostly a technology diagram. Ask about scale, latency, availability, data retention, RTO/RPO, security classification, expected growth and budget before you select infrastructure.
service: booking-api
businessCriticality: high
slo:
availability: "99.95%"
p95LatencyMs: 450
maxErrorRate: "0.5%"
capacity:
peakRequestsPerSecond: 1200
expectedAnnualGrowth: "35%"
resilience:
rtoMinutes: 30
rpoMinutes: 5
security:
authentication: OIDC
dataClassification: confidential
operability:
metrics: true
tracing: true
structuredLogs: trueThis kind of lightweight NFR contract is often more useful than choosing a framework first because it tells the team what the system must actually achieve.
Stage 8: Learn failure-first design
During architecture reviews I mentally remove components. Database unavailable—what happens? Redis unavailable—what happens? A Kubernetes node dies—what happens? A payment succeeds but the response is lost—what happens?
The happy path proves functionality. Failure paths prove architecture.
Stage 9: Learn observability
If the team cannot determine why production is failing, the architecture is incomplete. Learn logs, metrics, distributed tracing, correlation IDs, Prometheus, Grafana, Splunk/ELK and OpenTelemetry concepts. Observability should be designed, not bolted on after go-live.
Stage 10: Communicate architecture clearly
Practice HLD, LLD, C4 views, sequence diagrams, ER models, deployment diagrams, ADRs, API contracts and NFR documents. Every artifact should answer a question. A diagram that looks impressive but does not clarify ownership, data flow or failure points is decoration.
A practical ADR structure
adr:
id: ADR-017
title: Use Kafka for booking-domain events
status: accepted
context:
- multiple downstream consumers need booking changes
- synchronous fan-out increased coupling and latency
decision:
broker: Kafka
delivery: at-least-once
idempotencyKey: bookingEventId
consequences:
positive:
- decoupled consumers
- replayable event history
negative:
- schema governance required
- consumer lag must be monitoredStage 11: Understand business and organization constraints
A technically elegant architecture that ignores cost, timeline, team capability, regulation, vendors or legacy constraints is not a good business solution. Architecture is optimization across competing constraints.
Stage 12: Mentor others
One of the clearest signals that you are moving into architecture is when your work changes from “I can implement this” to “I can help this team implement it correctly.” Architecture multiplies the effectiveness of other engineers.
My architecture review checklist
| Area | Questions I expect answered |
|---|---|
| Business | What outcome, criticality and cost constraints drive the design? |
| Scale | Current/peak traffic, growth, data volume and concurrency? |
| Reliability | Timeouts, retries, idempotency, failover, RTO/RPO? |
| Security | Identity, authorization, secrets, data classification, audit? |
| Data | Ownership, consistency, lifecycle, backup and recovery? |
| Operations | Metrics, logs, tracing, alerts, runbooks and rollback? |
| Delivery | Team skill, deployment model, testing and migration plan? |
How I would practice this transition
Do not create a checklist of fifty technologies and wait until you master all of them. Build one realistic architecture problem end to end: frontend → gateway → backend services → Kafka → database → Redis. Then add Docker, Kubernetes, observability, circuit breakers, rate limiting, security and CI/CD. Finally, deliberately break it.
Architecture becomes real when you can explain the trade-off, predict the failure mode and help a team operate the solution—not when you can name the most technologies.
Your feedback helps prioritize deeper technical content.
Romharshan Singh
Senior Solution Architect and Full Stack Technology Leader with 20+ years of enterprise engineering experience across AI, cloud, distributed systems, Java, Node.js, React, Angular, Kafka and Kubernetes.
