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.
