CAP Theorem and Mobile Architecture

# CAP Theorem and Mobile Architecture

13.1 The CAP Theorem

When one system serves users all over the planet, it makes three promises at once. It wants every reader to see the same data. It wants every request answered. And it wants to keep running even when the network breaks. A distributed system can hold only two of those three promises at any moment. That hard limit is the CAP theorem. Life is full of trade-offs, and a global system lives with this one every day. This section defines each promise, shows why the trio cannot coexist, and walks through real choices made with banks, auctions, chats, and cash machines.

13.1.1 The Three Guarantees

The theorem gets its name from three properties. Learn each one as a promise a system makes to its users.

Consistency means everybody who reads the system sees the same values at the same moment. Deposit money, and somebody anywhere in the world sees your new balance at once if they look right then. One write, visible everywhere, right away. There is exactly one truth, and every server shows it.

Availability means the service answers you when you call. Think of greeting a friend: you say hi, and the friend replies at once, so the friend is available. Now picture a server that wanders off to other work while it waits for your query. It forgets the link it held with you. Next time you connect, it reports you as disconnected. The server logged in, but it was not really available. That is exactly the failure availability tries to prevent. A reply must come back — and it must be a real answer, not silence or a timeout.

Partition tolerance means the system keeps working even when the network splits into islands that cannot talk to each other. The worry is not hypothetical. Private companies laid much of this global backbone. Their contracts never required it to survive physical warfare aimed at IT links. Many cables run underwater. Some nations reportedly can reach deep water and bomb such links. The loss to business could be huge. A partition-tolerant design says: even if a disconnection splits the globe, your service stays up.

The letters C, A, and P stand for these three promises. The theorem states a hard limit on holding them together.

A useful picture is a juggler keeping three balls in the air. At any instant the juggler holds only one ball in a hand. Here you are luckier: you have two hands, so you can hold two of the three balls. You can never hold all three. Consistency, availability, and partition tolerance are those balls.

Draw the idea as a triangle. Put C at the top corner, A at the bottom left, P at the bottom right. Every working system sits on one edge of the triangle, never inside it. An edge means "this pair is kept." The center — all three — is unreachable whenever the network can fail. Takeaway: the question is never "do we support CAP?" but "which edge do we sit on when the cable snaps?"

Every model carries scope limits, and this one has several worth stating before you apply it.

Beginners meet the same traps here again and again.

In the field, this shows up everywhere. Payment networks, airline booking systems, and messaging platforms all publish post-mortems describing the moment they had to pick which promise to drop. Distributed systems engineering is largely the craft of choosing that edge deliberately instead of discovering it during an outage.

13.1.2 Why One Guarantee Must Give Way

Say we demand all three at once: every node sees the same data, no node ever fails to respond, and work continues even when a connection breaks. Walk the logic forward and watch the trio collapse the moment a partition appears.

1. The network splits into two islands, East and West. Messages between them stop.
2. Data A is being read in one partition while data B is being written in the other.
3. Both partitions keep accepting work, so the system looks available.
4. But each island now holds different data. Consistency is gone precisely because we refused to stop either side.

To keep the two islands identical, one of them must refuse requests — giving up availability. To keep answering on both sides, they must accept divergence — giving up consistency. There is no third door. That is the whole proof, and it needs nothing more than a broken link and two users.

A bank makes this concrete. Work through the scenario as it was presented, with real numbers:

Picture the timeline. Draw two boxes labeled East and West with a wire between them. At minute 0 the wire goes dark (mark it with an X). At minute 5 the east box rises to ₹2,500 while the west box stays at ₹500. At minute 6 an arrow labeled "withdraw ₹2,000" hits the west box and bounces off, stamped "insufficient funds." The picture's takeaway: after the X, the two boxes can only drift apart unless one of them stops talking to users.

13.1.3 Picking Your Pair: CP, AP, and CA in Practice

