Why Should We Care About Architecture?​

The answer is: to reduce the human resources spent on each feature.

Mobile developers evaluate the quality of an architecture on three levels:

1. Whether the responsibilities of different features are evenly distributed
2. Whether it is easy to test
3. Whether it is easy to use and maintain

	Responsibility Distribution	Testability	Usability
Tight Coupling MVC	❌	❌	✅
Cocoa MVC	❌ V and C are coupled	❌	✅⭐
MVP	✅ Independent view lifecycle	✅	Average: more code
MVVM	✅	Average: View has a dependency on UIKit	Average
VIPER	✅⭐️	✅⭐️	❌

Tight Coupling MVC​

For example, in a multi-page web application, when you click a link to navigate to another page, the entire page reloads. The problem with this architecture is that the View is tightly coupled with the Controller and Model.

Cocoa MVC​

Cocoa MVC is the architecture recommended by Apple for iOS developers. Theoretically, this architecture allows the Controller to decouple the Model from the View.

However, in practice, Cocoa MVC encourages the use of massive view controllers, ultimately leading to the view controller handling all operations.

Although testing such tightly coupled massive view controllers is quite difficult, Cocoa MVC performs the best in terms of development speed among the existing options.

MVP​

In MVP, the Presenter has no relationship with the lifecycle of the view controller, allowing the view to be easily replaced. We can think of UIViewController as the View.

There is another type of MVP: MVP with data binding. As shown in the figure, the View is tightly coupled with the Model and Controller.

MVVM​

MVVM is similar to MVP, but MVVM binds the View to the View Model.

VIPER​

Unlike the three-layer structure of MV(X), VIPER has a five-layer structure (VIPER View, Interactor, Presenter, Entity, and Routing). This structure allows for good responsibility distribution but has poorer maintainability.

Compared to MV(X), VIPER has the following differences:

1. The logic processing of the Model is transferred to the Interactor, so Entities have no logic and are purely data storage structures.
2. ==UI-related business logic is handled in the Presenter, while data modification functions are handled in the Interactor==.
3. VIPER introduces a routing module, Router, to implement inter-module navigation.

Why Is Such a Protocol Needed?​

Mobile video playback services using HTTP Live Streaming encounter the following issues:

1. ==Limited memory and storage on mobile devices==.
2. Due to unstable network connections and varying bandwidth, there is a need to ==dynamically adjust video quality during transmission==.

Solutions​

1. Server Side: In a typical setup, encoding hardware receives audio and video input, encodes it into H.264 format video and AAC format audio, and then streams it out in MPEG-2 format.
   1. A software multiplexer then splits the raw output stream into a series of short media files (with lengths possibly around 10 seconds in .ts format).
   2. The multiplexer also maintains an index file (.m3u8 format) that contains a list of all media files.
   3. The generated media files and index file are published on a web server.
2. Client Side: The client reads the index, sequentially requests the necessary media files from the server, and smoothly plays the content of each short media file.

Architecture​

Why Does Facebook Handle Its Own Photo Storage?​

• Petabyte-scale volume of blob data
• Traditional NFS-based designs (where each image is stored as a file) face metadata bottlenecks: massive metadata severely limits metadata hit rates.
  • Here are the details:

For photo applications, most metadata, such as image permissions, is useless, wasting storage space. However, the larger overhead is that the metadata of the file must be read from disk into memory to locate the file itself. While this is negligible for small-scale storage, when multiplied by billions of photos and several petabytes of data, accessing metadata becomes a throughput bottleneck.

Solution​

By aggregating hundreds of thousands of images into a single Haystack storage file, the metadata burden is eliminated.

Structure​

Data Layout​

Index file (for quick memory loading) + Haystack storage file containing many images.

Index file layout

Storage file

CRUD Operations​

• Create: Write to the storage file, then ==asynchronously== write to the index file, as indexing is not a critical step.
• Delete: Perform soft deletes by marking the deleted bits in a flag field. Execute hard deletes through compacting operations.
• Update: During updates, only append (append-only); if a duplicate key is encountered, the application can choose to update and read the key with the maximum offset.
• Read: Read operations (offset, key, backup key, cookie, and data size)

Use Cases​

Upload

Download

Traditional wisdom tells us that losing trust happens quickly, while gaining trust takes time. However, this is not entirely true. The renowned British mentalist Derren Brown, in his reality show "Derren Brown: The Push," utilized various psychological techniques to lead a kind-hearted ordinary person to commit a horrific murder by pushing an elderly man off a building—all within 72 minutes.

