Putting it together, then going mobile

Not a full system-design exercise (no schemas or traffic math) — just how the course's concepts apply to a real service. Google Maps offers satellite imagery, route planning, live traffic, and an API for map-based games like Pokémon Go; it began as C++ desktop software and evolved over years into a service for a billion+ users. The design choices fall out of a few properties:

Server-side rendering of map tiles

A search matches text to a location and pulls its coordinates — then those numbers become an image. Render on the server, because the image is static and identical for all users, so it can be cached. Crucially, the map is broken into tiles, not one big image, so the system renders only the part the user engages with — which is what makes zoom and pan cheap (you've seen the map refresh in sections, not full-page).

UI: JavaScript + HTML5 (or React/Angular/Vue); OpenLayers is a popular open-source map UI library. Real-time features (live traffic, alternative routes) need a persistent connection but are resource-intensive with a hard cap on concurrent connections — so implement them only when truly required.

This case study is the mirror image of the mapping service — it's transaction-heavy, so it makes the opposite choices.

Two ways to handle the concurrent rush

• Message queue. Queue all ticket-buy requests and process them FIFO (the concurrency technique from the message-queue chapter).
• Database locks + caching. Use the correct transaction isolation level so only one transaction accesses a resource at a time (only possible with an ACID DB like MySQL). And mirror the e-commerce pattern: the ticket counts shown while browsing are inconsistent cached values; only at checkout does the system poll the DB for the accurate count and lock the resource for the transaction. Caching (Redis, Memcached, Hazelcast) absorbs the browsing load.

Roughly 60–70% of users now access online services on mobile — thanks to accessibility (always in your pocket) and intuitive interfaces (no tech-savvy required). Businesses shifted from web-first to mobile-first. The course traces it through gaming: Facebook social games like Farmville (Zynga's freemium hit, ~15–20% of Facebook's earnings at its peak) gave way to mobile games as smartphones improved — studios saw better retention and higher MAU/DAU on mobile, so games went mobile-first, then mobile-only (Clash of Clans). Today the Facebook game store is deserted; mobile-only giants like Instagram, TikTok, and Pokémon Go run on billions of users, and the Play Store alone has 2B+ monthly actives and 3.5M+ apps.

There's no one-size-fits-all — research your niche before writing an app. Mobile may dominate overall, but not for every business: the author's own tech site gets ~80% desktop traffic and thrives with no app. An app carries real cost (possibly a dedicated mobile team) and a steep learning curve — handheld devices are battery-powered with limited CPU, storage, RAM, data, and user patience, demanding a different mindset than cloud web apps.

What to research before deciding

• How do users of similar businesses access their service — app, website, or both? If they have an app, how many downloads, and what are their traffic/discovery sources?
• What's the revenue split by platform? (Often inferable from traffic even when not public.)
• What kind of service is it? A meal-tracking health app is naturally mobile-first (you won't open a laptop to log lunch); a read-heavy content site may be mobile-friendly.

A responsive website adapts to any screen size — "content should be like water, taking the shape of the vessel it's poured into." With so many screen sizes (phones, tablets, smart TVs, watches, Kindles, IoT devices), maintaining a dedicated UI per device is impossible, so responsive is the default. Two design directions: mobile-first (design for small screen, adapt up) and web-first (design for large screen, adapt down).

How to build one without being a designer: use a CSS framework. Bootstrap (or Tailwind) is a production-grade open-source framework with pre-built CSS, JS features, typography, forms, buttons — assemble a grid of rows and columns and plug elements in. Bootstrap was originally written at Twitter for UI consistency across internal tools, then open-sourced; its learning curve is under a week if you know some frontend. Other options: jQuery Mobile (now declining as modern browsers do the same with vanilla JS), Skeleton, HTML5 Boilerplate, Less Framework.

"Mobile app" here means apps downloaded from an app store. There are two types.

Why hybrid exists — and its catch

Native's biggest pain is cross-platform cost: every OS needs its own dedicated app, team, and tech, with no common ground and no guarantee a new OS won't appear. Hybrid solves this with "write once, run everywhere" on web skills developers already have — one codebase across platforms, saving time and money. The catch: hybrid isn't as smooth as native (the middle layer adds lag), and several companies reverted to native after trying it:

• Airbnb spent ~two years on React Native, then abandoned it — performance issues (init, render, navigation, dropped frames), many patches needed, and JavaScript's lack of type safety made scaling and refactoring hard.
• Udacity dropped React Native due to rising Android-specific feature requests, high long-term maintenance cost, and UX inconsistency across platforms.
• Facebook (2012) called betting too heavily on HTML5 over native its "biggest mistake" — a dated example, but instructive.

A reliable heuristic either way: look at what businesses in your niche used to build their apps, and see if it's viable for you to do the same.

A PWA looks and feels like a native app but runs in mobile and desktop browsers — and can be installed straight from the browser (via a "+" in the address bar), not the app store. Once installed it runs in its own window with no address bar or tab, just like a native app. Built with open web tech (HTML, CSS, JS, and frameworks like Angular, React, Ionic, Google Polymer), so there's no native learning curve — write once, run everywhere.

Why businesses prefer PWAs over responsive sites: normally a business funnels search traffic through its responsive mobile site, then tries to redirect users to its native app — a PWA gives the native-app experience directly in the browser, with optional install. PWAs access the OS and hardware, work offline, support push notifications, are indexable by search engines and shareable by link, and always show the latest version (no manual updates).

MBaaS is a cloud model that runs your app's entire backend infrastructure, so you focus only on business logic and UI. Beyond logic and UI, a real service needs authentication, social integration, push notifications, a real-time database, caching, storage, messaging/chat, third-party integrations, analytics, crash reporting — an MBaaS provides all of these, each via an API your code calls directly. Popular: Google Firebase, AWS Amplify, Parse (Parse was the early leader, bought and shut down by Facebook).

This is the PaaS story that let solo/indie developers bootstrap: generous free tiers mean you can deploy, get early users and feedback, and pitch investors without paying for hosting — and skipping infrastructure management cuts development time sharply.

When to use it: great for mobile-only services with no existing custom backend — mobile games, messaging, to-do apps. Because there's no server you control, all business logic lives on the client (a fat/thick client ). Caveats: if you later need server-side logic, you'll have to build a custom backend or a serverless function; you can also mix MBaaS with a custom backend (e.g. a banking app verifying against a legacy enterprise system). And the big risk — vendor lock-in: if the provider shuts down (like Parse), stops upgrading (security holes), stops adding features, or changes billing, you're stuck.

These two chapters cite many external links. Below are the ones that resolve live, grouped by topic. A few cited links returned server errors or blocked automated access and are omitted (noted in the footer).

Case-study concepts

Responsive & mobile foundations

Native vs. hybrid — the retrospectives

PWAs in production