Exam practice

Scaling up is using a bigger computer (more cores, memory, faster disks). Advantage: simple, the program doesn’t change.
Scaling out is adding more ordinary computers that share the work. Advantage: no upper limit except money, and losing one of many computers hurts little.
Services with millions of users scale out because no single computer is big enough for them, the biggest are very expensive, and one computer is a single point of failure.

No. The database is the bottleneck: every request waited for it, and the web servers already had room to spare, so doubling them changes nothing.
Advice (any two, with reasons): put a cache in front of the database, since published results never change and the same results and pages are looked up many times; make every result page in advance as a ready file, so lookups don’t touch the database at all; give the database more capacity, or split it into shards by symbol number, or add follower copies to share the reading; use a content delivery network for the pages that are the same for everyone; load-test before results day; publish results through other channels too (SMS, several websites) so the load is spread.

• a.Volume: years of orders and locations from many thousands of customers and riders are more than one database computer can hold or search quickly. Velocity: rider locations arrive every few seconds, all day, and orders in bursts at lunch and dinner. Variety: carts, menus with different fields, locations and links between customers are very different shapes of data.
• b.The cart: key–value, since it is always looked up by one key, the customer, and only needs to be fast. The dishes: document, since each dish can carry its own fields (spice level, size, a set meal’s items) without one fixed table. Rider locations: wide-column, built for huge numbers of writes in time order, kept sorted by rider and time. Who orders from the same restaurants: graph, since the question is about links between customers and restaurants, a few steps out.

• a.A transaction is a group of changes to a database that is treated as one: either all of them happen, or none of them do.
• b.BEGIN starts the transaction. Then the two changes: take Rs. 1,000 from Ram’s balance, add Rs. 1,000 to Sushma’s. COMMIT ends the transaction and makes both changes permanent. If either change fails, ROLLBACK ends it and undoes every change since BEGIN, so both balances are as they were.
• c.Without a transaction, the first change is already kept: Ram has lost Rs. 1,000 that Sushma never received. With a transaction, the transfer was never committed, so the database rolls it back when it restarts: Ram still has his Rs. 1,000, and the transfer can be tried again. This is atomicity: all or nothing.

a. One possible order:

Both print a ticket, but the record names only Bishal: Gita’s write was overwritten. This is a lost update, which breaks the isolation of the two transactions.

• b.With record locking, a transaction locks the seat’s record before reading it. Clerk 1 locks it first, reads it, writes Gita and commits, which releases the lock. Clerk 2 tries to lock the same record and must wait until then; when it reads the record, it finds Gita’s name and says “sold out”. Only that record is locked, so other bookings carry on.
• c.A deadlock: two transactions each hold a lock the other is waiting for (clerk 1 has seat A7 and wants A8; clerk 2 has A8 and wants A7), so neither can go on. Databases detect it and roll one transaction back, releasing its locks so the other can finish; the rolled-back one is tried again. (Also accepted: transactions wait while others hold locks, which slows the system, so locks are held as briefly as possible.)

When copies can’t reach each other (a network partition), a copy asked to make a change can either refuse until it can reach the others, keeping every copy the same (consistency), or accept it and pass it on later, so the service keeps working (availability). It can’t have both: this is the CAP theorem.
For a bank balance, it must refuse on the side without a majority: if both sides accepted payments, each might see enough money, and together they could spend money that isn’t there (Rs. 1,000 spent twice as Rs. 700 + Rs. 700).
For likes, it should keep answering: each side counts the likes it gets, and when the link is back the counts are simply added. A count a few seconds behind harms nobody.

A cache keeps copies of answers that were costly to get, close to where they are needed, so the next request for the same answer is quick.
A hit is a request answered from the cache; a miss is one the cache doesn’t have, which is fetched from the real source and then kept. The time to live is how long a copy is kept before it is fetched again, so it doesn’t get too stale.
A balance changes with every payment and must be exactly right, so a cached (possibly stale) copy could show money that has been spent. A published result never changes, so any copy is always right.