The protagonist of the story is Chris, a mild-mannered, sunny young man. Although he appears to be just an average person, he was meticulously selected for the experiment due to his strong tendency to conform to social pressures. Chris was unaware of the experiment's true purpose, as the production team informed him that he had not been selected, which allowed him to let his guard down. The team arranged for someone to impersonate a high-ranking executive from a charitable organization to contact Chris's company about a collaboration and invited him to help organize an event. To quickly establish authority, the event featured numerous celebrity endorsements, and Chris was tasked with serving drinks, carrying bags, and handling clothing to train his sense of obedience.

Then the incident began. With only the executive and Chris present, a wealthy old man suddenly "died." The executive persuaded Chris to consider the bigger picture and asked him to help hide the body, which he did. Later, the event host mistakenly thought Chris was the wealthy old man and called him to the stage to speak, and he complied. The executive instructed Chris to move the body, and he followed suit. Eventually, the old man's wife mentioned that he had a condition that made him appear dead during episodes, which relieved both the executive and Chris. Unexpectedly, the production team arranged for the old man to "wake up" and, using a recording device from his pocket, he "learned" everything that had happened since his "death," threatening to expose the two and refusing to donate a penny to the charity. In the end, fearing for his job and potential imprisonment, the executive urged Chris to eliminate the old man by pushing him off the edge of the platform. However, he… did not comply. In fact, Chris was the only one of the four participants who did not obey the "murder" command.

The fact that the other three "murderers" complied so quickly illustrates how rapidly trust can be established, allowing individuals to follow orders to the extent of committing murder.

So how is trust built? Psychologists have long had the answer: ==Trust equals competence plus approachability==. For instance, in the aforementioned murder-inciting reality show, the executive presented himself as sophisticated and high-status, and the entire charity event was backed by social elites.

Here, ==“competence” does not require someone to genuinely be competent; it merely requires them to appear competent==. For example, using a lot of jargon when speaking can make one sound like an expert. A more superficial method is appearance—driving a luxury car and wearing cufflinks can help people remember you. The key is appropriateness; don’t wear a suit and tie to a garage to fix someone’s car, and don’t show up in flip-flops and shorts to give a speech at a charity gala.

Another effective way to enhance perceived competence is through consistency between words and actions; no one will trust a hypocrite. If I lived in the world of "The Smiling, Proud Wanderer," I would certainly trust the honest rogue Tian Boguang, rather than the pretentious hypocrite Yue Buqun.

Competence, or "credibility," can be mutually reinforced between individuals and organizations. Both people and organizations can increase their credibility by joining exclusive associations, and when high-credibility individuals and organizations join, the association's credibility rises even higher. I feel that there is an old Chinese saying, "A flower-laden sedan chair is carried by people," which may express this very idea. The most direct product of mutual credibility is money; the easier it is to establish credibility through interaction, the more people trust each other, leading to increased transactions and a higher overall economic level in society.

Many national leaders give an impression of being "competent," yet are quite cold. To enhance public trust, each U.S. president adopts a dog. For instance, Obama had never owned a dog before moving into the White House, and his daughter Malia was even allergic to dogs, but he felt compelled to get one. After all, few things can make people feel as approachable as a furry, tail-wagging, wide-eyed dog.

This is the power of "approachability." A professor at Harvard conducted an experiment and found that on rainy days, when borrowing a phone from a stranger at a bus stop, simply saying, "I apologize for the rain," before making the call increased the likelihood of success fourfold. Research has shown that ==no matter how exaggerated the apology may be, this method consistently promotes cooperation in real life==.

In fact, ==to convey approachability, the way you speak is often more important than the content of your speech, and body language is more significant than verbal language==. Sitting closer, leaning forward, shaking hands, patting shoulders, and touching elbows can all powerfully express the intention to cooperate. ==When it comes to trust, face-to-face communication is extremely important==. I have a classmate from Yale who, after receiving an offer from Uber, directly negotiated his salary with his boss and ended up discussing it all the way to the director level, securing several thousand shares of stock!

Beyond these two dimensions, what other methods can enhance trust? The answer is exposing minor weaknesses. For example, "accidentally" dropping a pen, "accidentally" telling a bad joke, or "accidentally" spilling coffee.

Competent individuals can consciously make small mistakes or reveal minor secrets to appear more relatable. In a previous MBA program at Columbia University, there was an executive student who intentionally included typos in her emails to seem more approachable, and her relationships with colleagues genuinely improved. This explains why Japanese employees enjoy getting drunk together after work and then singing karaoke off-key. The worse you perform, the deeper your bond with friends becomes.

