Mobile developers evaluate the architecture in three dimensions.
|Distribution of Responsibility||Testability||Ease of Use|
|Cocoa MVC||❌ VC are coupled||❌||✅⭐|
|MVP||✅ Separated View Lifecycle||✅||Fair: more code|
|MVVM||✅||Fair: because of View’s UIKit dependant||Fair|
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.
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.
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.
It is similar to MVP but binding is between View and View Model.
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
KV cache is like a giant hash map and used to reduce the latency of data access, typically by
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.
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.
There are still chances for dirty cache in this pattern. It happens when these two cases are met in a racing condition:
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.
Eliminates the metadata overhead by aggregating hundreds of thousands of images in a single haystack store file.
index file (for quick memory load) + haystack store file containing needles.
index file layout
haystack store file
Disclaimer: All things below are collected from public sources or purely original. No Uber-confidential stuff here.
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.
The key is to have an async design, because payment systems usually have a very long latency for ACID transactions across multiple systems.
A blockchain is an incorruptible distributed ledger that is…
Hardware: computer resources = computing + networking + storage
Basic Utils: P2P network + crypto + data storage w/ db or filesystem
Ledger: chain of data blocks + domain-specific data models
Consensus: write first consensus later (PoW/PoS/DPoS) / consensus first write later (PBFT)
Smart Contract: limited program running on the blockchain
API: RPC + SDK
dApps: 1) transfer of values 2) data certification 3) data access control
DevOps: deployment, operations, metrics, logs
Energy and resources
Technology, media, and telecom
Consumer and industrial products