MAIE6000C Chap.11 Scaling, Security and Handover
Scaling, Security and Handover
Two published weeks that the course itself merges
One covers latency, throughput, batching, caching, bottleneck identification, worker scaling, concurrency, load testing and trade-off reasoning. The other covers data minimisation, access control, safe logging, responsible operation, technical debt, handover documentation and the final scope review.
They belong together because both are assessed on evidence a stranger could check, and because they are answered by the same artefacts: the records that let you measure the background step are the records that reveal how much of a submitted item was duplicated along the way.
The evidence ladder
Claim, measurement, localisation, targeted change, re-measurement, documented trade-off.
The module's stated actions for the week are to pick a path where speed matters, take one real measurement, change one thing deliberately where that is sensible, and write down what it cost, which is rungs two to six.
A change made between the first rung and the fourth is a guess with a commit message, and the module's own closing line is that honest reasoning about where the constraint lies counts for more here than inflated claims about scale.
Latency and throughput are not the same number
Latency is how long one item takes; throughput is how many finish per unit of time.
Improving one can worsen the other, which is the first genuine trade-off most semester projects meet. Batching is the classic case: processing ten items in one call usually raises throughput and raises the latency of the first item in the batch, because it now waits for nine others.
Neither outcome is correct in the abstract, and which one you want depends on whether a person is waiting.
Where load concentrates in a system of this shape
The request-handling service is rarely the constraint, because its work per request is small. The database becomes one when every worker polls it frequently.
The AI step is the usual answer, being the slowest operation and often the only one that calls out of the process. The worker pool is the constraint only when everything else has room, which is exactly the hypothesis a small scaling experiment tests.
Load testing at honest scale for this course means submitting a known number of items and watching two numbers, not simulating production traffic that does not exist.
Three exposure rings
What the system stores, what it writes to logs, and what it sends outside itself. Data minimisation is the claim that each ring should be smaller than the one outside it.
Most projects set the outer ring deliberately and let the middle one default to whatever the framework logs, which is how submitted text ends up duplicated in a file nobody meant to create.
The project data policy makes this easier rather than harder: projects must use public, synthetic, anonymised or instructor-approved data, and must not depend on proprietary, confidential or personal data.
Handover, and the reader who is not you
The goal is leaving the project comprehensible to a reader who did not build it, and the handbook sets what that reader needs: what problem the system solves, how it is structured, how to run it, how to test it, what is currently supported and what is not yet supported.
The last of the six is the one teams omit and the one that makes the other five trustworthy, because a document describing only what works reads as marketing to anybody who has tried the system.
What this chapter covers
- 01
The six-rung ladder from claim to documented trade-off
- 02
Latency and throughput as two numbers that trade against each other
- 03
Four levers, what each usually costs, and when it is worth it
- 04
Where load concentrates in a four-service system
- 05
Load testing at the honest scale for a semester project
- 06
Three exposure rings and the data-minimisation claim
- 07
Safe logging, one sentence per field
- 08
The six things a handover reader needs, including the one teams omit
The smallest honest scaling experiment
- 3Describe the measurement taken before anything changes.
- 3Describe the single change and the repeat measurement.
- 3State what each outcome does and does not license.
Key terms
- Latency
- How long a single item takes to be handled, which is the number that matters when a person is waiting for that particular result.
- Throughput
- How many items finish per unit of time, which can improve through batching even while the latency of individual items gets worse.
- Bottleneck
- The component where time or contention actually concentrates, identified by measurement rather than by inspection of the architecture diagram.
- Batching
- Processing several items in one call, which usually raises throughput at the cost of the latency of the earliest item in the group.
- Data Minimisation
- The principle that each of the storing, logging and outward-sending surfaces should carry no more than it needs, each decided separately.
- Safe Logging
- Choosing log fields so that diagnosis remains possible without duplicating submitted content into a file with different access rules.
- Technical Debt
- Work knowingly deferred, listed with what it would cost and why it was deferred, which supplies both the final limitation and the trade-off discussion.
- Handover Documentation
- The written material that lets somebody who did not build the system understand, run, test and continue it.
Scaling, Security and Handover FAQ
How do I show my system scales without a production workload?
By measuring one path, changing one variable, and stating the range. Submit a fixed number of items with one worker and record the wall-clock time until the last job completes together with the average background-step duration from the stored job records. Repeat with two workers and nothing else altered.
A halved total time licenses the claim that throughput was limited by worker capacity over that range on that machine; an unchanged total licenses the more valuable claim that the constraint lies elsewhere, with evidence. What neither licenses is an unqualified statement that the system scales.
What should I not be writing into my logs?
Anything you would not want duplicated into a file with different access rules from the database, which in practice usually means the full submitted text. Go through each field your system logs and say why it is there and what it would reveal to somebody reading the file. Identifiers, statuses, durations and stage names survive that question easily.
The submitted content usually does not, and replacing it with the item identifier costs nothing diagnostically because the text is already stored where whoever is entitled to see it can look it up.
Should I add a big feature in the final fortnight?
The module says the closing week is a poor moment for substantial new features unless the core is already sound, and the rubric explains why. Functional completeness is worth twenty points in the final project, while engineering quality and maintainability, documentation and operability, and testing together are worth forty-five.
A feature added late competes for one of those and puts three at risk, because it arrives untested, undocumented and outside the architecture the team has been describing since the proposal. Listing it as deferred work is usually worth more than shipping it.
Assessment move
Spend one sitting walking your own data: list every field you store, every field you log and everything that leaves the system, then cross out what is not needed. The same walk produces the exposure audit, the safe-logging changes and most of the material the technical brief needs on trade-offs, which is why doing it once beats doing performance and security separately.
Working through Scaling, Security and Handover in MAIE6000C? Sia is AskSia’s AI Computer Science tutor — ask any MAIE6000C Scaling, Security and Handover question and get a clear, step-by-step explanation grounded in how MAIE6000C is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