Of course, revealing weaknesses must be done carefully. ==Before exposing weaknesses, people must recognize that you are genuinely competent==. Additionally, ==the weaknesses must be trivial==. A surgeon with shaky hands or a quarterback with butterfingers are not minor weaknesses; they are serious flaws.

In summary, ==Trust = Competence + Approachability + Exposure of Minor Weaknesses==. To be trusted, you must first be worthy of trust; you need to be competent. Not only must you be competent, but you also need to establish a connection with the other party, which requires you to appear approachable. Once trust is established, if you appear overly competent or too perfect, it can create a sense of distance and threat, so you must also expose minor weaknesses to bridge the gap with others.

Why bother with architecture?​

Answer: for reducing human resources costs per feature.

Mobile developers evaluate the architecture in three dimensions.

1. Balanced distribution of responsibilities among feature actors.
2. Testability
3. Ease of use and maintainability

	Distribution of Responsibility	Testability	Ease of Use
Tight-coupling MVC	❌	❌	✅
Cocoa MVC	❌ VC are coupled	❌	✅⭐
MVP	✅ Separated View Lifecycle	✅	Fair: more code
MVVM	✅	Fair: because of View's UIKit dependant	Fair
VIPER	✅⭐️	✅⭐️	❌

Tight-coupling MVC​

For example, in a multi-page web application, page completely reloaded once you press on the link to navigate somewhere else. The problem is that the View is tightly coupled with both Controller and Model.

Cocoa MVC​

Apple’s MVC, in theory, decouples View from Model via Controller.

Apple’s MVC in reality encourages ==massive view controllers==. And the view controller ends up doing everything.

It is hard to test coupled massive view controllers. However, Cocoa MVC is the best architectural pattern regarding the speed of the development.

MVP​

In an MVP, Presenter has nothing to do with the life cycle of the view controller, and the View can be mocked easily. We can say the UIViewController is actually the View.

There is another kind of MVP: the one with data bindings. And as you can see, there is tight coupling between View and the other two.

MVVM​

It is similar to MVP but binding is between View and View Model.

VIPER​

There are five layers (VIPER View, Interactor, Presenter, Entity, and Routing) instead of three when compared to MV(X). This distributes responsibilities well but the maintainability is bad.

When compared to MV(X), VIPER

1. Model logic is shifted to Interactor and Entities are left as dumb data structures.
2. ==UI related business logic is placed into Presenter, while the data altering capabilities are placed into Interactor==.
3. It introduces Router for the navigation responsibility.

KV cache is like a giant hash map and used to reduce the latency of data access, typically by

1. Putting data from slow and cheap media to fast and expensive ones.
2. Indexing from tree-based data structures of O(log n) to hash-based ones of O(1) to read and write

There are various cache policies like read-through/write-through(or write-back), and cache-aside. By and large, Internet services have a read to write ratio of 100:1 to 1000:1, so we usually optimize for read.

In distributed systems, we choose those policies according to the business requirements and contexts, under the guidance of CAP theorem.

Regular Patterns​

• Read
  • Read-through: the clients read data from the database via the cache layer. The cache returns when the read hits the cache; otherwise, it fetches data from the database, caches it, and then return the vale.
• Write
  • Write-through: clients write to the cache and the cache updates the database. The cache returns when it finishes the database write.
  • Write-behind / write-back: clients write to the cache, and the cache returns immediately. Behind the cache write, the cache asynchronously writes to the database.
  • Write-around: clients write to the database directly, around the cache.

Cache-aside pattern​

When a cache does not support native read-through and write-through operations, and the resource demand is unpredictable, we use this cache-aside pattern.

• Read: try to hit the cache. If not hit, read from the database and then update the cache.
• Write: write to the database first and then ==delete the cache entry==. A common pitfall here is that people mistakenly update the cache with the value, and double writes in a high concurrency environment will make the cache dirty.

==There are still chances for dirty cache in this pattern.== It happens when these two cases are met in a racing condition:

1. read database and update cache
2. update database and delete cache

Where to put the cache?​

• client-side
• distinct layer
• server-side

What if data volume reaches the cache capacity? Use cache replacement policies​

• LRU(Least Recently Used): check time, and evict the most recently used entries and keep the most recently used ones.
• LFU(Least Frequently Used): check frequency, and evict the most frequently used entries and keep the most frequently used ones.
• ARC(Adaptive replacement cache): it has a better performance than LRU. It is achieved by keeping both the most frequently and frequently used entries, as well as a history for eviction. (Keeping MRU+MFU+eviction history.)

Who are the King of the cache usage?​