Designers must choose which two promises to keep. The common shorthand labels the pairs CP, AP, and CA, and each pair shapes a different kind of product. Side by side:

Keep consistency and partition tolerance; drop availability. When a particular area misbehaves, lock that node out and declare it not available. Everybody else stays consistent and the system continues. There is a network partition, but the system does not go down. The troubled area is made non-available, so the rest of the world sees correct data. Picture a bank branch whose link fails: there is no service at your branch, while the whole country remains fine. In the early days of bank computerization, each bank ran its own server. Operations inside the branch continued during a break, and staff allowed a limited amount to be withdrawn on trust. With better connectivity, banks centralized, and now a network failure simply means the terminal is down and the system is not available at that counter.

Some ATMs still allow a small emergency withdrawal during a break. This is a calculated risk by the bank, priced and bounded in advance. The reasoning runs:

So designers keep trying such blends of consistency, partition tolerance, and availability. The pairs are poles, not prison cells.

Keep availability and consistency; refuse to tolerate a partition. On its face this makes little sense. The moment a partition appears, you must shut the entire system down worldwide. Yet a case exists. Imagine an online auction where bidders everywhere in the world place bids. If any bidder cannot bid, continuing the auction is pointless. So the operators demand availability and consistency. They accept that a partition forces a full shutdown. Serving a bid from a stale partition would corrupt the auction — imagine selling the same painting twice because one island never heard the winning bid — so no partition is tolerated at all.

One standard-form note belongs here. Textbooks usually say a CA system is possible only while there is no partition — a single-site database is the clean case. The auction design agrees: it enjoys C and A exactly until the network splits, and its plan for that moment is to stop being available everywhere. The lecture's version and the textbook's version describe the same animal from two angles.

Keep availability and partition tolerance; drop consistency. Compare a voice call with a chat message. For a voice conversation the other person must be available at that instant. For chat they need not be. Chat tells you that KKR has won the match. You read the message an hour later, so your knowledge lags the event. The information was not consistent at that moment, but availability held. You opened the chat, pressed enter, and felt connected. The message waits, and your knowledge becomes correct only after you read it. That waiting state has a name, and the next subsection covers it.

13.1.4 Eventual Consistency and Shared Ledgers

A student question pinned down the classic confusion about plain databases, and the answer opens the door to the compromise most banking designs actually take.

Banking wants all three promises, so designers reach for a compromise that many people dislike hearing aloud: eventual consistency. The phrase means "at the end of the day, we are okay." Instant agreement is traded for guaranteed agreement later.

Walk through the transfer case with the compromise in place:

The mental model is a messaging app, and it is worth spelling out.

Blockchain enters here as related knowledge. In brief: blockchain keeps multiple transaction logs, maintained by all stakeholders. Every party holds the trail instead of trusting one central copy. That shared-log idea supports designs that want all three promises at once, settling for eventual agreement — each participant's copy may lag during a break, but the logs converge to one history.

This compromise has boundaries worth respecting.

Real-world: banks have responded to partition risk by centralizing hard. If your bank runs one central system, a lost link locks you out completely. There is no second server in another zone to keep serving a stale balance. Momentary internet breaks between zonal servers were the price of the older distributed design.

13.1.5 Case Study: The One-Time Password That Always Expired

Small implementation bugs teach big architecture lessons, and this one unfolded abroad. While staying in Canada for most of a year, the account holder used an Indian bank's one-time password (OTP) flow for every transaction. Each OTP arrived already timed out — the moment it landed, the window to use it had closed. Complaints came back saying the bank saw no problem. Then the real cause emerged:

The lesson generalizes beyond one bank. When you convert between time zones, convert the date-time as one unit, not just the clock hour. Treating date and time as a single value avoids this entire bug class.

Location restrictions were not the culprit — the bank allowed transacting from abroad, so there was no blanket location bar. Some banks do apply an IP cap or location cap for KYC (Know Your Customer, the identity-verification duty banks owe regulators) checks. Governments add their own rules: Indian regulation insists data about Indian users be kept locally. International service providers are being asked to hold that data inside the country.