The video company runs a content delivery network: edge servers in many places, some of them inside internet companies’ networks, including Nepal’s. The first time someone in that network asks for the video, the edge server fetches it from abroad and keeps it in its cache; every later viewer nearby gets it from that copy, quickly and without crossing the border again. DNS (or anycast) sends each phone to the nearest edge server.
This works because the internet is a network of networks: each internet company is its own network and makes its own agreements. The video company and the Nepali internet company both gain (faster videos for viewers, less costly traffic abroad), so they agree to put the cache servers inside the Nepali network, with nobody running the whole internet needing to arrange it.

Any three:

During the fault every request fails, and each app tries again, so when the database is fixed the service gets its 1,400 new requests a second plus all the tries again: several times what it can answer. Overloaded, it wastes work on requests whose users have given up, so it gets even less done; most requests fail again, and their tries again keep the load high. The overload sustains itself after its cause is gone.
Defenses (any two): exponential backoff with jitter (wait longer before each try, a random part of the limit, and give up after a few tries); circuit breakers (stop calling a failing service for a while); shedding load and rate limits (turn excess requests away at once so the rest succeed); keeping spare capacity, so the service can climb out; letting users back in slowly after a big failure.

What users saw: for up to about 14½ hours from 19–20 October 2025, apps and websites around the world that used AWS’s Northern Virginia region failed or worked badly.

The cause: a race condition in the automation that kept the DNS records of DynamoDB, AWS’s database service, up to date. A slow copy of the program wrote an old plan over a newer one after another copy had started cleaning up old plans; the clean-up deleted the plan in use, leaving the database’s name with no addresses, so nothing could find it.

How it spread: the system that manages EC2’s servers depended on DynamoDB; when it came back, the system tried to renew all its records at once and collapsed under the load, so no new servers could start; then delays in the network’s records made health checks remove healthy servers from load balancers.

What was changed: the DNS automation was turned off everywhere until fixed; limits were put on how much capacity health checks can remove at once; new tests of the recovery; incoming work limited by queue length.

Hours in a year: 365 × 24 = 8,760.
The computers: 30,000 kW × 8,760 h = 262,800,000 kWh = 262.8 GWh.
Electricity of the whole building: 1.2 × 262.8 GWh ≈ 315 GWh a year.
Water: 1.5 L/kWh × 262,800,000 kWh = 394,200,000 L ≈ 394 million liters a year.
Share of Upper Tamakoshi: 315 ÷ 2,281 ≈ 0.14, about 14%.

In January 2023 a denial-of-service attack from abroad overloaded the GIDC, and more than 400 government websites went down for hours. Immigration at Tribhuvan airport lost its computers, so passports and visas were checked by hand and flights abroad were delayed by up to three hours. Affected were travelers and their families, airlines, immigration officers, and anyone who needed a government service that day. They were affected not because they used the GIDC themselves, but because services they depended on all shared it: one data center was a single point of failure for many services.
Suggestions (any three, with reasons): keep copies in a second place that can take over (Hetauda’s disaster recovery center is a start, if it can run services and not only keep backups); give critical services like immigration a way to keep working on their own for a while (graceful degradation); defend against floods of requests with a content delivery network or anti-denial-of-service service, rate limits and shedding load; split services into cells so one attack or fault doesn’t take down all; publish blameless reports after each incident so the lessons are learned.

A good answer names groups and reasons, not just “good” or “bad”. Gain: the company and its users anywhere; the district through taxes and a few jobs; the electricity company. Might pay: farmers and households downstream, if the data center evaporates the river’s water in the dry months; neighbors, if electricity becomes scarce or dearer. Why them: the costs fall where the building is, while its users live anywhere, and local people have little say. Evidence wanted: its power in MW and its expected PUE; its cooling design and WUE, and water use month by month, especially in the dry season; where its water and electricity come from; how many local jobs it would really create; whether the company will publish these numbers every year. A fair decision might require cooling that uses little water, limits in dry months, or payment towards the community’s water supply.