System Design (High-Level Design) Module 18 – Delivery, multi-region, disaster recovery and cost
First-hand case: how MySmartCoPilot is built
MySmartCoPilot as a case study: pages and on-device tools in front, a PHP backend with MariaDB, jobs, an outbox and an AI gateway, and its budgets.
What you will learn
- Choose where each kind of work runs, on the visitor's device or on the backend, and give the reason
- Split a backend's data into database groups by what one transaction changes together
- Design a transactional outbox so that a message leaves only after its change commits
- Plan a backend release whose rollback cannot change payments or signing keys
- Choose abuse protection rather than a cap for a public endpoint
Before you start
What you’ll learn · Before you start
What you will learn
- Choose where each kind of work runs, on the visitor's device or on the backend, and give the reason
- Split a backend's data into database groups by what one transaction changes together
- Design a transactional outbox so that a message leaves only after its change commits
- Plan a backend release whose rollback cannot change payments or signing keys
- Choose abuse protection rather than a cap for a public endpoint
Before you start
On this page
A visitor who converts a 50 MB phone video on MySmartCoPilot, the site this lesson is on, never uploads it: on the 75th-percentile connection in India the upload alone would take more than three minutes. The site is a full frontend and backend website, and its first rule is to put each piece of work where it is quickest and safest: on the visitor’s device when it can be, on the backend when it must be shared, kept or paid for.
The site’s real architecture has the pages and on-device tools in front; a PHP 8.4 backend behind Apache, with MariaDB in seven groups, scheduled jobs and an outbox, and an AI gateway; and the budgets it keeps.
The architecture in one picture
The pages are built ahead of time and served by Apache as files: a tool page, a lesson, and the scripts and styles
they share. What a page does happens in the browser. Tools work on the visitor’s files there, and the site’s about
page says that almost all of them do (About MySmartCoPilot). Behind /api/ runs a
PHP 8.4 backend with MariaDB: accounts and sign-in, payments and licences, email through the host’s own mail service,
Shop, Play and Learn services, and the AI gateway. The whole of it, from the device down:
MySmartCoPilot's architecture, from the device down
Text description of the diagram
Eight boxes joined by arrows, from the visitor's device at the top to the outside services at the bottom.
- The visitor's device holds the pages, the tools that work on local files, and on-device AI. - An arrow labelled "page views" leads from the device to Apache on the host, which serves the built pages, scripts and styles. - An arrow labelled "Run, inside a frame" leads from the device to the sandbox origin, where code a learner runs executes. - An arrow labelled "calls that need the server" leads from the device to the PHP 8.4 backend under /api/: accounts, payments, Shop, Play, Learn and the AI gateway. - From the backend, an arrow labelled "one transaction per change" leads to MariaDB in 7 groups: main, shop, shoplog, stats, logs, jobs and cache. - The scheduled jobs, the jobs tick every 5 minutes, read what waits in the database ("reads what waits") and send email through the host's mail service ("sends email"). - The backend calls outside services, payment providers and AI providers ("payments, AI questions"), and the payment providers answer with webhooks ("payment webhooks").
Follow four requests through it, from a tool page to a question for the AI:
The drawing shows the whole scene; its 9 steps are listed below.
Every step as text
- A tool page. The device asks for a tool page. Apache sends the built page and its scripts as files, so no PHP runs and no database is read.
- The page arrives. The page comes back with the scripts and styles that every page of the site shares.
- The file stays here. The visitor drops a 50 MB video on the tool. The browser converts it on the device, so the file is never uploaded.
- A code example. In a lesson, Run starts the code in a frame on the sandbox origin, still on the device, where it cannot read the main site's data.
- A checkout. A checkout needs the backend. PHP writes the order, and the message it must send, to MariaDB in one transaction.
- The payment. The payment provider takes the payment and tells the backend with a webhook, which the backend checks before it acts.
- The jobs tick. Every 5 minutes a scheduled job sends the messages that wait, by email through the host's own mail service.
- An AI question. A question for the AI goes to the backend's gateway, which asks an outside AI provider and falls through to the next one if the first cannot answer.
- The answer. The gateway passes the answer back to the device, and the visitor never sees which provider gave it.
The program below prices what the design avoids: sending the visitor’s file to a server and the result back, on the 75th-percentile connection in India, which an annual study of device and network performance puts at 2.1 Mbit/s up and 6.2 Mbit/s down (The Performance Inequality Gap):
# Why heavy media work stays on the visitor's device: the time a server would need just to receive a file and send the
# result back, on the 75th-percentile connection in India (2.1 Mbit/s up, 6.2 Mbit/s down, the cited measurement).
# The result is assumed to be as large as the file. Worked on the device, the network time is 0.
UP_MBIT_S = 2.1
DOWN_MBIT_S = 6.2
FILES = (("photo", 5), ("phone video", 50), ("long video", 500)) # name, megabytes
def seconds(megabytes: float, mbit_s: float) -> float:
return megabytes * 8 / mbit_s
print(f"{'file':<12}{'size':>7}{'upload':>9}{'download':>10}{'in all':>10}")
for name, size in FILES:
up, down = seconds(size, UP_MBIT_S), seconds(size, DOWN_MBIT_S)
total = up + down
shown = f"{total / 60:.1f} min" if total >= 60 else f"{total:.0f} s"
print(f"{name:<12}{f'{size} MB':>7}{f'{up:.0f} s':>9}{f'{down:.0f} s':>10}{shown:>10}")
print("on the device: 0 s on the network, and the file never leaves it") Output
file size upload download in all photo 5 MB 19 s 6 s 25 s phone video 50 MB 190 s 65 s 4.2 min long video 500 MB 1905 s 645 s 42.5 min on the device: 0 s on the network, and the file never leaves it
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 upload_or_device.py
Runs on this device, in your browser. The first run downloads Python (about 13.5 MB), which is kept for the next runs.
Your run, in this browser
A photo costs 25 s of network time, a phone video 4.2 minutes and a long video 42.5 minutes before any server has done any work. On the device that time is zero, and the promise of each tool page, that files stay with their owner, holds by construction. The rest of the lesson takes each part apart; in one sentence each:
- On the device first: tools, code examples and on-device AI run in the browser, so files never travel.
- Separate origin (web): The scheme, host and port of a web address, such as https://mysmartcopilot.com. Browsers keep each origin's storage and cookies apart, so a page on one origin cannot read another origin's data.: code a learner runs and the sign-in cookies each live on an origin of their own.
- Seven database groups: data is split by what one transaction changes together, and a group grows by adding a database.
- An transactional outbox: A table written in the same transaction as a change, holding the message that change must send. A separate job reads it and sends each message, so a message leaves only for a change that committed.: a change and the message it must send are written in one transaction, and a scheduled job sends it.
- Releases with a way back: the backend switches to a new release in one step, and back only when that is safe.
- No caps of its own: the AI gateway falls through to the next provider, and abuse protection takes the place of quotas.
Key idea
Put each piece of work where it is quickest and safest: on the device when it can be, on the backend when it must be shared, kept or paid for.
Checkpoint
Check: Where each piece of work runs
On the device first: files, code and models that stay put Pro: opens with a Pro, Premium or Ultimate pass
In this part:
- Seven database groups, split by what changes together
- The outbox: a message leaves only after its change commits
- Releases, backups and checks on a clock
- No caps of its own, and the limits that stay
- Practise: relay an outbox
- Relay an outbox in order, and receive each message once
- Interview questions
- When should a website do a piece of work on the visitor's device, and when on its backend?
- Your learning site lets visitors run Python and JavaScript in the browser. Explain why that code runs in a sandboxed iframe on a separate origin rather than on the main site, and what can still go wrong.
- A checkout saves the order and then sends the licence email from the same request. Support reports two problems: some customers got an email for an order that does not exist, and some paid orders never sent one. Explain both, and redesign the flow.
- One MariaDB database holds accounts, orders, licences, a product catalogue, usage statistics and logs, and the statistics and logs grow by millions of rows a month. Split it so that a payment stays atomic and fast-growing data never crowds the money tables. Say where each kind of table goes and how each group grows.
- Your site's AI features have no quota of their own, but every outside provider behind them has its own daily allowance and its own failures. Design the gateway so that visitors keep getting answers, and say what protection it still needs.
- Key takeaways
4 diagrams · 1 runnable example · 1 exercise with sample tests · 4 interview answers · about 51 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Terms in this lesson
- at-least-once delivery
- A delivery guarantee under which every message arrives but some may arrive more than once, after a retry, so the receiver must recognise and drop the copies.
- origin (web)
- The scheme, host and port of a web address, such as https://mysmartcopilot.com. Browsers keep each origin's storage and cookies apart, so a page on one origin cannot read another origin's data.
- shard
- One of several databases that together hold a group's data, each with its own share of the rows, such as the accounts of one set of customers and everything that belongs to them.
- transactional outbox
- A table written in the same transaction as a change, holding the message that change must send. A separate job reads it and sends each message, so a message leaves only for a change that committed.
References
- About MySmartCoPilot (MySmartCoPilot)
- The Performance Inequality Gap (Infrequently Noted (Alex Russell))
- The iframe element: the sandbox attribute (MDN Web Docs (Mozilla))
- Same-origin policy (MDN Web Docs (Mozilla))
- Transactional outbox pattern (Amazon Web Services (Prescriptive Guidance))
- mariadb-dump (the --single-transaction option) (MariaDB)
- OWASP API Security Top 10: API4, Unrestricted Resource Consumption (OWASP Foundation)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress