Search the practice set
126 questions, 454 terms and 400 topics in 20 areas.
55 results for “Chaos Engineering”
Chaos Engineering
Deliberately injecting failure into a system to discover, before an incident does, which of your resilience assumptions are false.
Consent Management
Capturing, storing, honouring and evidencing a data subject's permissions for specific processing purposes, including withdrawal.
FinOps
The practice of giving engineering teams visibility into and accountability for the cost of what they build and run.
Game Day
A scheduled exercise in which a failure is deliberately introduced and the team responds as though it were real, to test the system and the response together.
Monzo's Microservice Estate
Monzo runs a bank on well over a thousand microservices, and the interesting engineering is in the platform and network isolation that makes that number survivable.
Purpose Limitation
The principle that personal data collected for one stated purpose may not be used for an unrelated one without a new lawful basis.
You have designed a system. Explain the same architecture to a CEO, an engineering manager and an engineer. What changes?
What the interviewer is testing Whether you can adapt to an audience, which is the skill that most often separates a senior engineer from an architect. It is al
A team proposes CQRS for a CRUD admin panel because reads are slow. Is that the right call?
Why not CQRS here "Reads are slow" is a symptom with many causes, and CQRS addresses only one of them: the read and write models having genuinely different opti
Product wants to add "customers who bought this also bought" using purchase history. What does privacy by design require here?
The first question is lawful basis, not architecture Purchase history was collected to fulfil orders. Using it for recommendations is a new purpose , and purpos
You are reviewing a design for an internal tool with 200 users. It proposes Kubernetes, microservices, Kafka, a service mesh and CQRS. How do you handle the review?
What the interviewer is testing Judgement, and whether you can push back without alienating a team. Anyone can spot over engineering; the question is what you d
Chaos Engineering
Hypothesis-driven failure injection with a bounded blast radius.
Privacy Engineering
Minimisation, purpose limitation, and erasure that is implementable.
Bottleneck Analysis
Finding the constraint, and expecting a second one behind it.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Caching for Performance
Layer choice, hit ratio as a first-class metric, and cold-cache recovery.
Capacity Modelling
Arithmetic before load tests, and headroom for failure as well as peak.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Code Review
Where architectural rules are enforced by people rather than by tools.
Concurrency
Operations in flight, and the limits that are the real capacity ceiling.
Connection Pooling
The most common hidden ceiling, and the metric nobody collects.
Contract Tests
Capturing what consumers actually use, not what the API documents.
DORA Metrics
Throughput and stability moving together rather than trading off.
Database Performance
Plans, indexes, contention and the pool in front of the database.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Feature Flags
Decoupling deploy from release, with an expiry date.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Horizontal vs Vertical Scaling
Scale out for stateless, scale up first for stateful.
Latency
Distributions rather than averages, and the floors physics imposes.
Little's Law
L = λW, and the pool sizes it computes directly.
Load Testing
Realistic data, realistic mix, and a ramp rather than a step.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Network Performance Tuning
Keep-alive, compression, payload size and round-trip elimination.
Peak Event Readiness
Freeze, pre-scale, shed order, warm caches and rehearse.
Performance & Capacity
General material on performance and capacity engineering.
Performance Budgets
Targets enforced in CI so regressions fail the build.
Profiling & Optimisation
Measuring before optimising, and optimising the dominant term.
Queueing Theory
Why latency explodes as utilisation approaches capacity.
Refactoring
Changing structure without changing behaviour, in verified steps.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
SOLID
Five design principles, two of which scale beyond the class.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Soak Testing
Long runs that surface leaks and slow degradation.
Software Architecture
General material on the engineering underneath an architecture.
Stress Testing
Pushing past target to learn what breaks first and how it fails.
Tail Latency
p99 behaviour, amplification across fan-out, and hedged requests.
Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Throughput
Work completed per unit time, and why it trades against latency.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Performance & Capacity Engineering
If traffic becomes ten times larger, what breaks first?
Software Architecture & Engineering
Enough engineering depth to know whether the architecture is implementable.
Architecture Communication
Explain the same architecture to a CEO, an engineering manager and an engineer.