Facebook TAO

Motivation & Assumptions​

• PB-level Blob storage
• Traditional NFS based desgin (Each image stored as a file) has metadata bottleneck: large metadata size severely limits the metadata hit ratio.
  • Explain more about the metadata overhead

For the Photos application most of this metadata, such as permissions, is unused and thereby wastes storage capacity. Yet the more significant cost is that the file’s metadata must be read from disk into memory in order to find the file itself. While insignificant on a small scale, multiplied over billions of photos and petabytes of data, accessing metadata is the throughput bottleneck.

Solution​

Eliminates the metadata overhead by aggregating hundreds of thousands of images in a single haystack store file.

Architecture​

Data Layout​

index file (for quick memory load) + haystack store file containing needles.

index file layout

haystack store file

CRUD Operations​

• Create: write to store file and then ==async== write index file, because index is not critical
• Read: read(offset, key, alternate_key, cookie, data_size)
• Update: Append only. If the app meets duplicate keys, then it can choose one with largest offset to update.
• Delete: soft delete by marking the deleted bit in the flag field. Hard delete is executed by the compact operation.

Usecases​

Upload

Download

Disclaimer: All things below are collected from public sources or purely original. No Uber-confidential stuff here.

Requirements​

• ride hailing service targeting the transportation markets around the world
• realtime dispatch in massive scale
• backend design

Architecture​

Why micro services?​

==Conway's law== says structures of software systems are copies of the organization structures.

	Monolithic ==Service==	Micro Services
Productivity, when teams and codebases are small	✅ High	❌ Low
==Productivity, when teams and codebases are large==	❌ Low	✅ High (Conway's law)
==Requirements on Engineering Quality==	❌ High (under-qualified devs break down the system easily)	✅ Low (runtimes are segregated)
Dependency Bump	✅ Fast (centrally managed)	❌ Slow
Multi-tenancy support / Production-staging Segregation	✅ Easy	❌ Hard (each individual service has to either 1) build staging env connected to others in staging 2) Multi-tenancy support across the request contexts and data storage)
Debuggability, assuming same modules, metrics, logs	❌ Low	✅ High (w/ distributed tracing)
Latency	✅ Low (local)	❌ High (remote)
DevOps Costs	✅ Low (High on building tools)	❌ High (capacity planning is hard)

Combining monolithic ==codebase== and micro services can bring benefits from both sides.

Dispatch Service​

• consistent hashing sharded by geohash
• data is transient, in memory, and thus there is no need to replicate. (CAP: AP over CP)
• single-threaded or locked matching in a shard to prevent double dispatching

Payment Service​

==The key is to have an async design==, because payment systems usually have a very long latency for ACID transactions across multiple systems.

• leverage event queues
• payment gateway w/ Braintree, PayPal, Card.io, Alipay, etc.
• logging intensively to track everything
• APIs with idempotency, exponential backoff, and random jitter

UserProfile Service and Trip Service​

• low latency with caching
• UserProfile Service has the challenge to serve users in increasing types (driver, rider, restaurant owner, eater, etc) and user schemas in different regions and countries.

Push Notification Service​

• Apple Push Notifications Service (not quite reliable)
• Google Cloud Messaging Service GCM （it can detect the deliverability) or
• SMS service is usually more reliable

We all know that Donald Trump is a very unconventional American president. Regardless of his political achievements, we cannot deny that his speeches are highly engaging. His persuasive power is discussed in detail in Scott Adams' book, “Win Bigly”, and I find it particularly interesting that he has a penchant for giving his opponents nicknames—he is truly a nickname enthusiast.

For instance, he refers to Hillary as “Crooked Hillary,” and others include “Little Marco,” “Lying Ted,” and “Low-Energy Jeb.” Looking at the following image from Jeb Bush's speech, where the audience appears to be dozing off, I think Trump has a point.

The importance of names is such that they can even determine life and death. A 13-year-old girl from Minnesota, Rachel Ehmke, took her own life after being bullied and called a “slut.” This is not an isolated case; researchers at Syracuse University found that when people use derogatory terms to refer to a certain social group, the suicide rate among that group tends to be higher.

Words can be frightening; when faced with harsh words, we must learn to protect ourselves. There are generally three ways to deal with derogatory terms: the first is to ignore them. Of course, if it were that easy to ignore, we wouldn't need to pay extra attention to them. The second is to eliminate them. For example, Facebook's COO Sheryl Sandberg believes the word “bossy” should be banned. ==Banning a word widely and comprehensively is quite difficult, so there is a third option: to change it. This strategy is common in business, such as when “ValuJet Airlines” was renamed “AirTran Airways” after a series of accidents.==

