Performance, Security, and Testability

Three quality attributes take the stage in this session: performance, security, and testability. Each gets a meaning, a scenario shape, tactics, and design choices that turn goals into structure. The same rhythm repeats for each attribute — define it, write its six-part scenario, list its tactics, then apply the seven design decision areas — so ideas you build in performance return as tools for security and testability.

5.1 Performance as a Quality Attribute

5.1.1 What Performance Means

Here is a puzzle: a system gives the perfectly right answer — and it is still useless. How? It answered five days late. Correctness alone does not make software good; the answer has to arrive in time. That time-bound behavior is what the quality attribute performance designs for.

Performance is about time. It asks how fast the system answers an event (something that happens and calls for a reaction), and whether the answer lands on time. Quick but late is not enough. Fast, on-time responses are the whole contract.

The session opened with a request to clarify how this differs from availability, which was covered earlier.

Now let us pin the idea down. An event arrives at the system (or at some part of it). Responding consumes resources — CPU cycles, memory, network bandwidth, disk — and resources take time. While the system works on this event, it may also be serving other events at the same moment. So the delay a user feels has exactly two sources: either the system is actively working, or it is waiting for something.

$$\text{Response time}=\text{Processing time}+\text{Blocked time}$$

Here processing time is the stretch during which the system is computing the answer, and blocked time is the stretch during which the work sits stalled. Work gets blocked for three standard reasons:

• Contention for resources — many events want the same resource (one CPU, one database lock), so all but one must wait.
• Unavailability of resources — the resource is offline or failed, so nothing can proceed even with no competition.
• Dependency on other computations — the answer needs another component's result first, and that component may sit across a slow network.

Every performance tactic you will meet in 5.1.4 attacks one side of this equation: either it shrinks the demand (less processing, less contention) or it improves the supply (more or better-managed resources).

5.1.2 Events and Stimulus Sources

Performance always answers an event. UI coders live with these daily: a mouse click, a mouse-over, entering a text box, leaving it, entering a window, exiting it. Events can be hardware events or software events. From a design seat, the event stream also includes:

• Messages arriving from other systems.
• Notices pushed to your system.
• Calls coming from other users or subsystems.
• The clock itself — a key event that marks a given time. The system must handle it well. A backup job that fires at midnight, a session that expires after fifteen idle minutes, a report scheduled for the first of the month — all of these are clock events.

The source of stimulus — whoever or whatever fires the event — sits outside or inside the system: a human user, another system, or the system's own clock. But the property that shapes the whole design more than the source's identity is the arrival pattern — the rhythm at which events show up:

• Periodic events arrive at a fixed gap, with a steady rhythm.
• Sporadic events break long silence. Nothing happens for days, then a tsunami hits; quiet again, then storms. Systems built for sporadic loads must ride out bursts. You may claim you serve requests 95% of the time. Notice too that 95% of the time there are no requests at all. The burst still has to be handled when it lands — averages hide the storm.
• Stochastic events follow probability patterns: Poisson distribution, chi-square distribution, standard normal distribution. When the load follows a known chart, design for that pattern. The system may even scale up on its own when it senses events building.

Clients also set speed targets per load case. Normal use gets one target. Under peak load the client may allow no drop at all, or a drop up to a stated limit. Targets are often written per case.

5.1.3 Performance Scenarios and Measures

A performance scenario has six parts, and you should be able to name each one. The six slots, with the values each can take:

Walk any performance requirement through those six slots and the vague wish becomes a testable statement.

How speed is measured — five gauges:

• Latency is the lag between stimulus and reply.
• A deadline gauge asks whether work finished by a promised time (the fuel must ignite when the cylinder reaches the right position — late ignition fails even if it happens).
• Throughput counts work done per unit of time:

$$\text{Throughput}=\frac{\text{number of transactions completed}}{\text{time taken}}$$

• Jitter is how much that lag wobbles from one reply to the next — the variation in latency. A video call with steady 100 ms replies feels better than one jumping between 20 ms and 500 ms, even if both average the same.
• Miss rate is the share of replies that miss their timing target — the number of events not processed because the system was too busy to respond:

