Team practices and system design
Status: Concise draft.
System-design answer frame
Section titled “System-design answer frame”- Clarify users, scale, correctness, latency, availability, privacy and budget.
- State the consistency-critical invariants.
- Propose the simplest viable architecture and data model.
- Trace one write and one read end to end.
- Identify bottlenecks and failure modes.
- Add scaling/operational mechanisms only where a stated constraint requires them.
- Explain observability, security, migration and testing.
Senior answers expose assumptions and decision triggers. Diagrams without invariants or failure handling are incomplete.
Architecture choices
Section titled “Architecture choices”A well-modularized monolith gives local transactions, simple deployment and easier refactoring. Microservices offer independent deployment/scaling and organizational boundaries at the cost of network failure, eventual consistency, duplicated operations and harder testing. Team topology and domain boundaries matter more than service count.
Build versus buy should consider strategic differentiation, integration constraints, compliance, total operating cost, lock-in, exit plan and internal expertise—not only license cost.
Technical leadership
Section titled “Technical leadership”- Code review protects correctness and spreads context; distinguish blocking defects from preferences.
- Estimates are ranges conditioned on assumptions. Surface unknowns and reduce them with small investigations.
- Technical debt is a future cost created by a present choice; name its interest and trigger for repayment.
- Architecture decisions should record context, alternatives, decision and consequences.
- Incidents should produce learning and system changes, not a search for individual blame.
Common interview systems
Section titled “Common interview systems”For each, define the strongest invariant before choosing technology:
- Booking: prevent double allocation under concurrency.
- Webhook receiver: authenticate, durably accept, deduplicate, retry and expose status.
- Import pipeline: bounded memory, validation, partial failure, progress and resumability.
- Multi-tenant SaaS: isolation in queries, storage, cache, queues and authorization.
- Notifications: preferences, fan-out, provider failure, deduplication and delivery state.
Interview prompts
Section titled “Interview prompts”- When would you split a Laravel monolith?
- Resolve disagreement over a repository/service abstraction in review.
- Design a tenant-safe background export.
- Describe an incident you would escalate, mitigate, communicate and review.