Platform Architecture and System Design
Platform Architecture and System Design checks whether you can choose a structural style, justify it with availability and coupling arguments, and predict where a design breaks under partial outage. Questions are scenario-based: given constraints on RTO, traffic shape, and team topology, select the decomposition and the integration style.
Boundaries, state, and blast radius
- Split services along bounded contexts, not technical layers; each service owns its data store and exposes it only through a contract.
- Keep the request tier stateless so any instance serves any request; push session and file state to managed stores.
- Prefer asynchronous events for cross-context workflows; reserve synchronous calls for queries that must answer inside the user's request.
- Use cells (independent stacks with their own data and quotas) when one tenant's load must not degrade another.
Availability arithmetic
- Serial dependencies multiply: 0.999 × 0.999 = 0.998, roughly 17.5 hours of downtime a year, not 8.76.
- Parallel redundancy improves availability: two independent 99.9% paths give 1 − 0.001² = 99.9999%, but only if they share no failure domain.
- RTO and RPO choose the DR pattern: backup/restore (hours), pilot light, warm standby, active-active (near-zero RPO, hardest consistency).
Consistency across services
Distributed transactions are usually replaced by the transactional outbox plus idempotent consumers, or by sagas with compensating actions. Accept eventual consistency and state the convergence window explicitly.
Worked example
Target is 99.95% monthly. The app tier spans two AZs at 99.99%; the database is single-AZ at 99.9%. Chain availability = 0.9999 × 0.999 = 0.9989, i.e. 99.89% - short of target. Moving the database to Multi-AZ (assume 99.99%) gives 0.9999 × 0.9999 = 0.9998, i.e. 99.98%. The reasoning matters more than the number: the weakest serial link sets the ceiling, so adding redundancy to the already-strong app tier buys nothing.
Traps
- Claiming redundancy for two nodes in the same rack or AZ.
- Leaving shared dependencies (DNS, IdP, message broker) out of the availability chain.
- Choosing microservices for a small team with one deployable domain.
- Chatty synchronous calls that turn one user request into twenty network hops.
- Confusing reliability (does it do the right thing) with availability (is it answering).