13.1.6 Questions and Answers on CAP Choices

Two more questions from the session rounded out the picture — one architectural, one about design intent.

That answer deserves a second reading. Notice what it does: it never claims to beat the theorem. It redefines the goal from "consistent right now" to "consistent, provably, by settlement time," and lets the time-stamped log carry the proof.

13.2 Mobile Apps: Three Ways to Build

Mobile devices are tiny, crowded, always-moving computers. Architecture for them starts from their constraints. Three build styles dominate — native apps, web apps, and hybrid apps — and each trades performance against reach in a different way.

13.2.1 What Makes Mobile Design Different

Several pressures shape every mobile design decision:

• Processing power. Many apps and services compete for the phone's CPU. You would never pile this much concurrent load onto a desktop — yet the phone juggles sync jobs, location updates, and your game at once.
• Memory. Proper use of memory matters greatly. Some handsets carry a fancy amount of RAM and ROM. Yet apps keep becoming resource hungry, so memory stays a challenge. When memory runs low, the operating system may kill background apps or drop cached data without asking.
• Storage. The architect decides among local storage, remote storage, files, a database, or a remote service. These are design decisions, not defaults — and they decide how the app behaves when the network disappears.
• Layering. A wide variety of vendors provides the service at each layer. Layers cost performance, but the work is spread across so many stakeholders that layers cannot be avoided.
• Connectivity. A mobile cannot work without connectivity, and the activity expected from the tiny machine keeps growing. Wireless links also cost battery power, so every unnecessary round trip is paid twice — in latency and in charge.
• Platform spread. Programs must adjust themselves to the platform they meet. "Mobile" does not even mean only phones. Some such devices sit fixed in place, part of plant equipment or part of a car.

The constraint list is already visible in homes, which makes it concrete:

The reference literature adds one more pressure worth naming: battery life is usually the most limiting factor of all. Backlighting, wireless radios, and processor speed all drain it, so designs batch communications and defer nonessential work until the device is plugged in. A desktop architect can ignore power; a mobile architect cannot write a single line without meeting it.

13.2.2 Native Apps

Native apps come supplied by the manufacturer of the device. The camera app, the telephone dialer, the calendar, the clock, the contact manager, and Apple's Health app are the standard examples. Other apps call these built-ins to do their work. A chat app borrows the contact manager to address a message. You generally cannot remove a native app. You can only disable it, because the hardware is incomplete without these programs handling basic functions. Makers tune them per machine: Samsung writes native apps that squeeze the best out of Samsung hardware.

Languages follow the platform. On iOS you write in Swift or Objective-C. On Android the early language was Java, and the platform has since fallen in love with Kotlin, a simpler language to use. Android Studio, the official development tool for Android, has made building very easy indeed.

Performance is the native app's crown. These apps are written by the people who own the machine, so they use the full capability of the hardware. No other style beats them on speed or feel. They also work when the network does not — a native app keeps running offline and syncs later, something a pure web page cannot promise.

A student question drew the boundary of the term precisely:

Real-world: because native apps bind to one platform, a product like Google, Facebook, or LinkedIn must ship a separate version for each operating system. Each version needs its own team, its own release cycle, and its own store review before an update reaches users.

13.2.3 Web Apps

Web apps are HTML and CSS pages that run in whatever browser the phone offers — Chrome, Edge (which grew out of IE), Opera, any of them. Every mobile provides a browser. It fetches pages, renders CSS and HTML, and reaches services living outside the device.

Their strengths are deployment and reach. A web app is easy to deploy, and one common code base runs anywhere. Supporting the browser is the hardware provider's job. Once the hardware supports the browser, it supports any app that runs inside it. You summon the app through a URL, and nothing sits on the local machine. Updates reach every user the moment the server changes — no download prompts, no version skew across the user base.

