Manab's Notes - SECTION 1: Architecture Style & Design Philosophy

1. How do you decide between a monolith, modular monolith, and microservices for a new system?

Start with the team and domain, not the technology.

The decision tree I follow:

Monolith — When the team is small (≤5 engineers), the domain is not well understood yet, or you're building an MVP. It's the fastest path to working software and easiest to refactor later. Don't prematurely distribute.
Modular Monolith — When the domain is understood well enough to draw clear boundaries, but operational complexity of microservices isn't justified. Modules share a process but enforce strict interface contracts between them (no direct cross-module DB access). This is the sweet spot for most mid-size companies.
Microservices — When you have independent scaling requirements per domain, team autonomy demands it (Conway's Law), different services have genuinely different deployment cadences, or you need polyglot persistence. The cost is high: distributed tracing, network failures, eventual consistency, operational overhead.

Key heuristic: If you can't draw clear bounded contexts on a whiteboard, microservices will hurt you. Start modular monolith and extract services only when there's a concrete, proven pain point.

2. What are the trade-offs between layered, vertical slice, and hexagonal architectures?

Layered architecture suffers from horizontal coupling — changing persistence forces touching every layer. Vertical slice fixes this by grouping all layers for one feature together, but you risk duplicating shared infrastructure code. Hexagonal (Ports & Adapters) is the most rigorous: the domain knows nothing about HTTP, databases, or queues. Those are adapters plugged in at runtime. It pays off in systems that swap infrastructure (e.g., migrating from REST to gRPC, or PostgreSQL to DynamoDB) without touching domain logic.

Folder structure:

Layard Architecture:

- UI/

- BusinessLogic/

- DataAccess/- Tests/

Vertical Slicing:

- FeatureA/

- UI/

- Logic/

- Data/

- Tests/

- FeatureB/

- UI/

- Logic/

- Data/

- Tests/

Hexagonal:

- src

- application

- usecases

- repositories

- domain

- ports

- input

- output

- adapters

- frameworks

- persistence

- ui

Refer: Hexagonal Architecture: Structure Example | by Alessandro Traversi | Medium

software design - Onion architecture compared to hexagonal - Stack Overflow

3. How do you apply the Principle of Least Surprises when designing components?

A component should do exactly what its name and interface imply — nothing more, nothing less.

Concrete practices:

Name honestly. A method called getUser() should never write to a database. If it does, call it getOrCreateUser().
Consistent error contracts. Don't return null in some paths and throw exceptions in others for the same failure scenario.
Avoid hidden side effects. If calling a read-only query also updates a "last accessed" timestamp, document it explicitly or extract it.
Predictable ordering. If a method accepts a list and the caller has no reason to expect ordering, guarantee it anyway or explicitly state it's unordered.
Don't let abstraction leak. A PaymentService should not expose database transaction objects to callers.

The test: can a new engineer use your component correctly without reading its implementation? If not, it violates least surprise.

4. How do you avoid accidental complexity when scaling a system?

Accidental complexity is complexity you introduced, not complexity inherent to the problem.

Strategies:

Resist premature abstraction. Don't build a plugin system for a feature that has one implementation. "We might need this later" is how you get five layers of indirection nobody understands.
Delay architectural decisions. Keep options open as long as possible. A single-region deployment is far simpler than multi-region — only go multi-region when you have the SLA and traffic to justify it.
Ruthless dependency audit. Every new library or service introduces operational, security, and cognitive cost. Ask: is the value worth the carrying cost?
Evolutionary architecture over big-bang. Small, reversible changes prevent the need for massive rewrites (which are the epicentre of accidental complexity).
Complexity budget. Some teams explicitly track this: every new service, every new abstraction costs budget. When you add something complex, something simpler must compensate.

The root cause is usually social: engineers who want to impress, or over-engineering driven by imagined future requirements.

Google Sites

Report abuse