Question 1

What is hexagonal architecture (ports and adapters) and what problem does it solve?

Accepted Answer

The domain logic sits at the core, ports define interfaces for external interaction, and adapters implement those interfaces for specific technologies (HTTP, DB, message queue) — keeping domain logic independent of infrastructure. Without hexagonal: domain logic directly calls UserRepository (JPA). Testing requires a real DB. With hexagonal: domain calls IUserRepository (port). Tests inject a fake adapter. Swap MySQL for PostgreSQL by writing a new adapter — domain unchanged. Also called 'Clean Architecture' (Uncle Bob) or 'Onion Architecture'.

Question 2

How do you decide between event-driven and request-response architecture?

Accepted Answer

Event-driven excels for asynchronous workflows, decoupled services, audit trails, and workloads where producers and consumers scale independently; request-response is better for real-time interactions requiring immediate results and simpler debugging. Request-response: user action → immediate result (checkout, search). Event-driven: order placed → (async) send confirmation email, update inventory, notify warehouse — each service processes in its own time. Events: natural audit log, temporal decoupling. Trade-off: eventual consistency, harder to trace causality, message ordering challenges.

Question 3

What are the trade-offs of using an ORM versus writing raw SQL?

Accepted Answer

ORM abstracts DB details, speeds development, and prevents basic SQL injection — but can generate inefficient queries, hide N+1 problems, and make complex queries awkward; raw SQL gives full control, expressiveness, and predictability. ORM wins: CRUD, standard patterns, quick development, portability. Raw SQL wins: complex reporting queries, bulk operations, DB-specific features (window functions, CTEs, JSONB). Pragmatic approach: ORM for 80% of queries, raw SQL or QueryDSL for the 20% that need it. Always check what SQL your ORM generates.

Question 4

How do you manage breaking API changes in a system with many downstream consumers?

Accepted Answer

Use API versioning (/v1/, /v2/ or Accept headers), publish deprecation timelines, use consumer-driven contract testing (Pact) to detect breakage, apply the expand-contract pattern, and use feature flags for gradual rollout. Expand: add the new field/endpoint alongside the old. Both work simultaneously. Migrate consumers. Contract: remove the old one after all consumers are off it. Consumer-driven contracts (Pact): consumers define what they expect; CI breaks if the provider violates it. Treat APIs as products — plan their lifecycle.

Question 5

What is the relationship between DDD bounded contexts and microservices?

Accepted Answer

A bounded context is the natural boundary for a microservice — it has its own ubiquitous language, domain model, and database; microservices that span bounded contexts create tight coupling and should be split. 'Order' means different things to Sales (cart + checkout), Warehouse (pick + pack), and Finance (invoice + payment). Each is a separate bounded context with its own model. Mapping a bounded context to a microservice gives the service a clear identity and data ownership — the Anti-Corruption Layer handles cross-context communication.

OOP Concepts — Tech Lead Interview Questions

More Tech Lead Topics

OOP Concepts at Other Levels