Their weakness is capability. A pure web app touches no device hardware beyond what the browser allows — the page is sandboxed inside the browser, so the camera, accelerometer, and contacts stay out of reach unless the browser opens a specific door. Many functionalities are simply unavailable. They also age badly at both ends: many web apps stop working on old browser versions, and new hardware refuses old browsers.

13.2.4 Hybrid Apps and Progressive Web Apps

Hybrids begin as web apps that grow local muscle. Some HTML apps download components that run locally. At that point they become hybrid — a blend of HTML, native pieces, and developer-written code. Every form of the mix exists. An app can open a browser inside itself and show pages there. That embedded surface is the WebView, and what runs inside it is really a web component. An app can also call native apps. The contact manager on Android is more or less standard, so a hybrid borrows the contact store rather than rebuilding it.

Two vocabulary terms frame the idea:

One of the earliest hybrids seen in India came from IndiaBulls, a financial services provider:

Where do hybrids sit on speed? Slower than native, better than web apps — with a twist. Sometimes a hybrid performs worse than a pure web app. It emulates the web app inside itself, and that emulation adds one more layer. Hybrids carry their own handle, their own socket to run on. You write them to run across platforms. Yet parts turn platform-specific whenever they lean on natives of one platform. They inherit native limitations along with some native benefits.

13.2.5 Comparing the Options and Wiring to the Backend

Put the three styles side by side:

Whichever style you pick, the client reaches the backend along familiar roads. The mobile client speaks HTTPS to a web server. The web server calls a web service, typically a RESTful service. It returns JSON data, or XML in any form, back to the browser or application. The business layer behind the service reaches the data. A second road skips the intermediate server. The client goes over HTTPS straight to a RESTful web service, which lands the data in cloud storage, with JSON flowing throughout. Hybrids combine both worlds — native capabilities on the device, web-service access on the wire.

13.3 Building Blocks of a Mobile Application

Every mobile app, whatever its style, is assembled from a small set of runtime parts: fragments, activities, services, content providers, broadcast receivers, and intents. Learn these six and the platform stops feeling magical.

13.3.1 Activities and Fragments

The basic component you build with is the fragment. A fragment is a reusable piece of a screen — a chunk of interface with its own layout and behavior. Fragments build up into screens. Every event creates an activity, and activities cause interaction with the user. An activity is the platform's unit of one focused user session: a single screen the user is consciously working with. Every control — every interactive unit — owns its own life cycle. The developer's job includes integrating those life cycles into one well-behaved app.

Concretely, the duties are:

Why so much ceremony around one screen? Because on a phone, interruption is normal. A call arrives mid-form; the user rotates the device; memory runs low and the system quietly discards the backgrounded screen. An activity that saved its state at each pause comes back exactly as the user left it. One that did not throws away the typed text — and users delete apps like that.

13.3.2 Services, Content Providers, and Broadcast Receivers

Three more parts run behind or beside the screen, each solving a different sharing problem.

A service runs in the background with no interface. Mobile devices thrive on background services. The download of files by Google Play happens in the background using file APIs. A service can also reach a remote server while the user does something else — syncing mail, uploading photos, tracking a delivery. The user keeps scrolling; the service keeps working.

A content provider is a shared door to data. The contact manager exposes the address book through a content provider, and any authorized app can read it. On Android the contacts themselves live in SQLite, and the integration is genuinely pleasant — contacts line up with your calendar and plans. Long-time phone users recall how hateful early contact managers were. The SQLite era made working with contacts a pleasure. The provider pattern means every app reads contacts through one standard doorway instead of each keeping its own private copy of your friends' numbers.

A broadcast receiver listens for announcements. One application broadcasts a message saying it wants to send. The choice of all registered receivers appears, and you can set one as the default. The receiver you picked receives the broadcast information and acts on it.

13.3.3 Intents: Direct and Broadcast

An intent is a package carrying all the data required for an activity to take place. It moves that data from one activity to another so the second activity can do its job. Think of it as a self-addressed envelope: contents inside, destination written on the front. Intents come in two kinds, and the difference is addressing.

