Scribd
Upload
1 views

Architecture_Patterns_Interview_Problems

The document discusses key considerations for choosing between monolithic and microservices architectures, emphasizing team size, scalability, and domain complexity. It also covers the benefits of event-driven architecture for decoupling and scalability, as well as the advantages and trade-offs of layered and hexagonal architectures. Additionally, it outlines architectural patterns for multi-tenant SaaS applications, focusing on isolation strategies and compliance needs.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
1 views

Architecture_Patterns_Interview_Problems

The document discusses key considerations for choosing between monolithic and microservices architectures, emphasizing team size, scalability, and domain complexity. It also covers the benefits of event-driven architecture for decoupling and scalability, as well as the advantages and trade-offs of layered and hexagonal architectures. Additionally, it outlines architectural patterns for multi-tenant SaaS applications, focusing on isolation strategies and compliance needs.

Uploaded by

pbecic
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Architecture Patterns

How would you decide between a monolithic and a microservices architecture


for a new greenfield enterprise application?
 Key considerations include team size, scalability needs, deployment frequency, and
domain complexity.
 Choose monolith when:
 Team is small or product is at MVP stage.
 Business domain is not yet stable or boundaries are unclear.
 You want to minimize deployment and operational overhead.
 Choose microservices when:
 You have multiple independent teams working on distinct business capabilities.
 There are strict requirements for scalability, resilience, or independent deployments.
 The domain is well-understood and aligns with bounded contexts.
 A common approach is to start with a modular monolith and extract services when
needed.

How does event-driven architecture (EDA) enhance system decoupling and


scalability?
 EDA uses asynchronous messaging to allow producers and consumers to communicate
indirectly.
 Benefits:
 Improves decoupling — services are not aware of each other's implementation or
presence.
 Enables horizontal scalability — consumers can scale independently.
 Supports extensibility — new consumers can subscribe to existing events without code
changes in the producer.
 Design considerations:
 Use durable messaging systems like Kafka or RabbitMQ.
 Adopt schema versioning and contract validation to maintain compatibility.
 Ensure observability via message tracing and correlation IDs.

What are the benefits and trade-offs of using a layered architecture?


 Layered architecture separates concerns into layers such as presentation, application,
domain, and infrastructure.
 Benefits:
 Improved separation of concerns.
 Ease of testing and mocking — each layer can be tested in isolation.
 Well-established and simple to understand.
 Trade-offs:
 Rigid dependencies between layers can slow down change.
 Cross-cutting concerns (e.g., logging, validation) may lead to duplication.
 May not suit high-performance, latency-sensitive systems due to excessive abstraction.
 Best practices:
 Use clear contracts between layers.
 Avoid leaking infrastructure concerns into business logic.

How does hexagonal architecture help in achieving better testability and


decoupling?
 Hexagonal (ports and adapters) architecture centers the domain logic and isolates it
from external systems.
 Benefits:
 Improves testability — core logic can be tested without databases, UIs, or APIs.
 Decouples the domain model from delivery mechanisms and infrastructure.
 Allows easier swapping of components — e.g., changing databases or APIs without
touching business logic.
 Key components:
 Ports: interfaces that define expected behavior (e.g., for persistence, messaging).
 Adapters: concrete implementations of ports (e.g., JPA, REST, Kafka clients).
 Encourages inversion of control and clean dependency flow.

What architectural pattern would you use to support multi-tenant SaaS, and
how would you isolate tenants?
 Common architectural patterns for multi-tenancy:
 Shared database, shared schema — simplest but least isolated.
 Shared database, separate schema — moderate isolation with shared infra.
 Separate databases per tenant — highest isolation and flexibility.
 Pattern selection depends on scalability, compliance, and data isolation needs.
 Isolation strategies:
 Use tenant identifiers in the data model and enforce data filtering.
 Configure separate data sources or schema resolvers dynamically per request.
 Apply rate-limiting, logging, and access control per tenant.
 Ensure proper observability and quota enforcement across tenants.

You might also like