In addition to these three methods, there is a more advanced approach, and the key is that ==the meaning of a name is not fixed; you can proudly reclaim the use of derogatory terms==. This reclamation can unite members within an organization, and it can even create an exclusive zone. For instance, the term “negro” can be used by Black individuals but not by white individuals; Jeremy Lin can use the ID ChiNkBaLLa88, but ESPN cannot use “chink in the armor.”

Names are a very important weapon; they can harm people or unite them. Israeli researchers conducted an experiment with the same game: when it was called “Community Game,” 72% of participants chose to cooperate, while when it was called “Wall Street Game,” only 33% chose to cooperate.

This ==technique of controlling feelings through names== can be applied in practical work. Researchers at Harvard found that when people face stressful activities like public speaking, singing competitions, or math contests, if they can cheer for themselves and say out loud, “I am excited!” they often achieve their best performance.

The insight here is that ==giving an appropriate name to your inner feelings to channel emotions, rather than avoiding them, is the best way to process and utilize emotions==. If we can correctly understand the source of negative emotions, for example, “I feel angry coming home today because work was really frustrating,” we won't take our bad mood out on friends and family, avoiding actions that would hurt those we care about.

What is blockchain?​

A blockchain is an incorruptible distributed ledger that is…

1. Hosted by multiple parties
2. Secured by crypto algorithms
3. Append-only/immutable and thus verifiable in data storage

How does it work?​

Categorization: Public vs. Private vs. Hybrid Blockchains​

• Public: It is permission-less to join the network.
• Private: The permission to join is centrally controlled.
• Hybrid: Multi-parties control the permission to join.

Do you need a blockchain?​

Architecture​

Hardware

Basic Utils

Basic Utils

Ledger

Ledger

Concensus

Concensus

Smart Contract

Smart Contract

APIs

APIs

dApps

dApps

Dev

Ops

[Not supported by viewer]

1. Hardware: computer resources = computing + networking + storage

2. Basic Utils: P2P network + crypto + data storage w/ db or filesystem

3. Ledger: chain of data blocks + domain-specific data models

4. Consensus: write first consensus later (PoW/PoS/DPoS) / consensus first write later (PBFT)

5. Smart Contract: limited program running on the blockchain

6. API: RPC + SDK

7. dApps: 1) transfer of values 2) data certification 3) data access control

8. DevOps: deployment, operations, metrics, logs

Industries​

1. Financial Services

   • crypto exchange: binance, coinbase, etc.
   • international payments: ripple, stellar, etc.
   • Know Your Customer (KYC) / anti-money laundry (AML): civic

2. Health care

   • sharing data across providers, insurers, vendors, auditors, etc

3. Public sector

   • asset tokenization
   • transparent voting in public election

4. Energy and resources

   • trading
   • sharing data across suppliers, shippers, contractors, and authorities

5. Technology, media, and telecom

   • DRM and incentivizing content creator
   • securing operations and data storage of IoT devices

6. Consumer and industrial products

   • loyalty points programs in traveling
   • document signing
   • supply-chain management

Case Study: Ripple for Cross-border Payments​

• Partnering with 200+ banks
• 47 trillion dollar cross-border payments market
• Huge hassles and costs. A large number of businesses cannot afford the high transaction fee of traditional cross-border payments.
  • Without ripple, it may take days to fulfill the transaction in some African countries
    1. Quote the exchange rate
    2. Find the path in those hops
    3. Lock the quote
    4. Validate, KYC, AML, etc…
  • With ripple, users in country A buys ripple tokens, pay with ripple, and then users in another country just withdraw. It just takes a few minutes and during which the token price will not fluctuate much.

Killer Apps​

• Graphite Docs: Similar to Google Docs but everything is encrypted when data leaves your computer.
• Textile Photos: Phone App like a private Instagram. Photos are encrypted and stored on IPFS, a decentralized storage network running by the community.
• Augur: Web App where people can bet on predictions on many things.
• Blockstack: Tools for developers to build DApps.
• D.Tube: Video streaming service that is add-free but content creators are rewarded by tokens. Similarly ThetaNetwork for e-sports videos.
• OpenBazaar: Online marketplace with no platform fees, powered by cryptocurrency.

Challenges​

• Network Effects. It is hard to convince users leaving existing well-established centralized services.
• Privacy vs. Free Services. Would people like to buy services with crypto? Or would people like to sacrifice privacy for free services?
• Efficiency in decentralized systems. Complex and decentralizes systems vs. simple and centralized systems.