Architecture & Documentation
An analyst does not need to be able to build a system, but does need to describe it well — name the architecture style, justify the choice, plan caching, access, and documentation. This is the vocabulary you use with the architect and leads.
The traps, named up front: monolith and microservices get swapped, microservices are called "always better", authentication (who you are) is mixed with authorization (what you may do), and a cache is added with no invalidation, serving stale data. The full map is in the layers below.
Topic map
- Architecture styles — what a monolith and microservices are and how they are built differently.
- Trade-offs and HLD — pros and cons of the styles, when to choose which, and what goes into a High Level Design.
- Caching strategies — where to cache, how to invalidate, and the latency-vs-staleness trade-off.
- Authentication and authorization — the difference between identification, authentication, and authorization and their order.
- Access-control models —
RBACvsABACand the principle of least privilege. - Documentation artifacts — which documents and diagrams a system must have.
Common traps
| Mistake | Consequence |
|---|---|
| Swapping the definitions of monolith and microservices | The whole team gets a wrong picture of the system |
| Calling microservices "always better" with no trade-offs | Network, consistency, and operations are underestimated |
| Confusing authentication (who you are) and authorization (what you may do) | Access holes and a wrong spec |
| Caching with no invalidation | The user sees stale data |
| Reading least privilege as "grant everything" | A huge blast radius on a breach |
| Making the HLD code-level instead of architectural | The document is useless for aligning on the solution |
Interview relevance
The topic is asked to check whether you can reason about a system at the architecture and security level, not just about "features". A candidate who names the downsides of microservices unprompted (network latency, distributed transactions) sounds far more convincing than "microservices are trendy and good".
Typical checks:
- The difference between a monolith and microservices and the conditions for choosing (scale, team, releases).
- The order identification → authentication → authorization and the
RBAC/ABACdifference. - Where to cache and how to plan invalidation (
TTLvs event-based). - What an HLD is, who needs it, and how deep it is worked out.
Common wrong answer: "microservices are always better than a monolith". In fact the choice depends on context: for an early product a monolith is simpler, and microservices pay off when scale, team size, and release independence demand it.