Solution Architect Interview Questions India 2026: Architecture Patterns, CAP Theorem, and Cloud Design

Every Solution Architect interview begins with architecture pattern trade-offs. You must be able to recommend the right architecture for a given context and defend your choice.

Monolithic architecture:

1. A single deployable unit that contains all application functionality: UI, business logic, data access
2. Advantages: simpler to develop and deploy initially; no network latency between components; easier to test end-to-end; a good choice for early-stage products and small teams
3. Disadvantages: scaling requires scaling the entire application; a bug in one component can bring down the whole system; technology diversity is limited; large codebases become hard to maintain; deployments require deploying the entire application
4. When to recommend monolith: early-stage startup with fewer than 5-10 engineers; product-market fit not yet found; need to iterate quickly

Microservices architecture:

1. Decomposes the application into independently deployable services; each service owns its domain and database
2. Advantages: independent deployment and scaling of each service; team autonomy (each team owns a service); polyglot (each service can use the best technology for its domain); fault isolation (a failing service does not crash other services)
3. Disadvantages: distributed systems complexity (network failures, eventual consistency, distributed tracing); operational overhead (service discovery, API gateway, container orchestration); testing complexity (integration and contract testing across services)
4. When to recommend microservices: large engineering organisation (50+ engineers); clear domain boundaries; different scaling requirements per domain (e.g., search requires 10x more resources than checkout)
5. Domain-Driven Design (DDD): use bounded contexts to identify natural service boundaries; each bounded context becomes a microservice

Serverless architecture:

1. Functions-as-a-Service (FaaS): AWS Lambda, Azure Functions, Google Cloud Functions; code runs in response to events without managing servers
2. Advantages: no server management; automatic scaling (from zero to millions of events); pay-per-invocation (cost is zero when idle)
3. Disadvantages: cold start latency (first invocation after idle period is slower); stateless (no persistent in-memory state between invocations); execution time limits (15 minutes for AWS Lambda); vendor lock-in; debugging and local development are harder
4. When to recommend serverless: event-driven workloads (file processing, notifications, webhooks); unpredictable or spiky traffic; background jobs; APIs with low average traffic but occasional spikes

Event-driven architecture:

1. Services communicate via events (messages) on a message broker (Apache Kafka, AWS SNS/SQS, RabbitMQ)
2. Loose coupling: the producer does not know who consumes its events
3. Use cases: real-time data pipelines, decoupled microservices communication, auditing and event sourcing
4. CQRS (Command Query Responsibility Segregation): separate the write model (commands) from the read model (queries); enables optimised read stores and event sourcing

CAP theorem and non-functional requirements are core Solution Architect knowledge areas that distinguish senior architects from developers.

CAP theorem: 1. In a distributed data store, you can guarantee at most two of the three properties simultaneously: Consistency (C): every read returns the most recent write or an error Availability (A): every request receives a (non-error) response — but without guarantee it contains the most recent write Partition tolerance (P): the system continues to operate despite network partitions (some messages between nodes are lost or delayed) 2. Network partitions are unavoidable in distributed systems; therefore every distributed system must choose between C and A under partition 3. CP systems: sacrifice availability when a partition occurs; wait for consistency to be restored before serving reads. Examples: HBase, Zookeeper, Etcd 4. AP systems: remain available under partition but may return stale (eventually consistent) data. Examples: Cassandra, DynamoDB (with eventual consistency), CouchDB 5. CA systems: only possible in a single-node system (no partition tolerance needed); not truly distributed 6. PACELC extension: adds Latency vs Consistency trade-off even when there is no partition: PAC (partition: A vs C) and ELC (else: L vs C)

Consistency models:

1. Strong consistency: every read returns the latest write
2. Eventual consistency: given enough time without updates, all replicas will converge to the same value
3. Read-your-writes consistency: a user always sees their own writes immediately
4. Causal consistency: operations that are causally related are seen in order by all nodes

Non-Functional Requirements (NFRs):

1. Availability: the percentage of time the system is operational. 99.9% = 8.7 hours downtime/year; 99.99% = 52 minutes/year; 99.999% = 5 minutes/year
2. Reliability: the probability the system performs its function correctly for a given time period
3. Scalability: the ability to handle increased load. Vertical scaling (bigger machine) vs horizontal scaling (more machines)
4. RTO (Recovery Time Objective): the maximum acceptable time to restore service after a failure
5. RPO (Recovery Point Objective): the maximum acceptable amount of data loss measured in time (how old the most recent backup can be)
6. Active-active: multiple instances serve live traffic simultaneously; immediate failover; no RTO impact
7. Active-passive: one instance is live; the passive instance takes over on failure; RTO depends on failover time
8. Disaster Recovery (DR): multi-region deployment; data replication to the DR region; route 53 health checks + DNS failover

Solution Architects at Indian IT services companies must know cloud design principles and how to structure technical proposals for clients.

Cloud design principles:

1. Design for failure: assume any component can fail at any time; build redundancy and automatic recovery
2. Loose coupling: minimise dependencies between components; use async communication (message queues) over synchronous API calls where possible
3. Use managed services: prefer AWS RDS over self-managed MySQL, AWS SQS over self-managed RabbitMQ; reduces operational burden
4. Immutable infrastructure: never modify running servers; replace them with new ones built from the latest image (immutable AMIs, container images)
5. Security in depth: multiple layers of security controls; never rely on a single control; encryption at rest and in transit; least privilege IAM policies
6. Cost optimisation: right-size instances, use Auto Scaling, use Spot Instances for fault-tolerant workloads, use S3 Intelligent-Tiering for variable access patterns
7. Data residency: under India's DPDP (Digital Personal Data Protection Act) 2023, personal data of Indian users may require storage within India; check data residency requirements for each client

Integration patterns:

1. API Gateway: single entry point for all clients; handles authentication, rate limiting, SSL termination, routing
2. Service mesh (Istio, Linkerd): handles inter-service communication concerns (mTLS, traffic management, observability) without application code changes
3. Event streaming (Apache Kafka): high-throughput, ordered, durable event log; used for real-time data pipelines and microservice event-driven communication
4. ESB (Enterprise Service Bus): older integration pattern; centralised message routing and transformation; still found in legacy enterprise environments in India
5. Saga pattern: manage distributed transactions across microservices using a sequence of local transactions, each publishing an event to trigger the next step; compensating transactions roll back on failure

RFP/RFQ writing for Indian IT services:

1. Executive Summary: 1-2 pages; business problem, proposed solution, key differentiators, estimated value
2. Solution Architecture: architecture diagram, technology stack, rationale for each choice, integration with client's existing systems
3. Non-Functional Requirements coverage: how the design meets SLA, scalability, security, and compliance requirements
4. Implementation approach: phases, milestones, team composition, governance model (Agile vs Waterfall vs hybrid)
5. Risk register: identified risks, likelihood, impact, and mitigation strategies
6. Total Cost of Ownership (TCO): infrastructure costs, license costs, implementation costs, ongoing support costs
7. Stakeholder communication: Solution Architects in India regularly present to CTO, CIO, and non-technical business stakeholders; practise explaining architecture trade-offs in business terms (cost, risk, time-to-market) not just technical terms