$$\text{Miss rate}=\frac{\text{events that missed their timing target}}{\text{total events that arrived}}$$

(On the term: "miss rate" is the standard name for this gauge in the architecture literature — the count of unprocessed events divided by arrivals.)

Visual picture: plot response time on the vertical axis against load (requests per second) on the horizontal axis. For light load the curve stays low and almost flat. As load approaches capacity the curve bends upward, and past saturation it climbs steeply — that knee of the curve is where latency targets start getting missed and miss rate rises from zero. One-line takeaway: response measures are read against load, never in isolation.

5.1.4 Performance Tactics: Control Demand or Manage Resources

When an event arrives, the tactics fall into two families: control the demand, or manage the resources.

Family 1 — Control resource demand (shrink what asks for service):

• Manage sampling rate. If a stream of data is captured more rarely, less work arrives — usually at some cost in fidelity.
• Limit event response. Process events only up to a set maximum rate; queue or refuse the rest.
• Prioritize events. Rank events by importance; under pressure, serve the important ones first and ignore the rest. A fire alarm outranks "room too cold."
• Reduce overhead. Remove intermediaries and extra hops between components; co-locate pieces that talk constantly.
• Bound execution times. Cap how long any single response may run (for example, limit iterations of a search), accepting a slightly less exact answer.
• Increase resource efficiency. Better algorithms in hot spots cut the work per event.

Controlling demand — a sampling example, worked end to end. Your mobile slows down while navigating. Position fixes for Google Maps might sample the GPS ten times per second. Cut the sampling rate to once per second and resources are released; the demand becomes one GPS read per second. If the app works in background mode, cut further to one read every five seconds. Count the effect: GPS reads fall from 10 per second to 0.2 per second in background — a 50-fold reduction in that demand — while a car moving at city speeds changes position by only a few meters between fixes, which is plenty for navigation. As the architect, you suggest this kind of reduction to the system designers.

Family 2 — Manage resources (serve the demand better):

• Increase resources. Faster processors, more memory, faster networks — often the cheapest immediate win.
• Introduce concurrency. Serve several event streams in parallel on different threads or processors.
• Maintain multiple copies of computations. Several identical servers behind a load distributor reduce contention on any one machine.
• Maintain multiple copies of data. Caches and replicas put data closer to the requester (this grows into a full design decision in 5.2).
• Bound queue sizes. Cap how many requests may wait; decide a policy for what happens when the cap is hit.
• Schedule resources. When many events contend for one resource, choose the order of service — first-come-first-served, priority order, or earliest deadline first.

Managing resources — buffers and queues. When many requests flood in, the system can hang because it cannot cope. Two levers exist:

• Increase the buffer size so requests wait in line instead of being dropped. Tell users honestly: if the buffer is more than half full, the response will take time, because the system carries too much load.
• Or shrink queues to a size you expect people to wait out patiently. The moment the queue fills, reply at once: there is heavy load right now, please come back after some time. Do not leave the person hanging. This does not make the response fast, but it stops the user from feeling abandoned.

One caveat: if the requirement says every request must be handled, neither lever is enough and you need other tactics — with zero drops allowed, queues must be sized for the worst case and demand must be reduced elsewhere, because bounding a queue means refusing someone.

5.1.5 Latency versus Resources: The Client Conversation

Keep the words straight. Latency gauges speed. CPU usage, memory usage, server count — these are resources. More CPU means more resource, so speed can rise; too few resources show up as longer latency. In the response-time equation from 5.1.1, buying resources attacks blocked time (less contention) and processing time (faster machines), which is why resource talk and latency talk get tangled — but they are different currencies.

Real-world: the customer never asks for more CPU or more RAM. The customer asks for reduced latency. The client negotiates a latency level; you quote the resource costs of reaching it. Those costs include CPUs, memory, more servers, load distribution, and faster processors. The cost-benefit side — the economics of software architecture — comes later in the course.