A direct intent is addressed to one particular activity. You want to send a message with your SMS sender, so you call that sender directly and send.

A broadcast intent is addressed to nobody in particular. Every service registered on the mobile that can handle that type of intent becomes available in a queue, and you either pick one or set a default. Opening a document shows the pattern: would you use MS Office, would you use a PDF reader, would you use Adobe? The chooser appears, you select, and if you set a default, the next direct intent can route straight there.

13.3.4 Worked Example: From Pulse Alarm to Doctor Consultation

Chain the parts together and a complete workflow falls out. Follow the pulse-monitoring scenario step by step:

A second mapping, suggested as a self-study exercise, breaks a ride-hailing app into the same vocabulary. The Uber app decomposes roughly as follows:

13.4 Responsive Design and Local Storage

Two design skills decide whether a mobile app feels professional. The interface must reshape itself for every screen. And the app must choose what data lives on the device versus the far end.

13.4.1 Responsive versus Adaptive Design

Adaptive design is the older idea: the layout adapts to various things, often by snapping between preset templates. The server (or the page) detects which class of device is asking and serves one of several fixed arrangements. Responsive design goes further — the interface senses the environment and responds, creating its arrangement to fit. There are no presets to snap between; the pieces reflow continuously.

The working parts:

• A flexi grid control underlies the layout. Its layout manager arranges the pieces by itself, filling the screen in fitting shares.
• Content shrinks, hides, or moves as space demands.
• Media queries determine the screen size and steer the rules that apply. A media query is a CSS test such as "does this screen have at most 320 pixels of width?" — if yes, load the compact stylesheet.
• Grid width is specified as a percentage of screen size rather than in pixels, so the same grid fills a tablet edge-to-edge and shrinks gracefully on a phone.
• Images are flexible: image size is a percentage of grid size, so pictures scale with the grid automatically.

The contrast deserves a table:

Real-world: Bootstrap and Drupal carry this approach to huge audiences. Drupal in particular has been a mainstay web technology for quite some time. A responsive UI built this way contacts a web server over a RESTful API, and the architect again chooses what to cache locally.

One boundary from the reference literature keeps expectations honest:

13.4.2 SQLite: A Database in Your Pocket

The storage split follows a simple rhythm. For quick refresh of the screen and for temporary data, keep things in local SQL. When you need major data, fetch it from the remote server. When your work is done and must persist, you commit it — click a button, and the data stores into the main storage.

The shopping cart shows why the split pays:

The local engine of choice is SQLite. It behaves very much like Microsoft SQL Server: the same statements largely work. Experience with MSSQL transfers directly, and MySQL experience mostly carries over too, though MSSQL is the closer cousin. SQLite is an open-source engine, lightweight and very efficient, and it supports virtually complete RDBMS facilities. It has become the top choice for mobile apps.

The habit extends past phones: televisions, refrigerators, and other appliances use SQLite for local storage. Even your phone's contact manager keeps its data in SQLite on Android — the same engine you met in the content provider discussion two topics ago.

13.5 Layers Inside a Mobile Platform

Look under the apps and a mobile platform is a disciplined stack of layers, each wrapping the one below. The layering looks expensive, and it is — but removing it costs more.

Picture the stack as an office building drawn top to bottom: user applications occupy the penthouse; below them the framework floor splits into a browser wing and a native wing; below that the core apps; then the Android runtime with its virtual machine; then the Linux kernel with its drivers; and the hardware occupies the basement. Each floor only ever talks to the floor directly beneath it.

13.5.1 Hardware, Kernel, and Device Drivers

At the base sits hardware — thousands of variants worldwide, from phones to fixed industrial units to components inside cars. Around the hardware wraps a layer familiar from Linux and Unix: the kernel. The kernel is the innermost layer of software, and it gives the outside world the appearance of one unified device.

