By the end of the lesson, you can show on a concrete example where the goals of performance, security, and cost reinforce and where they weaken each other, you know the four viewpoints of a decision, and you know how a decision can be turned into a measurable requirement and a short justification.
Three goals, one system
For an appointment-booking system it is easy to say that the page should be fast, secure, and cheap. The three words, however, do not mean the same thing, and they do not always reinforce each other.
Performance from the user's viewpoint means that the page appears quickly, reacts to a keypress soon, and the important operation does not lag uncertainly (9.4); at system level it also means that the response time must not worsen unacceptably even with many simultaneous requests (10.3).
Security means that the system lets the right person do the right data and operation, while resisting faults and attacks (chapter 8).
Cost is not only the monthly cloud bill: it also includes the developers' time, maintaining complexity, monitoring, customer service, handling incidents, the fees of external services, and the business or social harm of errors.
flowchart TD
D[Design decision] --> P[Performance]
D --> B[Security]
D --> K[Cost]
P --> U[User task]
B --> U
K --> U
When do they reinforce each other, and when must we choose?
Not every decision forces a choice. Compressing needless images, for example, speeds up the page and also reduces cost (less data traffic). In many situations, however, improving one goal asks for resources from another. Four measured examples from the lessons of the course so far:
1. Password storage: the deliberate slowness of security
According to the measurement of lesson 8.6, the slow password hash (scrypt) asks for about 173 ms of processor time per login on one core (3457 ms / 20 tries), whereas the fast SHA-256 takes microseconds. This slowness is the essence of the protection: the attacker also gets only this much per guess. But the server does too: at 100 logins/s this is the continuous load of about 17 cores, that is hardware (cost), and the response time at login (performance) grows too. For the security gain we consciously pay with performance and cost here; and a login limit (10.5) also protects the cost from mass attempts.
2. Encryption: the price of HTTPS
According to the measurement of lesson 4.5, the TLS handshake added about 17 ms to the connection setup with a nearby server. This is small, and a reused connection (4.2) no longer pays it from the second request on. In exchange the traffic is secret and authenticated (4.3). This is the case where the price of security is negligible compared with the value of the protection.
3. Cache: speed and cost, but a privacy risk
According to lesson 10.4, a cache reduces response time and server load (the 304 is cheap), and thereby saves cost too. A badly configured shared cache, however, put Anna's data on Béla's screen. Here the gain in performance and cost risks security and privacy if the rule is imprecise: a cache is not a "speed-up to switch on" but a decision circumscribed by rules: what, for whom, and for how long may it be reused?
4. CDN: proximity, load, and contract
A CDN close to the users can give shorter latency (4.6), and bears the peak better (10.5). In exchange the service may be more expensive and contractually more complex; for sensitive data we must understand which party handles what, in which region, on what legal basis (9.6). The question is not whether the CDN is "good", but whether it is justified for public images, videos, and software files, and what data must not be served through it.
Four viewpoints of a decision
It is useful to ask the same four questions in a design matter:
What is the user impact? How much waiting or how many extra steps are acceptable? For whom does an error cause particularly great harm?
What is the asset to protect and the threat? Personal data, money, an exam result, an authorization, or public content? Who can abuse it? (8.1)
What is the load and operations situation? Constant or periodic traffic? Is there a predictable peak (course registration, ticket sales)? (10.3, 10.5)
What does the whole lifecycle cost? Not only the launch, but also checking, fixing, observing, and later modifying.
This way of thinking helps avoid resounding but empty answers: "let's put everything in the cloud", "let's use microservices", "let's encrypt everything", or "let it be very fast". These sentences make sense only if we say: exactly what, why, against what threat, with what user expectation, and at what cost.
A different decision per function: product list and payment
The product list of a web shop is the same information for many people: product name, image, short description. Such a page can be cached well and served through a CDN (10.4); fast loading reduces server load, so the goals of performance and cost can improve together. The payment process is of a different nature: here a user-bound cart, address, payment state, and order appear (Cache-Control: no-store or private, 10.4). It is unacceptable for an "order successful" page to come from a response stored earlier. For payment it matters more that every request runs validated, loggably, and with an unambiguous result (10.2: idempotency key), even if this means more database operations and a somewhat longer response time.
Good design therefore does not choose a single level for the whole system: it differentiates per function. Public, rarely changing content can be accelerated more aggressively; personal and irreversible operations get stricter checking.
Security that is not only slowing
It is a common misunderstanding that security necessarily slows the system. It has a cost (an encrypted connection, input checking, authorization, logging), but this is generally negligible compared with recovering from a privacy incident or an unauthorized transaction. A secure design sometimes improves performance too: well-defined authorization boundaries and data minimization can reduce how much data must be sent in a response; a properly sized rate limit (10.5) protects the service from faulty or malicious traffic, and so improves the availability for real users. The goal is not to drop protection for speed, but protection that fits the risk.
Cost: cheap is not always economical
For a small university project, infrastructure running in several regions and scaling automatically can be an overkill: a lot of money, learning, and maintenance, while the page is used by a few dozen people a day. A simpler service that is reliably backed up and observed is often the better decision. Conversely, if an exam registration at an exact time attracts several thousand students, the cheapness of an undersized system is only apparent. An outage causes customer-service load, loss of trust, a fairness problem, and extraordinary work; the cost estimate must include the price of the missed service too (10.1: error budget).
Simplicity is also a value. Every new component (a separate database, a message queue, a cache layer, an external identity provider) solves a problem, but brings a new failure possibility, dependency, and knowledge demand. The goal is not to have few technologies, but that every technology should have a clear reason and an owner.
How does a defensible decision come about?
A short decision note is worth a lot. For example: "We cache the responses of the public event list for five minutes (public, max-age=300), because the data is not personal, changes rarely, and peak traffic is expected when registration opens. We do not serve the booking and account pages from a shared cache (private), because they contain personal, fast-changing data." This names the decision, the goal, the risk, and the limit.
Worked example: the decision table of Kurzuspont
Function
Performance
Security
Cost
Decision
Course descriptions (public)
Fast, from the CDN
Not personal
Low (static)
SSG + CDN, public, max-age=300 (6.4, 10.4)
Login
Slow hash: ~170 ms
Strong protection
More processor time
Stays; login limit and separate capacity (10.5)
Enrolment
The server decides, no-store
Intent check (CSRF), authorization
More database operations
We do not speed it up at the expense of correctness (8.4)
Number of free places
Live data, short cache
Not sensitive
High load at opening
A few seconds of cache or SSE (5.5)
Status page
Separate infrastructure
Public
Small
Yes, independent of the main system (10.2)
It can be seen: the decision differs per function, and behind each there is a stated justification.
Common misconceptions
Statement
Clarification
"The fastest solution is always the best."
A fast but faulty, badly protected, or expensive solution is not a good service.
"Security is the job of the security team."
Authorizations, data transfer, and defaults are decided in the design decisions.
"The cloud solves the load automatically."
It can give flexible capacity, but does not fix a faulty query, a bad cache rule, or infinite retrying; capacity produces cost.
"A cache is only a performance optimization."
It is a data-handling rule: it affects correctness and privacy too.
"A compromise means giving up one of the goals."
Often only that protection or acceleration goes to the right place, not everywhere with the same strength.
In brief
Performance, security, and cost sometimes reinforce and sometimes weaken each other: the tried examples (password hash, TLS, cache, CDN) show where.
The four viewpoints of a decision: user impact, asset and threat to protect, load situation, lifecycle cost.
A different decision is needed per function: public content can be accelerated, personal and irreversible operations are stricter.
The goal must be turned into a measurable requirement and a short justification.
Review questions
Why is the slowness of the password hash "worth it", and what does it cost the server?
When is a cache beneficial for performance and cost at once, and when is it risky?
Which four questions do we ask for a design decision?
Performance, security, and cost: trade-offs
Objectives
By the end of the lesson, you can show on a concrete example where the goals of performance, security, and cost reinforce and where they weaken each other, you know the four viewpoints of a decision, and you know how a decision can be turned into a measurable requirement and a short justification.
Three goals, one system
For an appointment-booking system it is easy to say that the page should be fast, secure, and cheap. The three words, however, do not mean the same thing, and they do not always reinforce each other.
flowchart TD D[Design decision] --> P[Performance] D --> B[Security] D --> K[Cost] P --> U[User task] B --> U K --> UWhen do they reinforce each other, and when must we choose?
Not every decision forces a choice. Compressing needless images, for example, speeds up the page and also reduces cost (less data traffic). In many situations, however, improving one goal asks for resources from another. Four measured examples from the lessons of the course so far:
1. Password storage: the deliberate slowness of security
According to the measurement of lesson 8.6, the slow password hash (scrypt) asks for about 173 ms of processor time per login on one core (3457 ms / 20 tries), whereas the fast SHA-256 takes microseconds. This slowness is the essence of the protection: the attacker also gets only this much per guess. But the server does too: at 100 logins/s this is the continuous load of about 17 cores, that is hardware (cost), and the response time at login (performance) grows too. For the security gain we consciously pay with performance and cost here; and a login limit (10.5) also protects the cost from mass attempts.
2. Encryption: the price of HTTPS
According to the measurement of lesson 4.5, the TLS handshake added about 17 ms to the connection setup with a nearby server. This is small, and a reused connection (4.2) no longer pays it from the second request on. In exchange the traffic is secret and authenticated (4.3). This is the case where the price of security is negligible compared with the value of the protection.
3. Cache: speed and cost, but a privacy risk
According to lesson 10.4, a cache reduces response time and server load (the
304is cheap), and thereby saves cost too. A badly configured shared cache, however, put Anna's data on Béla's screen. Here the gain in performance and cost risks security and privacy if the rule is imprecise: a cache is not a "speed-up to switch on" but a decision circumscribed by rules: what, for whom, and for how long may it be reused?4. CDN: proximity, load, and contract
A CDN close to the users can give shorter latency (4.6), and bears the peak better (10.5). In exchange the service may be more expensive and contractually more complex; for sensitive data we must understand which party handles what, in which region, on what legal basis (9.6). The question is not whether the CDN is "good", but whether it is justified for public images, videos, and software files, and what data must not be served through it.
Four viewpoints of a decision
It is useful to ask the same four questions in a design matter:
This way of thinking helps avoid resounding but empty answers: "let's put everything in the cloud", "let's use microservices", "let's encrypt everything", or "let it be very fast". These sentences make sense only if we say: exactly what, why, against what threat, with what user expectation, and at what cost.
A different decision per function: product list and payment
The product list of a web shop is the same information for many people: product name, image, short description. Such a page can be cached well and served through a CDN (10.4); fast loading reduces server load, so the goals of performance and cost can improve together. The payment process is of a different nature: here a user-bound cart, address, payment state, and order appear (
Cache-Control: no-storeorprivate, 10.4). It is unacceptable for an "order successful" page to come from a response stored earlier. For payment it matters more that every request runs validated, loggably, and with an unambiguous result (10.2: idempotency key), even if this means more database operations and a somewhat longer response time.Good design therefore does not choose a single level for the whole system: it differentiates per function. Public, rarely changing content can be accelerated more aggressively; personal and irreversible operations get stricter checking.
Security that is not only slowing
It is a common misunderstanding that security necessarily slows the system. It has a cost (an encrypted connection, input checking, authorization, logging), but this is generally negligible compared with recovering from a privacy incident or an unauthorized transaction. A secure design sometimes improves performance too: well-defined authorization boundaries and data minimization can reduce how much data must be sent in a response; a properly sized rate limit (10.5) protects the service from faulty or malicious traffic, and so improves the availability for real users. The goal is not to drop protection for speed, but protection that fits the risk.
Cost: cheap is not always economical
For a small university project, infrastructure running in several regions and scaling automatically can be an overkill: a lot of money, learning, and maintenance, while the page is used by a few dozen people a day. A simpler service that is reliably backed up and observed is often the better decision. Conversely, if an exam registration at an exact time attracts several thousand students, the cheapness of an undersized system is only apparent. An outage causes customer-service load, loss of trust, a fairness problem, and extraordinary work; the cost estimate must include the price of the missed service too (10.1: error budget).
Simplicity is also a value. Every new component (a separate database, a message queue, a cache layer, an external identity provider) solves a problem, but brings a new failure possibility, dependency, and knowledge demand. The goal is not to have few technologies, but that every technology should have a clear reason and an owner.
How does a defensible decision come about?
A short decision note is worth a lot. For example: "We cache the responses of the public event list for five minutes (
public, max-age=300), because the data is not personal, changes rarely, and peak traffic is expected when registration opens. We do not serve the booking and account pages from a shared cache (private), because they contain personal, fast-changing data." This names the decision, the goal, the risk, and the limit.Worked example: the decision table of Kurzuspont
public, max-age=300(6.4, 10.4)no-storeIt can be seen: the decision differs per function, and behind each there is a stated justification.
Common misconceptions
In brief
Review questions
Learning resources