5.2 Design Decisions for Performance

5.2.1 Allocation of Responsibility

Seven decision areas turn performance goals into structure: allocation of responsibility, coordination, data model, mapping among architectural elements, resource management, binding time, and choice of technology. This subsection takes the first one — and it is the workhorse: allocation of responsibility maintains multiple copies — copies of computation and copies of data.

Copies of computation. Put a load distributor in front and let requests flow to several servers, each capable of doing the same work. The distributor can assign work round-robin or hand each request to the least busy server. Newer designs also spread computation out. If many systems sit on one network, hand work to idle systems, and the whole setup runs better. The usual shape is simpler: serve many users from several compute servers backed by one database. One database is rarely the bottleneck. Drawing the GUI and running business logic eats most of the cycles.

Copies of data. When results must be shared across a wide area — think of school results — place a copy of the database in each region. Two wins follow: fewer pings to reach the data (the copy sits near its users), and fewer hits on each server (the load spreads across the copies).

A follow-up question pushed the same idea one step further.

And a third question fixed the boundary of the whole technique.

An architect's job rewards dreaming. For a brand-new system — database, resources, topology, all from scratch — you discuss, jot points, draw diagrams, lay down the flow. Then sleep over it. Long bus rides were made for exactly this thinking.

A bit of history shows how much is now hidden. There was a time when even binary search had to be written into your code. Programs were written in COBOL. ISAM — the index sequential access method — arrived only mid-career. Before that, code created indexes by hand and ran binary search over them. Data was reached with bubble sort algorithms and split into compartments by hand. Today the RDBMS does all of it silently, and many developers never learn how or why. The lesson for an architect: every layer that hides mechanics still forces someone to decide the mechanics — and that someone is you.

One more push from the session: use the AI tools available — Bard, ChatGPT, or anything else that helps you study. Someone objected that telling students this was the faculty's job. The better view: guilt about AI tools today is like guilt about using a car to reach the airport. Go by bullock cart and you might as well live in your grandfather's era. These tools never tire of repeated questions; even the most patient teacher does. And a doubt or two raised live makes sessions fun — that is why live sessions exist at all.

Asynchronous tools deserve their own look. With asynchronous communication you can spread responsibility across multi-threading, multi-processing, queues, buffers, and caches. A server hit by a flood of queries can keep a queue and answer in order. No more "resource busy" replies. Size the queue with care. Too short, and people get "not available" replies. Too long, and people wait forever.

5.2.2 Coordination

Coordination decides how parts work together — and how they talk while doing it. A physical example makes it concrete: food delivery. Performance here is simply the number of minutes from placing the order to delivery. One part is food preparation; the other is delivery once food is ready. Build a coordination model. Study evening load patterns and per-restaurant load, then distribute riders to match. Tell riders which areas run short of riders, and which have too many. When a rider moves to a shortage area, tag them and steer business their way. Notice what the coordination model really is: a scheduling policy for riders, driven by measured arrival patterns — the same stochastic thinking as 5.1.2, applied to motorcycles.

Ways to talk come in labeled pairs: stateful or stateless, synchronous or asynchronous, guaranteed delivery or best effort, tuned for throughput or for latency.

Two need unpacking:

• Stateful. A phone call holds a state: the person you talk to knows you are connected. A connected state exists for the whole conversation.
• Stateless. You send a message and the receiver drops the connection. So the message carries your identity, or a token. Processing runs against the token. The receiver keeps a session record — "I am in a session with this person" — and replies. When you respond again, you identify yourself once more. No continuous state survives between exchanges.

Website browsing is stateless. Submit something on a page and the server does not remember you. The workaround: the browser passes tokens that hold the session state. Your application state travels with the token, gets sent to the server, drives processing, and routes the response back to the same session. Keep your session alive so you can receive the response. Why go to this trouble? Because a stateless server keeps no per-client memory, so any of a hundred servers can take your next click — coordination becomes cheap and capacity scales by adding machines.

5.2.3 Data Model

