Compare commits
11 Commits
04440b29de
...
7446bc2ff7
| Author | SHA1 | Date |
|---|---|---|
Huy Le
|
7446bc2ff7 | |
|
huylenq
|
7af3de718b | |
|
huylenq
|
4347e376cf | |
dgolant
|
a07e261677 | |
Iheb Haboubi
|
2d8231663f | |
Anand
|
e161b2a516 | |
Chetan Nair
|
7e8f93e57d | |
Kian-Meng Ang
|
7a094cec63 | |
mleers
|
79364dbbdc | |
Nnachevvv
|
578e29cff8 | |
Lawrence Chou
|
e8a867ee28 |
|
|
@ -61,7 +61,7 @@ See [Translations](TRANSLATIONS.md).
|
|||
|
||||
### Adding translations to new languages
|
||||
|
||||
Translations to new languages are always welcome! Keep in mind a transation must be maintained.
|
||||
Translations to new languages are always welcome! Keep in mind a translation must be maintained.
|
||||
|
||||
* Do you have time to be a maintainer for a new language? Please see the list of [translations](TRANSLATIONS.md) and tell us so we know we can count on you in the future.
|
||||
* Check the [translations](TRANSLATIONS.md), issues, and pull requests to see if a translation is in progress or stalled. If it's in progress, offer to help. If it's stalled, consider becoming the maintainer if you can commit to it.
|
||||
|
|
|
|||
|
|
@ -966,7 +966,7 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、
|
|||
* [キーバリューデータベース](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [キーバリューストアの欠点](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redisアーキテクチャ](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [メムキャッシュアーキテクチャ](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [メムキャッシュアーキテクチャ](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### ドキュメントストア
|
||||
|
||||
|
|
@ -1712,7 +1712,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
83
README-vi.md
83
README-vi.md
|
|
@ -1570,7 +1570,7 @@ Whenever you query the database, hash the query as a key and store the result to
|
|||
|
||||
### Caching at the object level
|
||||
|
||||
See your data as an object, similar to what you do with your application code. Have your application assemble the dataset from the database into a class instance or a data structure(s):
|
||||
See your data as an object, similar to what you do with your application code. Have your application assemble the dataset from the database into a class instance or a data structure(s**:
|
||||
|
||||
* Remove the object from cache if its underlying data has changed
|
||||
* Allows for asynchronous processing: workers assemble objects by consuming the latest cached object
|
||||
|
|
@ -1583,24 +1583,32 @@ Suggestions of what to cache:
|
|||
* User graph data
|
||||
|
||||
### When to update the cache
|
||||
### Khi nào cache được cập nhật
|
||||
|
||||
Since you can only store a limited amount of data in cache, you'll need to determine which cache update strategy works best for your use case.
|
||||
Bởi cache chỉ chứa một lượng dữ liệu giới hạn, bạn cần xác định một chiến lược cập nhật cache phù hợp với nhu cầu.
|
||||
|
||||
#### Cache-aside
|
||||
|
||||
<p align="center">
|
||||
<img src="images/ONjORqk.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Source: From cache to in-memory data grid</a></i>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Nguồn: From cache to in-memory data grid</a></i>
|
||||
</p>
|
||||
|
||||
The application is responsible for reading and writing from storage. The cache does not interact with storage directly. The application does the following:
|
||||
Ứng dụng chịu trách nhiệm cho việc đọc và ghi từ nơi lưu trữ. Cache không tương tác với lưu trữ này một cách trự tiếp. Ứng dụng sẽ thực thi như sau:
|
||||
|
||||
* Look for entry in cache, resulting in a cache miss
|
||||
* Load entry from the database
|
||||
* Add entry to cache
|
||||
* Return entry
|
||||
|
||||
* Tìm mục trong cache, dẫn đến "cache miss"
|
||||
* Tải mục này từ database
|
||||
* Thêm mục này vào cache
|
||||
* Trả về mục này
|
||||
|
||||
```python
|
||||
def get_user(self, user_id):
|
||||
user = cache.get("user.{0}", user_id)
|
||||
|
|
@ -1613,36 +1621,50 @@ def get_user(self, user_id):
|
|||
```
|
||||
|
||||
[Memcached](https://memcached.org/) is generally used in this manner.
|
||||
[Memcached](https://memcached.org/) thường được sử dụng với cách này.
|
||||
|
||||
Subsequent reads of data added to cache are fast. Cache-aside is also referred to as lazy loading. Only requested data is cached, which avoids filling up the cache with data that isn't requested.
|
||||
Cách thao tác đọc sẽ nhanh sau khi dữ liệu nằm trong cache. Cache-aside còn được biết đến cái tên "lazy loading". Chỉ những dữ liệu đã yêu cầu được cache, tránh được việc nhồi nhét vào cache những dữ liệu không được yêu cầu.
|
||||
|
||||
##### Disadvantage(s): cache-aside
|
||||
##### Bất lợi của cache-aside
|
||||
|
||||
* Each cache miss results in three trips, which can cause a noticeable delay.
|
||||
* Data can become stale if it is updated in the database. This issue is mitigated by setting a time-to-live (TTL) which forces an update of the cache entry, or by using write-through.
|
||||
* Data can become stale if it is updated in the database. This issue is mitigated by setting a time-to-live (TTL** which forces an update of the cache entry, or by using write-through.
|
||||
* When a node fails, it is replaced by a new, empty node, increasing latency.
|
||||
|
||||
* Mỗi lần miss cache sẽ dẫn đến ba vòng đi, nên có thể gây ra độ trễ cảm nhận được.
|
||||
* Dữ liệu ở cache có thể bị cũ (stale) nếu bị update trực tiếp trong CSDL. Có thể giải quyết phần nào vấn đề này bằng cách cấu hình time-to-live (TTL**, để bắt buộc cập nhật một mục trên cache sau một khoảng thời gian, hoặc sử dụng write-through.
|
||||
* Khi một nốt bị hỏng được thay thế bởi một nốt rỗng mới, sẽ làm tăng độ trễ.
|
||||
|
||||
#### Write-through
|
||||
|
||||
<p align="center">
|
||||
<img src="images/0vBc0hN.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Nguồn: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
The application uses the cache as the main data store, reading and writing data to it, while the cache is responsible for reading and writing to the database:
|
||||
Ứng dụng sử dụng cache như là dữ liệu chính, làm nơi đọc / ghi dữ liệu trực tiếp vào, khi đó thì cache chịu trách nhiệm chính cho việc đọc và ghi vào CSDL.
|
||||
|
||||
* Application adds/updates entry in cache
|
||||
* Cache synchronously writes entry to data store
|
||||
* Return
|
||||
|
||||
* Ứng dụng thêm/cập nhật mục vào cache
|
||||
* Cache đồng bộ hoá việc ghi dữ liệu vào CSDL
|
||||
* Trả về kết quả
|
||||
|
||||
Application code:
|
||||
Code ở ứng dụng:
|
||||
|
||||
```python
|
||||
set_user(12345, {"foo":"bar"})
|
||||
```
|
||||
|
||||
Cache code:
|
||||
Code ở cache:
|
||||
|
||||
```python
|
||||
def set_user(user_id, values):
|
||||
|
|
@ -1651,53 +1673,78 @@ def set_user(user_id, values):
|
|||
```
|
||||
|
||||
Write-through is a slow overall operation due to the write operation, but subsequent reads of just written data are fast. Users are generally more tolerant of latency when updating data than reading data. Data in the cache is not stale.
|
||||
Write-through nhìn chung là tương đối chậm do quá trình ghi, nhưng các thao đọc về sau của dư liệu vừa ghi sẽ nhanh. Người dùng thường chịu chấp nhận độ trễ ở cập nhật dữ liệu hơn là trễ ở việc đọc. Dữ liệu trong cache sẽ không thể stale.
|
||||
|
||||
##### Disadvantage(s): write through
|
||||
##### Bất lợi của write through
|
||||
|
||||
* When a new node is created due to failure or scaling, the new node will not cache entries until the entry is updated in the database. Cache-aside in conjunction with write through can mitigate this issue.
|
||||
* Most data written might never be read, which can be minimized with a TTL.
|
||||
|
||||
* Khi một nốt mới được tạo do một nốt khác hỏng hay do mở rộng tải, nốt mới sẽ không có các mục cache hiện tại cho đến khi mục được được cập nhật. Kết hợp cache-aside và write through có thể giải quyết phần nào vấn đề này.
|
||||
* Hầu hết dữ liệu được ghi có thể sẽ không bao giờ được đọc, việc này có thể giảm thiểu bằng TTL.
|
||||
|
||||
#### Write-behind (write-back)
|
||||
#### Write-behind (write-back)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/rgSrvjG.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Source: Scalability, availability, stability, patterns</a></i>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Nguồn: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
In write-behind, the application does the following:
|
||||
Với write-behind, ứng dụng sẽ làm như sau:
|
||||
|
||||
* Add/update entry in cache
|
||||
* Asynchronously write entry to the data store, improving write performance
|
||||
|
||||
* Thêm/cập nhật mục vào cache
|
||||
* Viết mục vào kho dữ liệu một cách bất đồng bộ, tăng cường hiệu năng của ghi
|
||||
|
||||
##### Disadvantage(s): write-behind
|
||||
##### Bất lợi của write-behind
|
||||
|
||||
* There could be data loss if the cache goes down prior to its contents hitting the data store.
|
||||
* It is more complex to implement write-behind than it is to implement cache-aside or write-through.
|
||||
|
||||
* Có thể mất dữ liệu nếu cache sập trước khi nội dung cache đến được kho dữ liệu.
|
||||
* Phức tạp hơn để triển khai write-behind so với cache-aside hay write-through.
|
||||
|
||||
#### Refresh-ahead
|
||||
#### Refresh-ahead
|
||||
|
||||
<p align="center">
|
||||
<img src="images/kxtjqgE.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Source: From cache to in-memory data grid</a></i>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Nguồn: From cache to in-memory data grid</a></i>
|
||||
</p>
|
||||
|
||||
You can configure the cache to automatically refresh any recently accessed cache entry prior to its expiration.
|
||||
Ta có thể cấu hình để cache tự động làm mới các mục cache trước thời điểm hết hạn cho các mục thường xuyên được truy cập.
|
||||
|
||||
Refresh-ahead can result in reduced latency vs read-through if the cache can accurately predict which items are likely to be needed in the future.
|
||||
Refresh-ahead có thể đạt hiệu quả trong việc giảm độ trễ so với read-though nếu cache có thể dự đoán chính xác những mục có khả năng được cần đến trong tương lai.
|
||||
|
||||
##### Disadvantage(s): refresh-ahead
|
||||
#### Bất lợi của refresh-ahead
|
||||
|
||||
* Not accurately predicting which items are likely to be needed in the future can result in reduced performance than without refresh-ahead.
|
||||
* Thiếu chính xác trong việc dự đoán những mục cần trong tương lai có thể làm giảm thiểu hiệu năng so với việc không refresh-ahead.
|
||||
|
||||
### Disadvantage(s): cache
|
||||
### Bất lợi của cache
|
||||
|
||||
* Need to maintain consistency between caches and the source of truth such as the database through [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms).
|
||||
* Cache invalidation is a difficult problem, there is additional complexity associated with when to update the cache.
|
||||
* Need to make application changes such as adding Redis or memcached.
|
||||
|
||||
* Cần bảo đảm tính nhất quán giữa cache và nguồn gốc như CSDL thông qua [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms).
|
||||
* Cache invalidation là một vấn đề khó, gia tăng tính phức tạp trong việc tính toán thời điểm khi nào thì cập nhật cache.
|
||||
* Cần thay đổi ở lớp ứng dụng như là thêm Redis hoặc memcached.
|
||||
|
||||
### Source(s) and further reading
|
||||
### Nguồn đọc thêm
|
||||
|
||||
* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
|
||||
* [Scalable system design patterns](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
|
||||
|
|
@ -1708,14 +1755,16 @@ Refresh-ahead can result in reduced latency vs read-through if the cache can acc
|
|||
* [Wikipedia](https://en.wikipedia.org/wiki/Cache_(computing))
|
||||
|
||||
## Asynchronism
|
||||
## Bất đồng bộ
|
||||
|
||||
<p align="center">
|
||||
<img src="images/54GYsSx.png">
|
||||
<br/>
|
||||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Source: Intro to architecting systems for scale</a></i>
|
||||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Nguồn: Intro to architecting systems for scale</a></i>
|
||||
</p>
|
||||
|
||||
Asynchronous workflows help reduce request times for expensive operations that would otherwise be performed in-line. They can also help by doing time-consuming work in advance, such as periodic aggregation of data.
|
||||
Workflow bất động bộ giúp giảm thiểu thời gian request so với việc thực hiện một cách tuyến tính cho các tác vụ nặng. Ngoài ra còn có thể giúp thực hiện trước các công việc tốn thời gian, như tổng hợp dữ liệu một cách định kỳ.
|
||||
|
||||
### Message queues
|
||||
### Hàng đợi tin
|
||||
|
|
@ -1748,9 +1797,13 @@ Hàng đợi nhận tác vụ và các dữ liệu liên quan, thực thi và gi
|
|||
|
||||
If queues start to grow significantly, the queue size can become larger than memory, resulting in cache misses, disk reads, and even slower performance. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) can help by limiting the queue size, thereby maintaining a high throughput rate and good response times for jobs already in the queue. Once the queue fills up, clients get a server busy or HTTP 503 status code to try again later. Clients can retry the request at a later time, perhaps with [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff).
|
||||
|
||||
Nếu hạng đợi bắt đầu gia tăng quá lớn, kích thước có thể vượt quá bộ nhớ, dẫn đến "cache miss", truy xuất đĩa, và giảm thiểu hiệu suất. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html) có thể giúp ích bằng cách giới hạn kích thước của queue, từ đó bảo đảm tần suất lưu lượng cao và thời gian hồi đáp tốt cho các tác vụ đang có trong hàng đợi. Khi hàng đợi đầy, client nhận được mã HTTP 503 hoặc "server bận" để thử lại sau. Client có thể thử lại request ở một thời điểm sau, khả dĩ với [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff).
|
||||
|
||||
### Disadvantage(s): asynchronism
|
||||
### Bất lợi của bất đồng bộ
|
||||
|
||||
* Use cases such as inexpensive calculations and realtime workflows might be better suited for synchronous operations, as introducing queues can add delays and complexity.
|
||||
* Những nhu cầu với các tính toán nhanh và workflow yêu cầu thời gian thực có thể tốt hơn là dùng các tác vụ đồng bộ, thêm hàng đợi có thể tăng độ trễ và độ phức tạp.
|
||||
|
||||
### Source(s) and further reading
|
||||
### Tài liệu bổ sung
|
||||
|
|
@ -1993,9 +2046,10 @@ REST is focused on exposing data. It minimizes the coupling between client/serv
|
|||
## An ninh
|
||||
|
||||
This section could use some updates. Consider [contributing](#contributing)!
|
||||
Phần cần được bổ sung thêm. Hãy [đóng góp](#contributing)!
|
||||
Phần cần được bổ sung thêm. Xin bạn [đóng góp](#contributing)!
|
||||
|
||||
Security is a broad topic. Unless you have considerable experience, a security background, or are applying for a position that requires knowledge of security, you probably won't need to know more than the basics:
|
||||
|
||||
An ninh là một chủ đề rộng. Trừ khi bạn có kinh nghiệm đáng kể, một nền tảng về an ninh, hoặc đang ứng tuyển vào một ví trí đòi hỏi kiến thức về an ninh, hầu như bạn sẽ không cần biết nhiều hơn ở mức cơ bản này:
|
||||
|
||||
* Encrypt in transit and at rest.
|
||||
|
|
@ -2125,7 +2179,7 @@ Một số tham số hữu dụng từ các con số trên:
|
|||
| Add a system design question | [Contribute](#contributing) |
|
||||
|
||||
### Real world architectures
|
||||
### Kiến trúc ở đời thực
|
||||
### Kiến trúc thực tế
|
||||
|
||||
> Articles on how real world systems are designed.
|
||||
> Các bài viết về cách các hệ thống thực tế được thiết kế như thế nào
|
||||
|
|
@ -2300,6 +2354,7 @@ TODO: probably make a glossary at the beginning of the document?
|
|||
|
||||
- Scale / scalable / scalability: "mở rộng" / "khả năng mở rộng"?
|
||||
- Large-scale system: "hệ thống lớn"?
|
||||
- Scale: "mở rộng tải" / "tăng tải"?
|
||||
- Partition tolerance: "dung sai phân vùng" (Typically, "dung sai" in Vietnamese is a scalar value, and often accompanied with an unit. So I'm not sure this is the right one.)
|
||||
- Client/server
|
||||
- Service: "dịch vụ"?
|
||||
|
|
@ -2320,6 +2375,10 @@ TODO: probably make a glossary at the beginning of the document?
|
|||
- Operation
|
||||
- Use case
|
||||
- Call _(as a noun)_
|
||||
- Node: "nốt"
|
||||
- Fail: "hỏng"
|
||||
- Workflow
|
||||
- Cache: "bộ đệm"?
|
||||
|
||||
### Words that does have a translation but the English version is widely accepted among the Vietnamese-speakers
|
||||
|
||||
|
|
@ -2327,4 +2386,8 @@ TODO: probably make a glossary at the beginning of the document?
|
|||
- Programmer: "lập trình viên" is just too mouthful
|
||||
- Request - response: "yêu cầu / truy vấn" - "hồi đáp / trả lời".
|
||||
- Message
|
||||
- OS: "hệ điều hành" is sometimes too mouthful.
|
||||
- OS: "hệ điều hành" is sometimes too mouthful.
|
||||
|
||||
### Translation that I found not commonly used / accepted in Vietnamese but is a great translation any way
|
||||
|
||||
- stale: thiu
|
||||
|
|
@ -977,7 +977,7 @@ NoSQL 是**键-值数据库**、**文档型数据库**、**列型数据库**或*
|
|||
- [键-值数据库](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
- [键-值存储的劣势](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
- [Redis 架构](http://qnimate.com/overview-of-redis-architecture/)
|
||||
- [Memcached 架构](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
- [Memcached 架构](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### 文档类型存储
|
||||
|
||||
|
|
@ -1723,7 +1723,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
|
|
@ -967,7 +967,7 @@ NoSQL 指的是 **鍵-值對的資料庫**、**文件類型資料庫**、**列
|
|||
* [鍵值對資料庫](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [鍵值對資料庫的缺點](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redis 架構](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [Memcached 架構](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [Memcached 架構](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### 文件類型資料庫
|
||||
|
||||
|
|
@ -1713,7 +1713,7 @@ Notes
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
24
README.md
24
README.md
|
|
@ -389,13 +389,13 @@ First, you'll need a basic understanding of common principles, learning about wh
|
|||
|
||||
### Step 2: Review the scalability article
|
||||
|
||||
[Scalability](http://www.lecloud.net/tagged/scalability/chrono)
|
||||
[Scalability](https://web.archive.org/web/20221030091841/http://www.lecloud.net/tagged/scalability/chrono)
|
||||
|
||||
* Topics covered:
|
||||
* [Clones](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Databases](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Caches](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [Asynchronism](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
|
||||
* [Clones](https://web.archive.org/web/20220530193911/https://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Databases](https://web.archive.org/web/20220602114024/https://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Caches](https://web.archive.org/web/20230126233752/https://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [Asynchronism](https://web.archive.org/web/20220926171507/https://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
|
||||
|
||||
### Next steps
|
||||
|
||||
|
|
@ -433,7 +433,7 @@ Generally, you should aim for **maximal throughput** with **acceptable latency**
|
|||
|
||||
### Source(s) and further reading
|
||||
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
|
||||
|
||||
## Availability vs consistency
|
||||
|
||||
|
|
@ -461,7 +461,7 @@ Waiting for a response from the partitioned node might result in a timeout error
|
|||
|
||||
Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.
|
||||
|
||||
AP is a good choice if the business needs allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
|
||||
AP is a good choice if the business needs to allow for [eventual consistency](#eventual-consistency) or when the system needs to continue working despite external errors.
|
||||
|
||||
### Source(s) and further reading
|
||||
|
||||
|
|
@ -597,7 +597,7 @@ DNS is hierarchical, with a few authoritative servers at the top level. Your ro
|
|||
|
||||
Services such as [CloudFlare](https://www.cloudflare.com/dns/) and [Route 53](https://aws.amazon.com/route53/) provide managed DNS services. Some DNS services can route traffic through various methods:
|
||||
|
||||
* [Weighted round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
|
||||
* [Weighted round robin](https://www.jscape.com/blog/load-balancing-algorithms)
|
||||
* Prevent traffic from going to servers under maintenance
|
||||
* Balance between varying cluster sizes
|
||||
* A/B testing
|
||||
|
|
@ -1015,7 +1015,7 @@ A key-value store is the basis for more complex systems such as a document store
|
|||
* [Key-value database](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redis architecture](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [Memcached architecture](https://www.adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
* [Memcached architecture](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### Document store
|
||||
|
||||
|
|
@ -1668,12 +1668,12 @@ Handy metrics based on numbers above:
|
|||
| Design a content delivery network like CloudFlare | [figshare.com](https://figshare.com/articles/Globally_distributed_content_delivery/6605972) |
|
||||
| Design a trending topic system like Twitter's | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in-storm/)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
|
||||
| Design a random ID generation system | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/twitter/snowflake/) |
|
||||
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/cs.ucsb.edu/files/docs/reports/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
|
||||
| Return the top k requests during a time interval | [cs.ucsb.edu](https://www.cs.ucsb.edu/sites/default/files/documents/2005-23.pdf)<br/>[wpi.edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
|
||||
| Design a system that serves data from multiple data centers | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
|
||||
| Design an online multiplayer card game | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer-game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
|
||||
| Design a garbage collection system | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http://courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
|
||||
| Design an API rate limiter | [https://stripe.com/blog/](https://stripe.com/blog/rate-limiters) |
|
||||
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implemenation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
|
||||
| Design a Stock Exchange (like NASDAQ or Binance) | [Jane Street](https://youtu.be/b1e4t2k2KJY)<br/>[Golang Implementation](https://around25.com/blog/building-a-trading-engine-for-a-crypto-exchange/)<br/>[Go Implementation](http://bhomnick.net/building-a-simple-limit-order-in-go/) |
|
||||
| Add a system design question | [Contribute](#contributing) |
|
||||
|
||||
### Real world architectures
|
||||
|
|
@ -1764,7 +1764,7 @@ Handy metrics based on numbers above:
|
|||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](http://githubengineering.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ generate () {
|
|||
cat $name.md | generate_from_stdin $name.epub $language
|
||||
}
|
||||
|
||||
# Check if depencies exist
|
||||
# Check if dependencies exist
|
||||
check_dependencies () {
|
||||
for dependency in "${dependencies[@]}"
|
||||
do
|
||||
|
|
|
|||
Loading…
Reference in New Issue