Each physical component needs a device driver, written uniquely for that piece of hardware. The driver's code is custom-built, but its interface is standard, so callers need no special knowledge. Today's storage is normally a solid-state device rather than a spinning disk. It too is reached through a driver, as are the keyboard, the screen, memory, and the other input/output paths.

What does the kernel actually manage? File management, process management, memory management, and input/output handling. Every running process is handled by the kernel. Inside, the kernel keeps internal servers — small servlets performing certain functions — and external servers handle work from outside.

13.5.2 Core, Framework, and User Applications

Above the kernel sit the core apps: the functions commonly required by a wide variety of people. The core defines the ecosystem — the Android ecosystem on one family of devices, the iPhone ecosystem on another.

Above the core lies the framework, divided into two major parts. The browser framework gives you the browser. The native framework supports the native apps. User apps run on top: web apps on the web framework, native apps on the native framework, and hybrids straddle both.

Why tolerate so many layers? Each hop costs performance. A designer tempted to merge layers for speed should run the thought experiment:

The hardware platform contributes the CPU, the graphic processing unit, the display, location sensing, connectivity, camera, sensors, and multimedia devices. All of it sits inside the same kernel-plus-drivers base described above.

History backs the layers up too. People have tried to encroach on each other's areas to squeeze out performance. But the work involved grows too big, and they ward off — let the database handle the work of the database. Over the years, a range of products tried to hand you the user interface, the business logic, and the database in one box. Access still tries, even now, though it moved toward an architecture where you could connect to a Jet engine — separating database management into its own compartment. Quicksilver, Clipper, FoxPro, and the earlier dBase walked the same all-in-one road. To a point they coped. Then systems outgrew that shape, and people saw that the interface and the database had to part ways. A famous pairing stepped in: PowerBuilder for the interface, Sybase for the database. Sybase gave Oracle a real run for its money, and ordinary medium-sized companies picked up the habit this whole topic formalizes — separation of concerns: give each kind of work its own layer, so each can evolve alone.

Other complete stacks exist besides Android and iOS. Tizen is a separate environment, standing alongside the Android, iPhone, and Microsoft ecosystems. At one time Motorola used Tizen; its current status is uncertain, but it illustrates that the layered recipe repeats across platforms.

13.5.3 The Android Stack and the Dalvik Machine

Zoom into Android and the layers acquire names. At the bottom sits the Linux kernel with its drivers. Then comes the hardware abstraction, then the core. Above that comes the Android runtime. Where the Linux world had the JVM (the Java virtual machine), Android has the Dalvik virtual machine. Dalvik is nothing more nor less than a version of the JVM meant for Android. Alongside it ride the core libraries.

The purpose of a runtime is to provide a common interface for applications to run and a common appearance over everything below. Its second gift is compilation discipline: you do not compile to the machine. You create byte code, and the virtual machine runs the byte code. That arrangement suits late-binding apps very well. Behavior can settle at run time rather than build time — the same byte code adapts to whatever device it lands on, which matters when the basement hardware differs across thousands of models.

13.5.4 Cloud Services and Multi-Tenancy

Pull the lens back and the mobile architecture turns out to lean massively on the ecosystem of cloud vendors. The mobile reaches popular cloud services to deliver a polished user experience. The phone is one end of a distributed design, not an island. Reference material covers several scenarios: ways of deploying in the cloud, a context diagram, and multi-tenant application architecture at a high level.

It deserves its own treatment and returns in detail later in the course. The high-level picture here is enough to recognize it when it reappears: many tenants on shared infrastructure, isolation guaranteed by the platform rather than by separate copies.

13.6 Professional Judgment: Tools, People, and Lifelong Learning

Technology alone settles nothing. The people wielding it decide the outcome. This closing thread ties the session's tools to the careers that will use them.

13.6.1 Why Tools Alone Are Not Enough

The Agile Manifesto says it directly: tools are good, but you require good people to handle the tools. A fly-by-wire aeroplane without the right pilot is destined to crash. Technology is not the danger — misuse of technology is. The mature path is to use powerful tools well, and make the world better rather than worse.