Data-model decisions set which abstractions sit at which level, which copies exist, and how much detail lives where. They also ask where data flow may jam. A grammar note worth keeping: data is plural, datum is singular.

Partitioning came up before and returns here: vertical or horizontal partitioning. Vertical splits by columns or fields (some fields live apart from others); horizontal splits by rows (this year's rows here, older rows elsewhere). Old data moves to archives. Some banks run a separate path: want bank statements older than five years? Submit a request; a fee may apply. The data is fetched from archives in the background, where archived resources serve it — the hot store stays small and fast because the cold store took the weight.

Retention rules can be strict. A recently built financial accounting system let the client scan documents. The scans attach to vouchers and goods receipt notes, so paper originals could be archived away. Hire a warehousing service, seal documents in a trunk, and forget them for the eight years the law requires. After eight years, have the trunk disposed of. The scanned images stay in the archive. A very large company may care about even archive costs. It can destroy images after eight years and keep structured data for queries and analysis. Even structured data can shed weight: make a vertical partition so certain fields never enter the archive. Then state up front that data older than ten years returns only selected fields.

Who owns these decisions — database architect, software architect, programmer, system designer? Those are questions of company structure; firms of different sizes split roles differently. In this course, every one of them is the architect's responsibility. Team size and delegation are management issues.

5.2.4 Mapping, Resource Management, Binding Time, and Choice of Technology

Mapping among architectural elements hands each job to a subsystem. The course mostly maps software parts, but hardware mapping exists too — which process lands on which machine matters when network hops cost milliseconds.

Resource management reuses earlier ground: CPU speed, memory, disk space, server count and placement, queues, buffers, fixed versus variable resources, and when to add more.

Binding time splits early design choices from runtime rules. Decide up front to keep a hot-swappable server ready: that is compile-time binding, also called early binding. Write a rule: when free disk space falls below 10%, add disk space on its own. That is late binding, decided at runtime. Decisions taken at design time or development time are early; decisions taken at run time are late. Early binding buys predictability; late binding buys adaptability — the auto-scaling behavior promised back in 5.1.2 is late binding in action.

Choice of technology covers which server to use, where to locate it, whose resources to rent, and what to prioritize. Add the performance numbers of competing service providers. Ultimately price versus performance decides; everyone chases the best deal at the lowest price. The architect must understand both sides.

5.3 Security as a Quality Attribute

5.3.1 Core Security Goals

Here is a question that sounds simple and is not: what exactly does "secure" mean for a system? The answer is not one property but six — three classic goals plus three supporting tools — and every security requirement you will ever write reduces to some mix of them.

Security rests on three classic goals plus three supporting tools.

An attack is any action against the system intended to do harm: an unauthorized attempt to access data or services, to modify data, or to deny service to legitimate users. Each attack targets one of the three goals above — read what you should not (confidentiality), change what you should not (integrity), or block those who should (availability).

5.3.2 Authentication and Non-Repudiation

Authentication is ID checking: are you the right person? Tools include biometrics, keys, and OTPs (one-time passwords, codes valid for a single login attempt). Microsoft Authenticator and Google Authenticator are very popular — you have likely used Microsoft Authenticator to reach Teams.

Non-repudiation is non-deniability: a person who used a service cannot later deny having used it. It leans on the strength of the provider's process for keeping logs and controlling entry. If auditors have cleared a strong process, the user cannot deny the transaction.

5.3.3 Authorization

Authorization is user rights. Every classic system — Unix or Windows — grants rights to a user, to a group, and to others. Rights attach to files, directories, and processes. Handing out these rights over resources, file systems, and processes — to users, groups, and the public — is authorization.

Keep the three tools straight, because exams love the distinctions: authentication proves who you are, authorization decides what you may do, and non-repudiation stops you from denying what you did. A system can know exactly who you are (authenticated) and still refuse you the file (not authorized).

5.3.4 The General Security Scenario

A security scenario slots into the same six-part shape used for performance:

Reading the rows against the lecture's points: security may be required by humans or by other subsystems; attackers may be humans or robots probing the systems; the stimulus is an unauthorized attempt — delete data, access the system, or modify data; the artifact may be the system, a subsystem, a component, or a server; the environment ranges over online or offline, full or partial operation, or shutdown, depending on the requirement.

The response varies most, so take it slowly. The system may simply shut down.

Measures follow. How quickly did the system handle it? Did data stay uncompromised? Was the attack resisted? Could the system roll back and recover? How vulnerable are we still?

A war story explains why backups deserve respect. Around 1986, at a client site, the EDP manager got fired by the chairman. He did not quit quietly. He walked into the computer room and wiped every file on the server. No backups existed. He left his resignation letter on the chairman's desk and walked out. Back then no legal framework could even prove what he had done. Today the IT Act can send such people to jail. Yet small offices still underrate the backups they need.

Chat wisdom added the 3-2-1 backup rule — three copies, two media types, one off-site — known classically as grandfather-father-son backup (generations of backups kept side by side so one bad save never destroys every version).

Physical security adds its own demands: biometrics, armed guards, shutters. Large and small data centers alike use biometric entry and armed guards. A race-course project once kept its mainframe room with no doors or windows. The main entrance was a collapsible shutter, locked during races. Armed guards carrying loaded weapons stood outside. Visitors carried badges back then, and staff knew every face on sight; today a biometric system does that job. Software tactics mirror these physical ones — which is exactly where the tactic list comes from.

5.3.5 Security Tactics: Detect, Resist, React, Recover

The tactic list organizes into four verbs, and the physical-security picture explains them: checkpoints limit entry (resist), badges expose strangers (detect), locked doors respond (react), off-site backups heal (recover).

• Detect: detect intrusion (compare traffic patterns against known malicious signatures); detect service denial (compare incoming traffic against historic denial-of-service profiles); verify message integrity (checksums and hash values flag even a one-character change); detect message delay (variable delivery times betray an eavesdropper sitting in the middle).
• Resist: identify the actor (user IDs, addresses, ports); authenticate the actor (passwords, one-time passwords, certificates, biometrics); authorize the actor (access-control rights); limit access (memory protection, closed ports, blocked hosts); limit exposure (fewest possible entry points); encrypt data (in storage and on the wire); separate entities (different servers, networks, or air gaps); change default settings (published defaults are an attacker's first try).
• React: revoke access; lock the computer (repeated failed logins trigger a lockout, often for a limited period since legitimate users mistype too); inform actors (notify operators and cooperating systems).
• Recover: maintain the audit trail (a record of who did what, when — used to trace and identify the attacker) and restore a safe state using the availability-style recovery tactics.

You should detect an attack, resist it, react appropriately after resisting, and recover from it.

5.3.6 Applying the Design Decisions to Security

Allocation of responsibility. Everything above must be done by some system, and someone must own it. People allowed to run the system must be identified. Identity is now a big business of its own; companies buy third-party services for secure sign-in checks. The institute runs its own LDAP server: most approved resources route you through that server, while Teams uses its own path.

Coordination model. Systems and people work together to restrict services, end connections, watch services, and escalate — all fitted into one smooth whole.

Data model. The audit trail is part of the data model. Some data sits in separate physical locations, open only to holders of rights on those spots. Encryption joins the data model, for transport of data or for storage of data.

Chain cryptography gets a strong yes wherever insiders touch data — smaller setups where coders hold direct access to the live database, for instance. If anyone bends the data, crypto checks show at once that the chain broke somewhere.

The chain's shape drew a natural follow-up.

Then someone tested the boundary between ordinary checks and cryptography.

And one more thread, kept for later in the course.

Real-world: banking transactions already depend on encryption. Banks refuse unauthorized transfers. India has moved to 256-bit encryption, and the bank supplies the function you include in your code.

Mapping hands security's jobs to people, tools, software, and hardware; that mapping sits in the architect's hands.

Binding time decides when security tools enter. Tools called at run time count as late binding. Technology choices include RSA keys, third-party code generators for two-factor authentication, and which service provider sends your OTPs.

5.4 Testability

5.4.1 Testing versus Testability and the Cost of Modifiability

Industry studies put testing at a huge share of development cost — so anything that makes testing cheaper pays back fast. But first, a distinction the session drew carefully: testing is the act of running checks to find faults; testability is the degree to which the software is built so that such checks can find faults easily. Testing and testability carry different costs, and the same triangle appeared earlier with modification and modifiability. Modification without modifiability carries one cost; building modifiability in carries another; modification after modifiability exists carries a third, much smaller one.

The comparison, worked with real numbers:

The example uses a small gap on purpose — just 150 units. The real gap is far larger and depends on the quality of the modifiability you build in. And the saving repeats: a second change, a third change — every future change saves again because the code is modifiable. After $N$ changes the comparison reads:

$$N\times C_{\text{without}}>C_{\text{invest}}+N\times C_{\text{with-change}}$$

Here $N$ is the number of changes you expect over the system's life, $C_{\text{without}}$ the per-change cost without the mechanism, $C_{\text{invest}}$ the one-time cost of building it, and $C_{\text{with-change}}$ the cheaper per-change cost once it exists. The larger the expected $N$, the more an upfront investment pays — which is why long-lived systems justify heavy modifiability spending.

Thumb rule for effort. Purely customized software costs $X$. Easily modifiable software costs about three times as much ($3X$). Software usable as a product, steered through parameters, costs about nine times ($9X$). Companies like Salesforce, SAP, and Oracle Apps happily spend even $27X$. Parameter-driven products must serve endless kinds of needs. If you write software without thinking about modification, be prepared: modifiability costs roughly three times. Modifiability often brings parameters: load them, and operations adjust in a simple way.

5.4.2 What Makes Software Testable

Testing costs a lot, and a running system resists it. You may be unable to test without going offline or running on a copy. You cannot test against live data. Building software so it can be tested — that is implementing testability.

Observation usually means logging internal states through loggers.

Modular software is surely more testable. Testability goes hand in hand with modifiability. Many people treat testing as part of modification. So if you build for modifiability, build for testability too. Switchable loggers balance observation against speed.

5.4.3 Testability Scenarios and Measures

Who wants to test? Unit testers, integration testers, system testers, acceptance testers, end users. The scenario reads like the others:

• Stimulus: a set of tests is required — unit, integration, system, acceptance.
• Environment: any time — design, development, compile stage, production, integration, deployment. (The textbook's list runs design, development, compile, integration, deployment, and run time — "production" names the same last setting: the system live in service.)
• Artifact: any system or subsystem may need checking.
• Response: after running the tests you know the faults, so they can be plugged.
• Measures: what share of faults you actually find. How quickly you find them. Whether tests can run while the system stays up. How much effort they take.

Visual picture: imagine a bar chart of paths in a module, one bar per path, height equal to times executed by the test suite. After the 85% run, roughly one bar in six still sits at zero — those silent bars are where undetected faults hide, and the measure tells you exactly how much shadow remains.

5.4.4 Testability Tactics

The goal of a testability tactic: make testing easier, sometimes make it possible at all, keep the cost fair, and let tests find problems. That saves a lot of future time. Two families cover the field: control and observe, and limit complexity.

Limiting complexity means limiting non-determinism — the same input producing different runs — so testing gets less complex and the structure easier to drive. A deterministic component fails the same way twice; a non-deterministic one may hide its fault for weeks.

Control and observe deploys:

• Special interfaces built for testing — set and get methods for key variables, a reset method, a report method returning full state.
• Recorded playback of interactions — capture what crossed an interface, replay it to recreate the fault.
• Kept logs.
• Local storage you can study directly.
• Abstract data sources, so you can create your own data for testing — point the component at a test database or file instead of production.
• Sandboxing: create a setting where a component runs against dummy input and output, isolated so experiments leave no permanent damage.
• Assertions — pre, post, and during execution. Assertions add coding time, but they guarantee boundary values get checked even while the system runs live. Sandboxing and assertions guard boundary values from opposite ends: the sandbox lets you aim tests at the edges safely; assertions keep watching the edges after release.

5.4.5 Design Decisions Applied to Testability

Allocation of responsibility: how will tests execute? Who keeps the logs? Do logs live on a local machine or a central server? Who controls the relevant system states, including recorded runs?

Coordination model: how test suites execute. Which systems support testing. What monitoring links support people with the system. Which channels testing uses. Whether tests run on the server or through remote access.

Data model: shape the data model so data can be studied and tested against. Provide test data that matches the model. Give the model control states, so you can study transitions from state to state. With proper state control, testing verifies that every trigger changes state in the correct order. Regression tests check state transitions in order. You can write and run them whenever the data model has been written down and documented.

Mapping among architectural elements, resources, binding time, and choice of technology round out the set. The same four questions apply once more.

Closing pointers: usability arrives next session, together with the requirements document for architecture. Bring any testing doubts right at the start of that session.

Exam Guidance Summary

Quiz logistics:

• Quiz one runs in a ten-day window; find a half-hour slot inside it. No makeup exists, so fix a slot inside the window if you need one.
• Quizzes are optional — grading survives without them and without assignments — but the midterm and comprehensive exams are required.
• The quiz asks 25 simple questions in 30 minutes. Web lookup is allowed. Fast browsing makes four or five out of it easy to get. Not everything comes from the study material: everything covered in sessions up to the quiz period is fair game.
• Quizzes and assignments are the easiest places to score. The small assignment can be done overnight, and doing it forces a useful review.
• Assignments are solo work. Groups form only for assignment two, which follows the midterm, with online discussion boards for group talk.
• Old question papers come from the exam department, posted when the exam process starts — not from the teaching side.

Answering technique for this lecture's material:

• Modifiability claims must carry measurable yardsticks: days per typical modification with the tactic versus without it.
• For any performance requirement, be ready to name the six scenario parts and pick among the five measures (latency, deadline, throughput, jitter, miss rate).
• For security, keep the vocabulary exact: audit trail (not plain audit), lock computer, and the four tactic verbs detect, resist, react, recover.

Key Industry Applications

Performance in the wild:

• Google Maps samples GPS position. Cutting the rate from ten reads per second to one releases resources on a slow phone. In background mode, one read per five seconds works.
• Netflix keeps its most-watched movies at local providers, so plays avoid long hauls to Amazon's Seattle-side systems.
• MakeMyTrip displays slightly old train seat counts (sourced indirectly from IRCTC) with last-updated timestamps, trading perfect freshness for a pleasurable, responsive screen.
• Banks turn overloaded query queues into pending-reports folders. The reply promises mail delivery; the reports page lists pending items; a PDF awaits download.
• Food-delivery platforms coordinate riders and restaurants by load pattern, moving riders toward shortage areas to cut order-to-door minutes.
• Microsoft ships optimized MVC and MVVM frameworks for communication and presentation; clouds bundle many architecture duties, covered later in the course.

Security in the wild:

• Microsoft Authenticator and Google Authenticator provide OTP-based authentication, including access to Microsoft Teams.
• ATMs layered magnetic stripes, RBI-required OTPs, and app-generated keys, with logs and video footage securing non-repudiation.
• State Bank of India's foreign-exchange systems illustrate strong banking controls discussed around cardless withdrawals.
• Blockchain keeps copies of transaction trails at many places — the audit trail idea taken all the way.
• LDAP servers give one home to identity and sign-in checks for institutional resources.
• RSA keys, two-factor code generators, and OTP providers are selectable security technologies; Indian banking uses 256-bit encryption with bank-supplied functions.

Modifiability and testability economics:

• Salesforce, SAP, and Oracle Apps sell product-grade software steered by parameters. It prices near nine times custom builds; they accept costs up to 27X so buyers can tune freely.
• COBOL and ISAM mark the era when index creation, binary search, and bubble sorts were hand-written. RDBMS products now hide all of it.
• Warehousing services store sealed document trunks for the law-required eight years while scans serve daily work.