The same honesty applies to assistance tools at work. In companies, people routinely use search engines and AI to work out how to handle code. Defect management is another common use. That is legitimate. What fails is copying without understanding.

So use the knowledge these tools give you, but apply your own mind. The tool can fetch an answer in seconds; only you can tell whether the answer fits the problem, the platform, and the client's constraints. That judgment is the part no search engine ships with.

13.6.2 Knowledge Has a Short Shelf Life

Across a 45-year working life, one rule held without exception: knowledge older than five years could not sustain you. Not once. Expectations climb, and users want more mature, more stable products. A product even five years old looks dated. A five-year-old WhatsApp, Facebook, Instagram, MS Teams, or Chrome would embarrass itself on sight. Survival of the fittest, in Darwin's phrase, describes the skills market exactly.

A money analogy makes the point stick:

Continuous learning and application of current technology are not optional extras — you are expected to keep up. One caution tempers the chase. You need not gamble on the absolutely newest release unless it falls inside your area of expertise. But you must be up to date.

Exam Guidance Summary

• Quiz questions are rapid-fire multiple choice. Either you know the answer or you do not, and the goal is overall understanding, not a perfect score. There is no partial credit to chase and no essay to structure — recognition speed is the skill being sampled.
• Expect questions outside the taught topics — deliberately. Some items test whether you can apply architectural judgment to material never covered in class; the same out-of-syllabus sampling applies to everybody. The habit being tested is reasoning from trade-offs, not recall of slides.
• The question pool holds about 100 items, with at least half newly written, and each attempt draws a random sample, so no two attempts align. Preparing from a friend's question list buys little; preparing the concepts buys everything.
• Grading is relative, not absolute: a low percentage does not mean a poor grade, and papers are moderated before grades are assigned. Learners have earned top grades with 20–25% scores in hard papers.

A practical study order falls out of this lecture's own structure: master the three guarantees and the pair-picking logic first, then the mobile build styles as a comparison table, then the six building blocks through the pulse-monitor trace, and finally the layer stack bottom-up.

Key Industry Applications

• Banking partition strategy. Zonal servers keep branches available during network splits, at the cost of temporary inconsistency. Centralized banks choose consistency and accept full outage on link loss. The same choice now separates legacy core-banking designs from modern cloud ones.
• ATM risk pricing. Limited emergency withdrawals (one, two, or five thousand rupees) against stale balances are a designed, bounded risk, not an accident. Risk teams set the ceiling the way an insurer sets a deductible.
• Blockchain-style shared logs. Multiple stakeholders maintaining transaction logs support designs that want all three CAP promises, settling for eventual agreement. Trade-finance consortia and settlement networks reuse exactly this pattern.
• Time zone correctness. Converting date-time as one unit prevents the expired-OTP bug class; KYC-driven IP or location caps and data-localization rules constrain banking apps across borders. Any global service issuing time-limited tokens inherits this test checklist.
• Smart appliances. Camera-equipped refrigerators inventory food, suggest orders, and checkout through Amazon with one click — mobile architecture principles in a kitchen shell.
• Thick-client revival. IndiaBulls delivered desktop-like trading through a downloaded browser component, an early form of today's progressive web applications; current trading platforms follow the same recipe with service workers.
• Per-platform shipping. Products like Google, Facebook, and LinkedIn maintain separate native builds per operating system, while web competitors ship one code base — the build-style trade-off made visible in release calendars.
• Component-based apps. Ride-hailing apps such as Uber decompose into screens, broadcast receivers, services, databases, and configuration files wired by intents — the six-block vocabulary applied at industry scale.
• SQLite everywhere. Phones, contact managers, televisions, and refrigerators rely on the same lightweight local engine, which is why SQL skills transfer into embedded work.
• Background services. Google Play's file downloads and app sync run as background services through file APIs — the reason large updates finish while the phone appears idle.