Fixed a mistranslation

2023-06-15 17:27:25 +05:30 · 2023-06-15 17:27:25 +05:30 · f53ac43591
parent 384669887d
commit f53ac43591
1 changed files with 719 additions and 719 deletions
--- a/README-ja.md
+++ b/README-ja.md
@ -1,4 +1,4 @@
-*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)*
+_[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة‎](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](https://github.com/donnemartin/system-design-primer/issues/39) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)_

 # システム設計入門

@ -35,11 +35,11 @@

 面接準備に役立つその他のトピック:

-* [学習指針](#学習指針)
-* [システム設計面接課題にどのように準備するか](#システム設計面接にどのようにして臨めばいいか)
-* [システム設計課題例 **とその解答**](#システム設計課題例とその解答)
-* [オブジェクト指向設計課題例、 **とその解答**](#オブジェクト指向設計問題と解答)
-* [その他のシステム設計面接課題例](#他のシステム設計面接例題)
+- [学習指針](#学習指針)
+- [システム設計面接課題にどのように準備するか](#システム設計面接にどのようにして臨めばいいか)
+- [システム設計課題例 **とその解答**](#システム設計課題例とその解答)
+- [オブジェクト指向設計課題例、 **とその解答**](#オブジェクト指向設計問題と解答)
+- [その他のシステム設計面接課題例](#他のシステム設計面接例題)

 ## 暗記カード

@ -50,9 +50,9 @@

 この[Anki 用フラッシュカードデッキ](https://apps.ankiweb.net/) は、間隔反復を活用して、システム設計のキーコンセプトの学習を支援します。

-* [システム設計デッキ](resources/flash_cards/System%20Design.apkg)
-* [システム設計練習課題デッキ](resources/flash_cards/System%20Design%20Exercises.apkg)
-* [オブジェクト指向練習課題デッキ](resources/flash_cards/OO%20Design.apkg)
+- [システム設計デッキ](resources/flash_cards/System%20Design.apkg)
+- [システム設計練習課題デッキ](resources/flash_cards/System%20Design%20Exercises.apkg)
+- [オブジェクト指向練習課題デッキ](resources/flash_cards/OO%20Design.apkg)

 外出先や移動中の勉強に役立つでしょう。

@ -67,7 +67,7 @@

 姉妹リポジトリの [**Interactive Coding Challenges**](https://github.com/donnemartin/interactive-coding-challenges)も見てみてください。追加の暗記デッキカードも入っています。

-* [Coding deck](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)
+- [Coding deck](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)

 ## コントリビュート

@ -75,10 +75,10 @@

 プルリクエスト等の貢献は積極的にお願いします:

-* エラー修正
-* セクション内容改善
-* 新規セクション追加
-* [翻訳する](https://github.com/donnemartin/system-design-primer/issues/28)
+- エラー修正
+- セクション内容改善
+- 新規セクション追加
+- [翻訳する](https://github.com/donnemartin/system-design-primer/issues/28)

 現在、内容の改善が必要な作業中のコンテンツは[こちら](#進行中の作業)です。

@ -95,86 +95,86 @@
  <br/>
 </p>

-* [システム設計トピック: まずはここから](#システム設計トピックス-まずはここから)
-    * [Step 1: スケーラビリティに関する動画を見る](#ステップ-1-スケーラビリティに関する動画を観て復習する)
-    * [Step 2: スケーラビリティに関する記事を読む](#ステップ-2-スケーラビリティに関する資料を読んで復習する)
-    * [次のステップ](#次のステップ)
-* [パフォーマンス vs スケーラビリティ](#パフォーマンス-vs-スケーラビリティ)
-* [レイテンシー vs スループット](#レイテンシー-vs-スループット)
-* [可用性 vs 一貫性](#可用性-vs-一貫性)
-    * [CAP理論](#cap-理論)
-        * [CP - 一貫性(consistency)と分割性(partition)耐性](#cp---一貫性と分断耐性consistency-and-partition-tolerance)
-        * [AP - 可用性(availability)と分割性(partition)耐性](#ap---可用性と分断耐性availability-and-partition-tolerance)
-* [一貫性 パターン](#一貫性パターン)
-    * [弱い一貫性](#弱い一貫性)
-    * [結果整合性](#結果整合性)
-    * [強い一貫性](#強い一貫性)
-* [可用性 パターン](#可用性パターン)
-    * [フェイルオーバー](#フェイルオーバー)
-    * [レプリケーション](#レプリケーション)
-* [ドメインネームシステム(DNS)](#ドメインネームシステム)
-* [コンテンツデリバリーネットワーク(CDN)](#コンテンツデリバリーネットワークcontent-delivery-network)
-    * [プッシュCDN](#プッシュcdn)
-    * [プルCDN](#プルcdn)
-* [ロードバランサー](#ロードバランサー)
-    * [アクティブ/パッシブ構成](#アクティブパッシブ)
-    * [アクティブ/アクティブ構成](#アクティブアクティブ)
-    * [Layer 4 ロードバランシング](#layer-4-ロードバランシング)
-    * [Layer 7 ロードバランシング](#layer-7-ロードバランシング)
-    * [水平スケーリング](#水平スケーリング)
-* [リバースプロキシ (WEBサーバー)](#リバースプロキシwebサーバー)
-    * [ロードバランサー vs リバースプロキシ](#ロードバランサー-vs-リバースプロキシ)
-* [アプリケーションレイヤー](#アプリケーション層)
-    * [マイクロサービス](#マイクロサービス)
-    * [サービスディスカバリー](#service-discovery)
-* [データベース](#データベース)
-    * [リレーショナルデータベースマネジメントシステム (RDBMS)](#リレーショナルデータベースマネジメントシステム-rdbms)
-        * [マスター/スレーブ レプリケーション](#マスタースレーブ-レプリケーション)
-        * [マスター/マスター レプリケーション](#マスターマスター-レプリケーション)
-        * [フェデレーション](#federation)
-        * [シャーディング](#シャーディング)
-        * [デノーマライゼーション](#非正規化)
-        * [SQL チューニング](#sqlチューニング)
-    * [NoSQL](#nosql)
-        * [キー/バリューストア](#キーバリューストア)
-        * [ドキュメントストア](#ドキュメントストア)
-        * [ワイドカラムストア](#ワイドカラムストア)
-        * [グラフ データベース](#グラフデータベース)
-    * [SQL or NoSQL](#sqlかnosqlか)
-* [キャッシュ](#キャッシュ)
-    * [クライアントキャッシング](#クライアントキャッシング)
-    * [CDNキャッシング](#cdnキャッシング)
-    * [Webサーバーキャッシング](#webサーバーキャッシング)
-    * [データベースキャッシング](#データベースキャッシング)
-    * [アプリケーションキャッシング](#アプリケーションキャッシング)
-    * [データベースクエリレベルでキャッシングする](#データベースクエリレベルでのキャッシング)
-    * [オブジェクトレベルでキャッシングする](#オブジェクトレベルでのキャッシング)
-    * [いつキャッシュを更新するのか](#いつキャッシュを更新するか)
-        * [キャッシュアサイド](#キャッシュアサイド)
-        * [ライトスルー](#ライトスルー)
-        * [ライトビハインド (ライトバック)](#ライトビハインド-ライトバック)
-        * [リフレッシュアヘッド](#リフレッシュアヘッド)
-* [非同期処理](#非同期処理)
-    * [メッセージキュー](#メッセージキュー)
-    * [タスクキュー](#タスクキュー)
-    * [バックプレッシャー](#バックプレッシャー)
-* [通信](#通信)
-    * [伝送制御プロトコル (TCP)](#伝送制御プロトコル-tcp)
-    * [ユーザデータグラムプロトコル (UDP)](#ユーザデータグラムプロトコル-udp)
-    * [遠隔手続呼出 (RPC)](#遠隔手続呼出-rpc)
-    * [Representational state transfer (REST)](#representational-state-transfer-rest)
-* [セキュリティ](#セキュリティ)
-* [補遺](#補遺)
-    * [2の乗数表](#2の乗数表)
-    * [全てのプログラマーが知るべきレイテンシー値](#全てのプログラマーが知るべきレイテンシー値)
-    * [他のシステム設計面接例題](#他のシステム設計面接例題)
-    * [実世界でのアーキテクチャ](#実世界のアーキテクチャ)
-    * [各企業のアーキテクチャ](#各企業のアーキテクチャ)
-    * [企業のエンジニアブログ](#企業のエンジニアブログ)
-* [作業中](#進行中の作業)
-* [クレジット](#クレジット)
-* [連絡情報](#contact-info)
-* [ライセンス](#license)
+- [システム設計トピック: まずはここから](#システム設計トピックス-まずはここから)
+  - [Step 1: スケーラビリティに関する動画を見る](#ステップ-1-スケーラビリティに関する動画を観て復習する)
+  - [Step 2: スケーラビリティに関する記事を読む](#ステップ-2-スケーラビリティに関する資料を読んで復習する)
+  - [次のステップ](#次のステップ)
+- [パフォーマンス vs スケーラビリティ](#パフォーマンス-vs-スケーラビリティ)
+- [レイテンシー vs スループット](#レイテンシー-vs-スループット)
+- [可用性 vs 一貫性](#可用性-vs-一貫性)
+  - [CAP 理論](#cap-理論)
+    - [CP - 一貫性(consistency)と分割性(partition)耐性](#cp---一貫性と分断耐性consistency-and-partition-tolerance)
+    - [AP - 可用性(availability)と分割性(partition)耐性](#ap---可用性と分断耐性availability-and-partition-tolerance)
+- [一貫性 パターン](#一貫性パターン)
+  - [弱い一貫性](#弱い一貫性)
+  - [結果整合性](#結果整合性)
+  - [強い一貫性](#強い一貫性)
+- [可用性 パターン](#可用性パターン)
+  - [フェイルオーバー](#フェイルオーバー)
+  - [レプリケーション](#レプリケーション)
+- [ドメインネームシステム(DNS)](#ドメインネームシステム)
+- [コンテンツデリバリーネットワーク(CDN)](#コンテンツデリバリーネットワークcontent-delivery-network)
+  - [プッシュ CDN](#プッシュcdn)
+  - [プル CDN](#プルcdn)
+- [ロードバランサー](#ロードバランサー)
+  - [アクティブ/パッシブ構成](#アクティブパッシブ)
+  - [アクティブ/アクティブ構成](#アクティブアクティブ)
+  - [Layer 4 ロードバランシング](#layer-4-ロードバランシング)
+  - [Layer 7 ロードバランシング](#layer-7-ロードバランシング)
+  - [水平スケーリング](#水平スケーリング)
+- [リバースプロキシ (WEB サーバー)](#リバースプロキシwebサーバー)
+  - [ロードバランサー vs リバースプロキシ](#ロードバランサー-vs-リバースプロキシ)
+- [アプリケーションレイヤー](#アプリケーション層)
+  - [マイクロサービス](#マイクロサービス)
+  - [サービスディスカバリー](#service-discovery)
+- [データベース](#データベース)
+  - [リレーショナルデータベースマネジメントシステム (RDBMS)](#リレーショナルデータベースマネジメントシステム-rdbms)
+    - [マスター/スレーブ レプリケーション](#マスタースレーブ-レプリケーション)
+    - [マスター/マスター レプリケーション](#マスターマスター-レプリケーション)
+    - [フェデレーション](#federation)
+    - [シャーディング](#シャーディング)
+    - [デノーマライゼーション](#非正規化)
+    - [SQL チューニング](#sqlチューニング)
+  - [NoSQL](#nosql)
+    - [キー/バリューストア](#キーバリューストア)
+    - [ドキュメントストア](#ドキュメントストア)
+    - [ワイドカラムストア](#ワイドカラムストア)
+    - [グラフ データベース](#グラフデータベース)
+  - [SQL or NoSQL](#sqlかnosqlか)
+- [キャッシュ](#キャッシュ)
+  - [クライアントキャッシング](#クライアントキャッシング)
+  - [CDN キャッシング](#cdnキャッシング)
+  - [Web サーバーキャッシング](#webサーバーキャッシング)
+  - [データベースキャッシング](#データベースキャッシング)
+  - [アプリケーションキャッシング](#アプリケーションキャッシング)
+  - [データベースクエリレベルでキャッシングする](#データベースクエリレベルでのキャッシング)
+  - [オブジェクトレベルでキャッシングする](#オブジェクトレベルでのキャッシング)
+  - [いつキャッシュを更新するのか](#いつキャッシュを更新するか)
+    - [キャッシュアサイド](#キャッシュアサイド)
+    - [ライトスルー](#ライトスルー)
+    - [ライトビハインド (ライトバック)](#ライトビハインド-ライトバック)
+    - [リフレッシュアヘッド](#リフレッシュアヘッド)
+- [非同期処理](#非同期処理)
+  - [メッセージキュー](#メッセージキュー)
+  - [タスクキュー](#タスクキュー)
+  - [バックプレッシャー](#バックプレッシャー)
+- [通信](#通信)
+  - [伝送制御プロトコル (TCP)](#伝送制御プロトコル-tcp)
+  - [ユーザデータグラムプロトコル (UDP)](#ユーザデータグラムプロトコル-udp)
+  - [遠隔手続呼出 (RPC)](#遠隔手続呼出-rpc)
+  - [Representational state transfer (REST)](#representational-state-transfer-rest)
+- [セキュリティ](#セキュリティ)
+- [補遺](#補遺)
+  - [2 の乗数表](#2の乗数表)
+  - [全てのプログラマーが知るべきレイテンシー値](#全てのプログラマーが知るべきレイテンシー値)
+  - [他のシステム設計面接例題](#他のシステム設計面接例題)
+  - [実世界でのアーキテクチャ](#実世界のアーキテクチャ)
+  - [各企業のアーキテクチャ](#各企業のアーキテクチャ)
+  - [企業のエンジニアブログ](#企業のエンジニアブログ)
+- [作業中](#進行中の作業)
+- [クレジット](#クレジット)
+- [連絡情報](#contact-info)
+- [ライセンス](#license)

 ## 学習指針

@ -188,22 +188,22 @@

 面接で何を聞かれるかは以下の条件によって変わってきます:

-* どれだけの技術経験があるか
-* あなたの技術背景が何であるか
-* どのポジションのために面接を受けているか
-* どの企業の面接を受けているか
-* 運
+- どれだけの技術経験があるか
+- あなたの技術背景が何であるか
+- どのポジションのために面接を受けているか
+- どの企業の面接を受けているか
+- 運

 より経験のある候補者は一般的にシステム設計についてより深い知識を有していることを要求されるでしょう。システムアーキテクトやチームリーダーは各メンバーの持つような知識よりは深い見識を持っているべきでしょう。一流テック企業では複数回の設計面接を課されることが多いです。

 まずは広く始めて、そこからいくつかの分野に絞って深めていくのがいいでしょう。様々なシステム設計のトピックについて少しずつ知っておくことはいいことです。以下の学習ガイドを自分の学習に当てられる時間、技術経験、どの職位、どの会社に応募しているかなどを加味して自分用に調整して使うといいでしょう。

-* **短期間** - **幅広く** システム設計トピックを学ぶ。**いくつかの** 面接課題を解くことで対策する。
-* **中期間** - **幅広く** そして **それなりに深く**システム設計トピックを学ぶ。**多くの** 面接課題を解くことで対策する。
-* **長期間** - **幅広く** そして **もっと深く**システム設計トピックを学ぶ。**ほぼ全ての** 面接課題を解くことで対策する。
+- **短期間** - **幅広く** システム設計トピックを学ぶ。**いくつかの** 面接課題を解くことで対策する。
+- **中期間** - **幅広く** そして **それなりに深く**システム設計トピックを学ぶ。**多くの** 面接課題を解くことで対策する。
+- **長期間** - **幅広く** そして **もっと深く**システム設計トピックを学ぶ。**ほぼ全ての** 面接課題を解くことで対策する。

 |                                                                                                                           | 短期間 | 中期間 | 長期間 |
-|---|---|---|---|
+| ------------------------------------------------------------------------------------------------------------------------- | ------ | ------ | ------ |
 | [システム設計トピック](#システム設計目次) を読み、システム動作機序について広く知る                                        | :+1:   | :+1:   | :+1:   |
 | 次のリンク先のいくつかのページを読んで [各企業のエンジニアリングブログ](#企業のエンジニアブログ) 応募する会社について知る | :+1:   | :+1:   | :+1:   |
 | 次のリンク先のいくつかのページを読む [実世界でのアーキテクチャ](#実世界のアーキテクチャ)                                  | :+1:   | :+1:   | :+1:   |
@ -224,43 +224,43 @@

 システム仕様の要求事項を聞き出し、問題箇所を特定しましょう。使用例と制約を明確にするための質問を投げかけましょう。要求する推計値についても議論しておきましょう。

-* 誰がそのサービスを使うのか？
-* どのように使うのか？
-* 何人のユーザーがいるのか？
-* システムはどのような機能を果たすのか？
-* システムへの入力と出力は？
-* どれだけの容量のデータを捌く必要があるのか？
-* 一秒間に何リクエストの送信が想定されるか？
-* 読み書き比率の推定値はいくら程度か？
+- 誰がそのサービスを使うのか？
+- どのように使うのか？
+- 何人のユーザーがいるのか？
+- システムはどのような機能を果たすのか？
+- システムへの入力と出力は？
+- どれだけの容量のデータを捌く必要があるのか？
+- 一秒間に何リクエストの送信が想定されるか？
+- 読み書き比率の推定値はいくら程度か？

 ### ステップ 2: より高レベルのシステム設計を組み立てる

 重要なコンポーネントを全て考慮した高レベルのシステム設計概要を組み立てる。

-* 主要なコンポーネントと接続をスケッチして書き出す
-* 考えの裏付けをする
+- 主要なコンポーネントと接続をスケッチして書き出す
+- 考えの裏付けをする

 ### ステップ 3: 核となるコンポーネントを設計する

 それぞれの主要なコンポーネントについての詳細を学ぶ。例えば、[url 短縮サービス](solutions/system_design/pastebin/README.md)の設計を問われた際には次のようにするといいでしょう:

-* 元のURLのハッシュ化したものを作り、それを保存する
-    * [MD5](solutions/system_design/pastebin/README.md) と [Base62](solutions/system_design/pastebin/README.md)
-    * ハッシュ衝突
-    * SQL もしくは NoSQL
-    * データベーススキーマ
-* ハッシュ化されたURLを元のURLに再翻訳する
-    * データベース参照
-* API & オブジェクト指向の設計
+- 元の URL のハッシュ化したものを作り、それを保存する
+  - [MD5](solutions/system_design/pastebin/README.md) と [Base62](solutions/system_design/pastebin/README.md)
+  - ハッシュ衝突
+  - SQL もしくは NoSQL
+  - データベーススキーマ
+- ハッシュ化された URL を元の URL に再翻訳する
+  - データベース参照
+- API & オブジェクト指向の設計

 ### ステップ 4: システム設計のスケール

 与えられた制約条件からボトルネックとなりそうなところを割り出し、明確化する。 例えば、スケーラビリティの問題解決のために以下の要素を考慮する必要があるだろうか？

-* ロードバランサー
-* 水平スケーリング
-* キャッシング
-* データベースシャーディング
+- ロードバランサー
+- 水平スケーリング
+- キャッシング
+- データベースシャーディング

 取りうる解決策とそのトレードオフについて議論をしよう。全てのことはトレードオフの関係にある。ボトルネックについては[スケーラブルなシステム設計の原理](#システム設計目次)を読むといいでしょう。

@ -268,17 +268,17 @@

 ちょっとした推計値を手計算ですることを求められることもあるかもしれません。[補遺](#補遺)の以下の項目が役に立つでしょう:

-* [チラ裏計算でシステム設計する](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
-* [2の乗数表](#2の乗数表)
-* [全てのプログラマーが知っておくべきレイテンシの参考値](#全てのプログラマーが知るべきレイテンシー値)
+- [チラ裏計算でシステム設計する](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
+- [2 の乗数表](#2の乗数表)
+- [全てのプログラマーが知っておくべきレイテンシの参考値](#全てのプログラマーが知るべきレイテンシー値)

 ### 文献とその他の参考資料

 以下のリンク先ページを見てどのような質問を投げかけられるか概要を頭に入れておきましょう:

-* [システム設計面接で成功するには？](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
-* [システム設計面接](http://www.hiredintech.com/system-design)
-* [アーキテクチャ、システム設計面接への導入](https://www.youtube.com/watch?v=ZgdS0EUmn70)
+- [システム設計面接で成功するには？](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
+- [システム設計面接](http://www.hiredintech.com/system-design)
+- [アーキテクチャ、システム設計面接への導入](https://www.youtube.com/watch?v=ZgdS0EUmn70)

 ## システム設計課題例とその解答

@ -287,7 +287,7 @@
 > 解答は `solutions/` フォルダ以下にリンクが貼られている

 | 問題                                                                                                               |                                                        |
-|---|---|
+| ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------ |
 | Pastebin.com (もしくは Bit.ly) を設計する                                                                          | [解答](solutions/system_design/pastebin/README.md)     |
 | Twitter タイムライン (もしくは Facebook フィード)を設計する<br/>Twitter 検索(もしくは Facebook 検索)機能を設計する | [解答](solutions/system_design/twitter/README.md)      |
 | ウェブクローラーを設計する                                                                                         | [解答](solutions/system_design/web_crawler/README.md)  |
@ -355,7 +355,7 @@
 > **備考: このセクションは作業中です**

 | 問題                                       |                                                                            |
-|---|---|
+| ------------------------------------------ | -------------------------------------------------------------------------- |
 | ハッシュマップの設計                       | [解答](solutions/object_oriented_design/hash_table/hash_map.ipynb)         |
 | LRU キャッシュの設計                       | [解答](solutions/object_oriented_design/lru_cache/lru_cache.ipynb)         |
 | コールセンターの設計                       | [解答](solutions/object_oriented_design/call_center/call_center.ipynb)     |
@ -375,31 +375,31 @@

 [Harvard でのスケーラビリティの講義](https://www.youtube.com/watch?v=-W9F__D3oY4)

-* ここで触れられているトピックス:
-    * 垂直スケーリング
-    * 水平スケーリング
-    * キャッシング
-    * ロードバランシング
-    * データベースレプリケーション
-    * データベースパーティション
+- ここで触れられているトピックス:
+  - 垂直スケーリング
+  - 水平スケーリング
+  - キャッシング
+  - ロードバランシング
+  - データベースレプリケーション
+  - データベースパーティション

 ### ステップ 2: スケーラビリティに関する資料を読んで復習する

 [スケーラビリティ](http://www.lecloud.net/tagged/scalability/chrono)

-* ここで触れられているトピックス:
-    * [クローン](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
-    * [データベース](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
-    * [キャッシュ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
-    * [非同期](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
+- ここで触れられているトピックス:
+  - [クローン](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
+  - [データベース](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
+  - [キャッシュ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
+  - [非同期](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)

 ### 次のステップ

 次に、ハイレベルでのトレードオフについてみていく:

-* **パフォーマンス** vs **スケーラビリティ**
-* **レイテンシ** vs **スループット**
-* **可用性** vs **一貫性**
+- **パフォーマンス** vs **スケーラビリティ**
+- **レイテンシ** vs **スループット**
+- **可用性** vs **一貫性**

 **全てはトレードオフの関係にある**というのを肝に命じておきましょう。

@ -411,13 +411,13 @@

 パフォーマンス vs スケーラビリティをとらえる他の考え方:

-* **パフォーマンス** での問題を抱えている時、あなたのシステムは一人のユーザーにとって遅いと言えるでしょう。
-* **スケーラビリティ** での問題を抱えているとき、一人のユーザーにとっては速いですが、多くのリクエストがある時には遅くなってしまうでしょう。
+- **パフォーマンス** での問題を抱えている時、あなたのシステムは一人のユーザーにとって遅いと言えるでしょう。
+- **スケーラビリティ** での問題を抱えているとき、一人のユーザーにとっては速いですが、多くのリクエストがある時には遅くなってしまうでしょう。

 ### その他の参考資料、ページ

-* [スケーラビリティについて](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
-* [スケーラビリティ、可用性、安定性、パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
+- [スケーラビリティについて](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
+- [スケーラビリティ、可用性、安定性、パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)

 ## レイテンシー vs スループット

@ -429,7 +429,7 @@

 ### その他の参考資料、ページ

-* [レイテンシー vs スループットを理解する](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)
+- [レイテンシー vs スループットを理解する](https://community.cadence.com/cadence_blogs_8/b/sd/archive/2010/09/13/understanding-latency-vs-throughput)

 ## 可用性 vs 一貫性

@ -443,11 +443,11 @@

 分散型コンピュータシステムにおいては下の三つのうち二つまでしか同時に保証することはできない。:

-* **一貫性** - 全ての読み込みは最新の書き込みもしくはエラーを受け取る
-* **可用性** - 受け取る情報が最新のものだという保証はないが、全てのリクエストはレスポンスを必ず受け取る
-* **分断耐性** - ネットワーク問題によって順不同の分断が起きてもシステムが動作を続ける
+- **一貫性** - 全ての読み込みは最新の書き込みもしくはエラーを受け取る
+- **可用性** - 受け取る情報が最新のものだという保証はないが、全てのリクエストはレスポンスを必ず受け取る
+- **分断耐性** - ネットワーク問題によって順不同の分断が起きてもシステムが動作を続ける

-*ネットワークは信頼できないので、分断耐性は必ず保証しなければなりません。つまりソフトウェアシステムとしてのトレードオフは、一貫性を取るか、可用性を取るかを考えなければなりません。*
+_ネットワークは信頼できないので、分断耐性は必ず保証しなければなりません。つまりソフトウェアシステムとしてのトレードオフは、一貫性を取るか、可用性を取るかを考えなければなりません。_

 #### CP - 一貫性と分断耐性(consistency and partition tolerance)

@ -461,9 +461,9 @@

 ### その他の参考資料、ページ

-* [CAP 理論を振り返る](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
-* [平易な英語でのCAP 理論のイントロ](http://ksat.me/a-plain-english-introduction-to-cap-theorem/)
-* [CAP FAQ](https://github.com/henryr/cap-faq)
+- [CAP 理論を振り返る](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
+- [平易な英語での CAP 理論のイントロ](http://ksat.me/a-plain-english-introduction-to-cap-theorem/)
+- [CAP FAQ](https://github.com/henryr/cap-faq)

 ## 一貫性パターン

@ -489,7 +489,7 @@

 ### その他の参考資料、ページ

-* [データセンター間でのトランザクション](http://snarfed.org/transactions_across_datacenters_io.html)
+- [データセンター間でのトランザクション](http://snarfed.org/transactions_across_datacenters_io.html)

 ## 可用性パターン

@ -515,8 +515,8 @@

 ### 短所: フェイルオーバー

-* フェイルオーバーではより多くのハードウェアを要し、複雑さが増します。
-* 最新の書き込みがパッシブサーバーに複製される前にアクティブが落ちると、データ欠損が起きる潜在可能性があります。
+- フェイルオーバーではより多くのハードウェアを要し、複雑さが増します。
+- 最新の書き込みがパッシブサーバーに複製される前にアクティブが落ちると、データ欠損が起きる潜在可能性があります。

 ### レプリケーション

@ -524,8 +524,8 @@

 このトピックは [データベース](#データベース) セクションにおいてより詳細に解説されています:

-* [マスター・スレーブ レプリケーション](#マスタースレーブ-レプリケーション)
-* [マスター・マスター レプリケーション](#マスターマスター-レプリケーション)
+- [マスター・スレーブ レプリケーション](#マスタースレーブ-レプリケーション)
+- [マスター・マスター レプリケーション](#マスターマスター-レプリケーション)

 ## ドメインネームシステム

@ -539,31 +539,31 @@

 DNS は少数のオーソライズされたサーバーが上位に位置する階層的構造です。あなたのルーターもしくは ISP は検索をする際にどの DNS サーバーに接続するかという情報を提供します。低い階層の DNS サーバーはその経路マップをキャッシュします。ただ、この情報は伝搬遅延によって陳腐化する可能性があります。DNS の結果はあなたのブラウザもしくは OS に一定期間（[time to live (TTL)](https://en.wikipedia.org/wiki/Time_to_live)に設定された期間）キャッシュされます。

-* **NS record (name server)** - あなたのドメイン・サブドメインでのDNSサーバーを特定します。
-* **MX record (mail exchange)** - メッセージを受け取るメールサーバーを特定します。
-* **A record (address)** - IPアドレスに名前をつけます。
-* **CNAME (canonical)** - 他の名前もしくは　`CNAME` (example.com を www.example.com) もしくは `A` recordへと名前を指し示す。
+- **NS record (name server)** - あなたのドメイン・サブドメインでの DNS サーバーを特定します。
+- **MX record (mail exchange)** - メッセージを受け取るメールサーバーを特定します。
+- **A record (address)** - IP アドレスに名前をつけます。
+- **CNAME (canonical)** - 他の名前もしくは　`CNAME` (example.com を www.example.com) もしくは `A` record へと名前を指し示す。

 [CloudFlare](https://www.cloudflare.com/dns/) や [Route 53](https://aws.amazon.com/route53/) などのサービスはマネージド DNS サービスを提供しています。いくつかの DNS サービスでは様々な手法を使ってトラフィックを捌くことができます:

-* [加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
-    * トラフィックがメンテナンス中のサーバーに行くのを防ぎます
-    * 様々なクラスターサイズに応じて調整します
-    * A/B テスト
-* レイテンシーベース
-* 地理ベース
+- [加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
+  - トラフィックがメンテナンス中のサーバーに行くのを防ぎます
+  - 様々なクラスターサイズに応じて調整します
+  - A/B テスト
+- レイテンシーベース
+- 地理ベース

 ### 欠点: DNS

-* 上記で示されているようなキャッシングによって緩和されているとはいえ、DNSサーバーへの接続には少し遅延が生じる。
-* DNSサーバーは、[政府、ISP企業,そして大企業](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)に管理されているが、それらの管理は複雑である。
-* DNSサービスは[DDoS attack](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)の例で、IPアドレスなしにユーザーがTwitterなどにアクセスできなくなったように、攻撃を受ける可能性がある。
+- 上記で示されているようなキャッシングによって緩和されているとはいえ、DNS サーバーへの接続には少し遅延が生じる。
+- DNS サーバーは、[政府、ISP 企業,そして大企業](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729)に管理されているが、それらの管理は複雑である。
+- DNS サービスは[DDoS attack](http://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/)の例で、IP アドレスなしにユーザーが Twitter などにアクセスできなくなったように、攻撃を受ける可能性がある。

 ### その他の参考資料、ページ

-* [DNS アーキテクチャ](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)
-* [Wikipedia](https://en.wikipedia.org/wiki/Domain_Name_System)
-* [DNS 記事](https://support.dnsimple.com/categories/dns/)
+- [DNS アーキテクチャ](<https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx>)
+- [Wikipedia](https://en.wikipedia.org/wiki/Domain_Name_System)
+- [DNS 記事](https://support.dnsimple.com/categories/dns/)

 ## コンテンツデリバリーネットワーク(Content delivery network)

@ -577,8 +577,8 @@ DNSは少数のオーソライズされたサーバーが上位に位置する

 CDN を用いてコンテンツを配信することで以下の二つの理由でパフォーマンスが劇的に向上します:

-* ユーザーは近くにあるデータセンターから受信できる
-* バックエンドサーバーはCDNが処理してくれるリクエストに関しては処理する必要がなくなります
+- ユーザーは近くにあるデータセンターから受信できる
+- バックエンドサーバーは CDN が処理してくれるリクエストに関しては処理する必要がなくなります

 ### プッシュ CDN

@ -596,15 +596,15 @@ CDNを用いてコンテンツを配信することで以下の二つの理由

 ### 欠点: CDN

-* CDNのコストはトラフィック量によって変わります。もちろん、CDNを使わない場合のコストと比較するべきでしょう。
-* TTLが切れる前にコンテンツが更新されると陳腐化する恐れがあります。
-* CDNでは静的コンテンツがCDNを指すようにURLを更新する必要があります。
+- CDN のコストはトラフィック量によって変わります。もちろん、CDN を使わない場合のコストと比較するべきでしょう。
+- TTL が切れる前にコンテンツが更新されると陳腐化する恐れがあります。
+- CDN では静的コンテンツが CDN を指すように URL を更新する必要があります。

 ### その他の参考資料、ページ

-* [グローバルに分散されたコンテンツデリバリーネットワーク](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci)
-* [プッシュCDNとプルCDNの違い](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
-* [Wikipedia](https://en.wikipedia.org/wiki/Content_delivery_network)
+- [グローバルに分散されたコンテンツデリバリーネットワーク](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci)
+- [プッシュ CDN とプル CDN の違い](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
+- [Wikipedia](https://en.wikipedia.org/wiki/Content_delivery_network)

 ## ロードバランサー

@ -616,28 +616,28 @@ CDNを用いてコンテンツを配信することで以下の二つの理由

 ロードバランサーは入力されるクライアントのリクエストをアプリケーションサーバーやデータベースへと分散させる。どのケースでもロードバランサーはサーバー等計算リソースからのレスポンスを適切なクライアントに返す。ロードバランサーは以下のことに効果的です:

-* リクエストが状態の良くないサーバーに行くのを防ぐ
-* リクエストを過剰に送るのを防ぐ
-* 特定箇所の欠陥でサービスが落ちることを防ぐ
+- リクエストが状態の良くないサーバーに行くのを防ぐ
+- リクエストを過剰に送るのを防ぐ
+- 特定箇所の欠陥でサービスが落ちることを防ぐ

 ロードバランサーは (費用の高い) ハードウェアもしくは HAProxy などのソフトウェアで実現できる。

 他の利点としては:

-* **SSL termination** - 入力されるリクエストを解読する、また、サーバーレスポンスを暗号化することでバックエンドのサーバーがこのコストが高くつきがちな処理を請け負わなくていいように肩代わりします。
-    * [X.509 certificates](https://en.wikipedia.org/wiki/X.509) をそれぞれのサーバーにインストールする必要をなくします
-* **セッション管理** - クッキーを取り扱うウェブアプリがセッション情報を保持していない時などに、特定のクライアントのリクエストを同じインスタンスへと流します。
+- **SSL termination** - 入力されるリクエストを解読する、また、サーバーレスポンスを暗号化することでバックエンドのサーバーがこのコストが高くつきがちな処理を請け負わなくていいように肩代わりします。
+  - [X.509 certificates](https://en.wikipedia.org/wiki/X.509) をそれぞれのサーバーにインストールする必要をなくします
+- **セッション管理** - クッキーを取り扱うウェブアプリがセッション情報を保持していない時などに、特定のクライアントのリクエストを同じインスタンスへと流します。

 障害に対応するために、[アクティブ・パッシブ](#アクティブパッシブ) もしくは [アクティブ・アクティブ](#アクティブアクティブ) モードのどちらにおいても、複数のロードバランサーを配置するのが一般的です。

 ロードバランサーは以下のような種々のメトリックを用いてトラフィックルーティングを行うことができます:

-* ランダム
-* Least loaded
-* セッション/クッキー
-* [ラウンドロビンもしくは加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
-* [Layer 4](#layer-4-ロードバランシング)
-* [Layer 7](#layer-7-ロードバランシング)
+- ランダム
+- Least loaded
+- セッション/クッキー
+- [ラウンドロビンもしくは加重ラウンドロビン](http://g33kinfo.com/info/archives/2657)
+- [Layer 4](#layer-4-ロードバランシング)
+- [Layer 7](#layer-7-ロードバランシング)

 ### Layer 4 ロードバランシング

@ -655,26 +655,26 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通

 #### 欠点: 水平スケーリング

-* 水平的にスケーリングしていくと、複雑さが増す上に、サーバーのクローニングが必要になる。
-    * サーバーはステートレスである必要がある: ユーザーに関連するセッションや、プロフィール写真などのデータを持ってはいけない
-    * セッションは一元的な[データベース](#データベース) (SQL、 NoSQL)などのデータストアにストアされるか [キャッシュ](#キャッシュ) (Redis、 Memcached)に残す必要があります。
-* キャッシュやデータベースなどの下流サーバーは上流サーバーがスケールアウトするにつれてより多くの同時接続を保たなければなりません。
+- 水平的にスケーリングしていくと、複雑さが増す上に、サーバーのクローニングが必要になる。
+  - サーバーはステートレスである必要がある: ユーザーに関連するセッションや、プロフィール写真などのデータを持ってはいけない
+  - セッションは一元的な[データベース](#データベース) (SQL、 NoSQL)などのデータストアにストアされるか [キャッシュ](#キャッシュ) (Redis、 Memcached)に残す必要があります。
+- キャッシュやデータベースなどの下流サーバーは上流サーバーがスケールアウトするにつれてより多くの同時接続を保たなければなりません。

 ### 欠点: ロードバランサー

-* ロードバランサーはリソースが不足していたり、設定が適切でない場合、システム全体のボトルネックになる可能性があります。
-* 単一障害点を除こうとしてロードバランサーを導入した結果、複雑さが増してしまうことになります。
-* ロードバランサーが一つだけだとそこが単一障害点になってしまいます。一方で、ロードバランサーを複数にすると、さらに複雑さが増してしまいます。
+- ロードバランサーはリソースが不足していたり、設定が適切でない場合、システム全体のボトルネックになる可能性があります。
+- 単一障害点を除こうとしてロードバランサーを導入した結果、複雑さが増してしまうことになります。
+- ロードバランサーが一つだけだとそこが単一障害点になってしまいます。一方で、ロードバランサーを複数にすると、さらに複雑さが増してしまいます。

 ### その他の参考資料、ページ

-* [NGINX アーキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
-* [HAProxy アーキテクチャガイド](http://www.haproxy.org/download/1.2/doc/architecture.txt)
-* [スケーラビリティ](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
-* [Wikipedia](https://en.wikipedia.org/wiki/Load_balancing_(computing))
-* [Layer 4 ロードバランシング](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
-* [Layer 7 ロードバランシング](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
-* [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)
+- [NGINX アーキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
+- [HAProxy アーキテクチャガイド](http://www.haproxy.org/download/1.2/doc/architecture.txt)
+- [スケーラビリティ](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
+- [Wikipedia](<https://en.wikipedia.org/wiki/Load_balancing_(computing)>)
+- [Layer 4 ロードバランシング](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
+- [Layer 7 ロードバランシング](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
+- [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)

 ## リバースプロキシ(web サーバー)

@ -689,35 +689,35 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通

 他には以下のような利点があります:

-* **より堅牢なセキュリティ** - バックエンドサーバーの情報を隠したり、IPアドレスをブラックリスト化したり、クライアントごとの接続数を制限したりできます。
-* **スケーラビリティや柔軟性が増します** - クライアントはリバースプロキシのIPしか見ないので、裏でサーバーをスケールしたり、設定を変えやすくなります。
-* **SSL termination** - 入力されるリクエストを解読し、サーバーのレスポンスを暗号化することでサーバーがこのコストのかかりうる処理をしなくて済むようになります。
-    * [X.509 証明書](https://en.wikipedia.org/wiki/X.509) を各サーバーにインストールする必要がなくなります。
-* **圧縮** - サーバーレスポンスを圧縮できます
-* **キャッシング** - キャッシュされたリクエストに対して、レスポンスを返します
-* **静的コンテンツ** - 静的コンテンツを直接送信することができます。
-    * HTML/CSS/JS
-    * 写真
-    * 動画
-    * などなど
+- **より堅牢なセキュリティ** - バックエンドサーバーの情報を隠したり、IP アドレスをブラックリスト化したり、クライアントごとの接続数を制限したりできます。
+- **スケーラビリティや柔軟性が増します** - クライアントはリバースプロキシの IP しか見ないので、裏でサーバーをスケールしたり、設定を変えやすくなります。
+- **SSL termination** - 入力されるリクエストを解読し、サーバーのレスポンスを暗号化することでサーバーがこのコストのかかりうる処理をしなくて済むようになります。
+  - [X.509 証明書](https://en.wikipedia.org/wiki/X.509) を各サーバーにインストールする必要がなくなります。
+- **圧縮** - サーバーレスポンスを圧縮できます
+- **キャッシング** - キャッシュされたリクエストに対して、レスポンスを返します
+- **静的コンテンツ** - 静的コンテンツを直接送信することができます。
+  - HTML/CSS/JS
+  - 写真
+  - 動画
+  - などなど

 ### ロードバランサー vs リバースプロキシ

-* 複数のサーバーがある時にはロードバランサーをデプロイすると役に立つでしょう。 しばしば、ロードバランサーは同じ機能を果たすサーバー群へのトラフィックを捌きます。
-* リバースプロキシでは、上記に述べたような利点を、単一のウェブサーバーやアプリケーションレイヤーに対しても示すことができます。
-* NGINX や HAProxy などの技術はlayer 7 リバースプロキシとロードバランサーの両方をサポートします。
+- 複数のサーバーがある時にはロードバランサーをデプロイすると役に立つでしょう。 しばしば、ロードバランサーは同じ機能を果たすサーバー群へのトラフィックを捌きます。
+- リバースプロキシでは、上記に述べたような利点を、単一のウェブサーバーやアプリケーションレイヤーに対しても示すことができます。
+- NGINX や HAProxy などの技術は layer 7 リバースプロキシとロードバランサーの両方をサポートします。

 ### 欠点: リバースプロキシ

-* リバースプロキシを導入するとシステムの複雑性が増します。
-* 単一のリバースプロキシは単一障害点になりえます。一方で、複数のリバースプロキシを導入すると(例: [フェイルオーバー](https://en.wikipedia.org/wiki/Failover)) 複雑性はより増します。
+- リバースプロキシを導入するとシステムの複雑性が増します。
+- 単一のリバースプロキシは単一障害点になりえます。一方で、複数のリバースプロキシを導入すると(例: [フェイルオーバー](https://en.wikipedia.org/wiki/Failover)) 複雑性はより増します。

 ### その他の参考資料、ページ

-* [リバースプロキシ vs ロードバランサー](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/)
-* [NGINX アーキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
-* [HAProxy アーキテクチャ ガイド](http://www.haproxy.org/download/1.2/doc/architecture.txt)
-* [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy)
+- [リバースプロキシ vs ロードバランサー](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/)
+- [NGINX アーキテクチャ](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
+- [HAProxy アーキテクチャ ガイド](http://www.haproxy.org/download/1.2/doc/architecture.txt)
+- [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy)

 ## アプリケーション層

@ -745,16 +745,16 @@ Layer 7 ロードバランサーは [アプリケーションレイヤー](#通

 ### 欠点: アプリケーション層

-* アーキテクチャ、運用、そしてプロセスを考慮すると、緩く結び付けられたアプリケーション層を追加するには、モノリシックなシステムとは異なるアプローチが必要です。
-* マイクロサービスはデプロイと運用の点から見ると複雑性が増すことになります。
+- アーキテクチャ、運用、そしてプロセスを考慮すると、緩く結び付けられたアプリケーション層を追加するには、モノリシックなシステムとは異なるアプローチが必要です。
+- マイクロサービスはデプロイと運用の点から見ると複雑性が増すことになります。

 ### その他の参考資料、ページ

-* [スケールするシステムアーキテクチャを設計するためのイントロ](http://lethain.com/introduction-to-architecting-systems-for-scale)
-* [システム設計インタビューを紐解く](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
-* [サービス指向アーキテクチャ](https://en.wikipedia.org/wiki/Service-oriented_architecture)
-* [Zookeeperのイントロダクション](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper)
-* [マイクロサービスを作るために知っておきたいこと](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/)
+- [スケールするシステムアーキテクチャを設計するためのイントロ](http://lethain.com/introduction-to-architecting-systems-for-scale)
+- [システム設計インタビューを紐解く](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
+- [サービス指向アーキテクチャ](https://en.wikipedia.org/wiki/Service-oriented_architecture)
+- [Zookeeper のイントロダクション](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper)
+- [マイクロサービスを作るために知っておきたいこと](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/)

 ## データベース

@ -770,10 +770,10 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 **ACID** はリレーショナルデータベースにおける[トランザクション](https://en.wikipedia.org/wiki/Database_transaction)のプロパティの集合である

-* **不可分性** - それぞれのトランザクションはあるかないかのいずれかである
-* **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。
-* **独立性** - 同時にトランザクションを処理することは、連続的にトランザクションを処理するのと同じ結果をもたらす。
-* **永続性** - トランザクションが処理されたら、そのように保存される
+- **不可分性** - それぞれのトランザクションはあるかないかのいずれかである
+- **一貫性** - どんなトランザクションもデータベースをある確かな状態から次の状態に遷移させる。
+- **独立性** - 同時にトランザクションを処理することは、連続的にトランザクションを処理するのと同じ結果をもたらす。
+- **永続性** - トランザクションが処理されたら、そのように保存される

 リレーショナルデータベースをスケールさせるためにはたくさんの技術がある: **マスター・スレーブ レプリケーション**、 **マスター・マスター レプリケーション**、 **federation**、 **シャーディング**、 **非正規化**、 そして **SQL チューニング**

@ -789,8 +789,8 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 ##### 欠点: マスタースレーブ レプリケーション

-* スレーブをマスターに昇格させるには追加のロジックが必要になる。
-* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション)を参照
+- スレーブをマスターに昇格させるには追加のロジックが必要になる。
+- マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション)を参照

 #### マスターマスター レプリケーション

@ -804,23 +804,23 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 ##### 欠点: マスターマスター レプリケーション

-* ロードバランサーを導入するか、アプリケーションロジックを変更することでどこに書き込むかを指定しなければならない。
-* 大体のマスターマスターシステムは、一貫性が緩い（ACID原理を守っていない）もしくは、同期する時間がかかるために書き込みのレイテンシーが増加してしまっている。
-* 書き込みノードが追加され、レイテンシーが増加するにつれ書き込みの衝突の可能性が増える。
-* マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション) を参照
+- ロードバランサーを導入するか、アプリケーションロジックを変更することでどこに書き込むかを指定しなければならない。
+- 大体のマスターマスターシステムは、一貫性が緩い（ACID 原理を守っていない）もしくは、同期する時間がかかるために書き込みのレイテンシーが増加してしまっている。
+- 書き込みノードが追加され、レイテンシーが増加するにつれ書き込みの衝突の可能性が増える。
+- マスタースレーブ レプリケーション、マスターマスター レプリケーションの **両方** の欠点は[欠点: レプリケーション](#欠点-マスタースレーブ-レプリケーション) を参照

 ##### 欠点: レプリケーション

-* 新しいデータ書き込みを複製する前にマスターが落ちた場合にはそのデータが失われてしまう可能性がある。
-* 書き込みは読み取りレプリカにおいてリプレイされる。書き込みが多い場合、複製ノードが書き込みの処理のみで行き詰まって、読み取りの処理を満足に行えない可能性がある。
-* 読み取りスレーブノードの数が多ければ多いほど、複製しなければならない数も増え、複製時間が伸びてしまいます。
-* システムによっては、マスターへの書き込みはマルチスレッドで並列処理できる一方、スレーブへの複製は単一スレッドで連続的に処理しなければならない場合があります。
-* レプリケーションでは追加のハードウェアが必要になり、複雑性も増します。
+- 新しいデータ書き込みを複製する前にマスターが落ちた場合にはそのデータが失われてしまう可能性がある。
+- 書き込みは読み取りレプリカにおいてリプレイされる。書き込みが多い場合、複製ノードが書き込みの処理のみで行き詰まって、読み取りの処理を満足に行えない可能性がある。
+- 読み取りスレーブノードの数が多ければ多いほど、複製しなければならない数も増え、複製時間が伸びてしまいます。
+- システムによっては、マスターへの書き込みはマルチスレッドで並列処理できる一方、スレーブへの複製は単一スレッドで連続的に処理しなければならない場合があります。
+- レプリケーションでは追加のハードウェアが必要になり、複雑性も増します。

 ##### その他の参考資料、ページ: レプリケーション

-* [スケーラビリティ、 可用性、 スタビリティ パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
-* [マルチマスター レプリケーション](https://en.wikipedia.org/wiki/Multi-master_replication)
+- [スケーラビリティ、 可用性、 スタビリティ パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
+- [マルチマスター レプリケーション](https://en.wikipedia.org/wiki/Multi-master_replication)

 #### Federation

@ -834,14 +834,14 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 ##### 欠点: federation

-* 大規模な処理やテーブルを要するスキーマの場合、フェデレーションは効果的とは言えないでしょう。
-* どのデータベースに読み書きをするのかを指定するアプリケーションロジックを更新しなければなりません。
-* [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers)で二つのデータベースからのデータを連結するのはより複雑になるでしょう。
-* フェデレーションでは追加のハードウェアが必要になり、複雑性も増します。
+- 大規模な処理やテーブルを要するスキーマの場合、フェデレーションは効果的とは言えないでしょう。
+- どのデータベースに読み書きをするのかを指定するアプリケーションロジックを更新しなければなりません。
+- [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers)で二つのデータベースからのデータを連結するのはより複雑になるでしょう。
+- フェデレーションでは追加のハードウェアが必要になり、複雑性も増します。

 ##### その他の参考資料、ページ: federation

-* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)
+- [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)

 #### シャーディング

@ -859,17 +859,17 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 ##### 欠点: シャーディング

-* シャードに対応するようにアプリケーションロジックを変更しなければなりません。結果としてSQLクエリが複雑になります。
-* シャードではデータ配分がいびつになってしまう可能性があります。例えば、標準ユーザーの集合を持つシャードがある場合、そのシャードが他のシャードよりも重い負荷を負うことになります。
-    * リバランシングをすると複雑性がより増します。[consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) に基づいたシャーディングでは、通信データを削減することもできます。
-* 複数のシャードからのデータを連結するのはより複雑です。
-* シャーディングでは追加のハードウェアが必要になり、複雑性も増します。
+- シャードに対応するようにアプリケーションロジックを変更しなければなりません。結果として SQL クエリが複雑になります。
+- シャードではデータ配分がいびつになってしまう可能性があります。例えば、標準ユーザーの集合を持つシャードがある場合、そのシャードが他のシャードよりも重い負荷を負うことになります。
+  - リバランシングをすると複雑性がより増します。[consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) に基づいたシャーディングでは、通信データを削減することもできます。
+- 複数のシャードからのデータを連結するのはより複雑です。
+- シャーディングでは追加のハードウェアが必要になり、複雑性も増します。

 ##### その他の参考資料、ページ: シャーディング

-* [シャードの登場](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
-* [シャードデータベースアーキテクチャ](https://en.wikipedia.org/wiki/Shard_(database_architecture))
-* [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)
+- [シャードの登場](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
+- [シャードデータベースアーキテクチャ](<https://en.wikipedia.org/wiki/Shard_(database_architecture)>)
+- [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)

 #### 非正規化

@ -881,13 +881,13 @@ SQLなどのリレーショナルデータベースはテーブルに整理さ

 ##### 欠点: 非正規化

-* データが複製される。
-* 冗長なデータの複製が同期されるように制約が存在し、そのことでデータベース全体の設計が複雑化する。
-* 非正規化されたデータベースは過大な書き込みを処理しなければならない場合、正規化されているそれよりもパフォーマンスにおいて劣る可能性がある。
+- データが複製される。
+- 冗長なデータの複製が同期されるように制約が存在し、そのことでデータベース全体の設計が複雑化する。
+- 非正規化されたデータベースは過大な書き込みを処理しなければならない場合、正規化されているそれよりもパフォーマンスにおいて劣る可能性がある。

 ###### その他の参考資料、ページ: 非正規化

-* [Denormalization](https://en.wikipedia.org/wiki/Denormalization)
+- [Denormalization](https://en.wikipedia.org/wiki/Denormalization)

 #### SQL チューニング

@ -895,49 +895,49 @@ SQLチューニングは広範な知識を必要とする分野で多くの [本

 ボトルネックを明らかにし、シミュレートする上で、 **ベンチマーク** を定め、 **プロファイル** することはとても重要です。

-* **ベンチマーク** - [ab](http://httpd.apache.org/docs/2.2/programs/ab.html)などのツールを用いて、高負荷の状況をシミュレーションしてみましょう。
-* **プロファイル** - [slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) などのツールを用いて、パフォーマンス状況の確認をしましょう。
+- **ベンチマーク** - [ab](http://httpd.apache.org/docs/2.2/programs/ab.html)などのツールを用いて、高負荷の状況をシミュレーションしてみましょう。
+- **プロファイル** - [slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) などのツールを用いて、パフォーマンス状況の確認をしましょう。

 ベンチマークとプロファイルをとることで以下のような効率化の選択肢をとることになるでしょう。

 ##### スキーマを絞る

-* MySQLはアクセス速度向上のため、ディスク上の連続したブロックへデータを格納しています。
-* 長さの決まったフィールドに対しては `VARCHAR` よりも `CHAR` を使うようにしましょう。
-    * `CHAR` の方が効率的に速くランダムにデータにアクセスできます。 一方、 `VARCHAR` では次のデータに移る前にデータの末尾を検知しなければならないために速度が犠牲になります。
-* ブログの投稿など、大きなテキストには TEXT を使いましょう。 TEXT ではブーリアン型の検索も可能です。 TEXT フィールドには、テキストブロックが配置されている、ディスク上の場所へのポインターが保存されます。
-* 2の32乗や40億以下を超えない程度の大きな数には INT を使いましょう。
-* 通貨に関しては小数点表示上のエラーを避けるために `DECIMAL` を使いましょう。
-* 大きな `BLOBS` を保存するのは避けましょう。どこからそのオブジェクトを取ってくることができるかの情報を保存しましょう。
-* `VARCHAR(255)` は8ビットで数えられる最大の文字数です。一部のDBMSでは、1バイトの利用効率を最大化するためにこの文字数がよく使われます。
-* [検索性能向上のため](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) 、可能であれば `NOT NULL` 制約を設定しましょう。
+- MySQL はアクセス速度向上のため、ディスク上の連続したブロックへデータを格納しています。
+- 長さの決まったフィールドに対しては `VARCHAR` よりも `CHAR` を使うようにしましょう。
+  - `CHAR` の方が効率的に速くランダムにデータにアクセスできます。 一方、 `VARCHAR` では次のデータに移る前にデータの末尾を検知しなければならないために速度が犠牲になります。
+- ブログの投稿など、大きなテキストには TEXT を使いましょう。 TEXT ではブーリアン型の検索も可能です。 TEXT フィールドには、テキストブロックが配置されている、ディスク上の場所へのポインターが保存されます。
+- 2 の 32 乗や 40 億以下を超えない程度の大きな数には INT を使いましょう。
+- 通貨に関しては小数点表示上のエラーを避けるために `DECIMAL` を使いましょう。
+- 大きな `BLOBS` を保存するのは避けましょう。どこからそのオブジェクトを取ってくることができるかの情報を保存しましょう。
+- `VARCHAR(255)` は 8 ビットで数えられる最大の文字数です。一部の DBMS では、1 バイトの利用効率を最大化するためにこの文字数がよく使われます。
+- [検索性能向上のため](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search) 、可能であれば `NOT NULL` 制約を設定しましょう。

 ##### インデックスを効果的に用いる

-* クエリ(`SELECT`、 `GROUP BY`、 `ORDER BY`、 `JOIN`) の対象となる列にインデックスを使うことで速度を向上できるかもしれません。
-* インデックスは通常、平衡探索木である[B木](https://en.wikipedia.org/wiki/B-tree)の形で表されます。B木によりデータは常にソートされた状態になります。また検索、順次アクセス、挿入、削除を対数時間で行えます。
-* インデックスを配置することはデータをメモリーに残すことにつながりより容量を必要とします。
-* インデックスの更新も必要になるため書き込みも遅くなります。
-* 大量のデータをロードする際には、インデックスを切ってからデータをロードして再びインデックスをビルドした方が速いことがあります。
+- クエリ(`SELECT`、 `GROUP BY`、 `ORDER BY`、 `JOIN`) の対象となる列にインデックスを使うことで速度を向上できるかもしれません。
+- インデックスは通常、平衡探索木である[B 木](https://en.wikipedia.org/wiki/B-tree)の形で表されます。B 木によりデータは常にソートされた状態になります。また検索、順次アクセス、挿入、削除を対数時間で行えます。
+- インデックスを配置することはデータをメモリーに残すことにつながりより容量を必要とします。
+- インデックスの更新も必要になるため書き込みも遅くなります。
+- 大量のデータをロードする際には、インデックスを切ってからデータをロードして再びインデックスをビルドした方が速いことがあります。

 ##### 高負荷なジョインを避ける

-* パフォーマンス上必要なところには[非正規化](#非正規化)を適用する
+- パフォーマンス上必要なところには[非正規化](#非正規化)を適用する

 ##### テーブルのパーティション

-* テーブルを分割し、ホットスポットを独立したテーブルに分離してメモリーに乗せられるようにする。
+- テーブルを分割し、ホットスポットを独立したテーブルに分離してメモリーに乗せられるようにする。

 ##### クエリキャッシュを調整する

-* 場合によっては[クエリキャッシュ](http://dev.mysql.com/doc/refman/5.7/en/query-cache) が[パフォーマンス問題](https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/) を引き起こす可能性がある
+- 場合によっては[クエリキャッシュ](http://dev.mysql.com/doc/refman/5.7/en/query-cache) が[パフォーマンス問題](https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/) を引き起こす可能性がある

 ##### その他の参考資料、ページ: SQL チューニング

-* [MySQLクエリを最適化するためのTips](http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-suck)
-* [VARCHAR(255)をやたらよく見かけるのはなんで？](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
-* [null値はどのようにパフォーマンスに影響するのか？](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
-* [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)
+- [MySQL クエリを最適化するための Tips](http://20bits.com/article/10-tips-for-optimizing-mysql-queries-that-dont-suck)
+- [VARCHAR(255)をやたらよく見かけるのはなんで？](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
+- [null 値はどのようにパフォーマンスに影響するのか？](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
+- [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)

 ### NoSQL

@ -945,9 +945,9 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、

 **BASE** はしばしば NoSQL データベースのプロパティを説明するために用いられます。[CAP Theorem](#cap-理論) と対照的に、BASE は一貫性よりも可用性を優先します。

-* **Basically available** - システムは可用性を保証します。
-* **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。
-* **結果整合性** - システム全体は時間経過とともにその間に入力がないという前提のもと、一貫性が達成されます。
+- **Basically available** - システムは可用性を保証します。
+- **Soft state** - システムの状態は入力がなくても時間経過とともに変化する可能性があります。
+- **結果整合性** - システム全体は時間経過とともにその間に入力がないという前提のもと、一貫性が達成されます。

 [SQL か？NoSQL か？](#sqlかnosqlか) を選択するのに加えて、どのタイプの NoSQL がどの使用例に最も適するかを理解するのはとても有益です。このセクションでは **キーバリューストア**、 **ドキュメントストア**、 **ワイドカラムストア**、 と **グラフデータベース** について触れていきます。

@ -963,16 +963,16 @@ 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://adayinthelifeof.nl/2011/02/06/memcache-internals/)
+- [キーバリューデータベース](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://adayinthelifeof.nl/2011/02/06/memcache-internals/)

 #### ドキュメントストア

 > 概要: ドキュメントがバリューとして保存されたキーバリューストア

-ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binaryなど)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、APIもしくはクエリ言語を提供します。 *メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによって二つドキュメントストアとの境界線が曖昧になってしまっています。*
+ドキュメントストアはオブジェクトに関する全ての情報を持つドキュメント(XML、 JSON、 binary など)を中心に据えたシステムです。ドキュメントストアでは、ドキュメント自身の内部構造に基づいた、API もしくはクエリ言語を提供します。 _メモ：多くのキーバリューストアでは、値のメタデータを扱う機能を含んでいますが、そのことによって二つドキュメントストアとの境界線が曖昧になってしまっています。_

 以上のことを実現するために、ドキュメントはコレクション、タグ、メタデータやディレクトリなどとして整理されています。ドキュメント同士はまとめてグループにできるものの、それぞれで全く異なるフィールドを持つ可能性があります。

@ -982,10 +982,10 @@ NoSQL は **key-value store**、 **document-store**、 **wide column store**、

 ##### その他の参考資料、ページ: ドキュメントストア

-* [ドキュメント指向 データベース](https://en.wikipedia.org/wiki/Document-oriented_database)
-* [MongoDB アーキテクチャ](https://www.mongodb.com/mongodb-architecture)
-* [CouchDB アーキテクチャ](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/)
-* [Elasticsearch アーキテクチャ](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up)
+- [ドキュメント指向 データベース](https://en.wikipedia.org/wiki/Document-oriented_database)
+- [MongoDB アーキテクチャ](https://www.mongodb.com/mongodb-architecture)
+- [CouchDB アーキテクチャ](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/)
+- [Elasticsearch アーキテクチャ](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up)

 #### ワイドカラムストア

@ -1005,10 +1005,10 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha

 ##### その他の参考資料、ページ: ワイドカラムストア

-* [SQL & NoSQL簡単に歴史をさらう](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)
-* [Bigtable アーキテクチャ](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)
-* [HBase アーキテクチャ](https://www.mapr.com/blog/in-depth-look-hbase-architecture)
-* [Cassandra アーキテクチャ](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html)
+- [SQL & NoSQL 簡単に歴史をさらう](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)
+- [Bigtable アーキテクチャ](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)
+- [HBase アーキテクチャ](https://www.mapr.com/blog/in-depth-look-hbase-architecture)
+- [Cassandra アーキテクチャ](http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/architecture/architectureIntro_c.html)

 #### グラフデータベース

@ -1026,17 +1026,17 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha

 ##### その他の参考資料、ページ: グラフ

-* [Graphデータベース](https://en.wikipedia.org/wiki/Graph_database)
-* [Neo4j](https://neo4j.com/)
-* [FlockDB](https://blog.twitter.com/2010/introducing-flockdb)
+- [Graph データベース](https://en.wikipedia.org/wiki/Graph_database)
+- [Neo4j](https://neo4j.com/)
+- [FlockDB](https://blog.twitter.com/2010/introducing-flockdb)

 #### その他の参考資料、ページ: NoSQL

-* [基本用語の説明](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)
-* [NoSQLデータベースについて調査と選択ガイド](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)
-* [スケーラビリティ](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
-* [NoSQLのイントロダクション](https://www.youtube.com/watch?v=qI_g07C_Q5I)
-* [NoSQLパターン](http://horicky.blogspot.com/2009/11/nosql-patterns.html)
+- [基本用語の説明](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)
+- [NoSQL データベースについて調査と選択ガイド](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)
+- [スケーラビリティ](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
+- [NoSQL のイントロダクション](https://www.youtube.com/watch?v=qI_g07C_Q5I)
+- [NoSQL パターン](http://horicky.blogspot.com/2009/11/nosql-patterns.html)

 ### SQL か？NoSQL か？

@ -1048,37 +1048,37 @@ Googleは[Bigtable](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/cha

 **SQL** を選ぶ理由:

-* 構造化されたデータ
-* 厳格なスキーマ
-* リレーショナルデータ
-* 複雑なジョインをする必要性
-* トランザクション
-* スケールする際のパターンが明確なとき
-* 開発者の数、コミュニティ、コード等がより充実している
-* インデックスによるデータ探索はとても速い
+- 構造化されたデータ
+- 厳格なスキーマ
+- リレーショナルデータ
+- 複雑なジョインをする必要性
+- トランザクション
+- スケールする際のパターンが明確なとき
+- 開発者の数、コミュニティ、コード等がより充実している
+- インデックスによるデータ探索はとても速い

 **NoSQL** を選ぶ理由:

-* 準構造化されたデータ
-* ダイナミックないし、フレキシブルなスキーマ
-* ノンリレーショナルなデータ
-* 複雑なジョインをする必要がない
-* データの多くのTB (もしくは PB) を保存する
-* 集中的、大規模なデータ負荷に耐えられる
-* IOPSについては極めて高いスループットを示す
+- 準構造化されたデータ
+- ダイナミックないし、フレキシブルなスキーマ
+- ノンリレーショナルなデータ
+- 複雑なジョインをする必要がない
+- データの多くの TB (もしくは PB) を保存する
+- 集中的、大規模なデータ負荷に耐えられる
+- IOPS については極めて高いスループットを示す

 NoSQL に適するサンプルデータ:

-* 急激なクリックストリームやログデータの収集
-* リーダーボードやスコアリングデータ
-* ショッピングカートなどの一時的情報
-* 頻繁にアクセスされる ('ホットな') テーブル
-* メタデータやルックアップテーブル
+- 急激なクリックストリームやログデータの収集
+- リーダーボードやスコアリングデータ
+- ショッピングカートなどの一時的情報
+- 頻繁にアクセスされる ('ホットな') テーブル
+- メタデータやルックアップテーブル

 ##### その他の参考資料、ページ: 　 SQL もしくは NoSQL

-* [最初の1000万ユーザーにスケールアップするために](https://www.youtube.com/watch?v=w95murBkYmU)
-* [SQLとNoSQLの違い](https://www.sitepoint.com/sql-vs-nosql-differences/)
+- [最初の 1000 万ユーザーにスケールアップするために](https://www.youtube.com/watch?v=w95murBkYmU)
+- [SQL と NoSQL の違い](https://www.sitepoint.com/sql-vs-nosql-differences/)

 ## キャッシュ

@ -1114,15 +1114,15 @@ NoSQLに適するサンプルデータ:

 Redis はさらに以下のような機能を備えています:

-* パージステンス設定
-* ソート済みセット、リストなどの組み込みデータ構造
+- パージステンス設定
+- ソート済みセット、リストなどの組み込みデータ構造

 キャッシュには様々なレベルのものがありますが、いずれも大きく二つのカテゴリーのいずれかに分類することができます: **データベースクエリ** と **オブジェクト** です:

-* 行レベル
-* クエリレベル
-* Fully-formed serializable objects
-* Fully-rendered HTML
+- 行レベル
+- クエリレベル
+- Fully-formed serializable objects
+- Fully-rendered HTML

 一般的に、ファイルベースキャッシングはクローンを作り出してオートスケーリングを難しくしてしまうので避けるべきです。

@ -1130,22 +1130,22 @@ Redisはさらに以下のような機能を備えています:

 データベースをクエリする際には必ずクエリをキーとしてハッシュして結果をキャッシュに保存しましょう。この手法はキャッシュ期限切れ問題に悩むことになります:

-* 複雑なクエリによりキャッシュされた結果を削除することが困難
-* テーブルセルなどのデータ断片が変化した時に、その変化したセルを含むかもしれない全てのキャッシュされたクエリを削除する必要がある。
+- 複雑なクエリによりキャッシュされた結果を削除することが困難
+- テーブルセルなどのデータ断片が変化した時に、その変化したセルを含むかもしれない全てのキャッシュされたクエリを削除する必要がある。

 ### オブジェクトレベルでのキャッシング

 データをアプリケーションコードでそうするように、オブジェクトとして捉えてみましょう。アプリケーションに、データベースからのデータセットをクラスインスタンスやデータ構造として組み立てさせます。:

-* そのデータが変更されたら、オブジェクトをキャッシュから削除すること
-* 非同期処理を許容します: ワーカーがキャッシュされたオブジェクトの中で最新のものを集めてきます
+- そのデータが変更されたら、オブジェクトをキャッシュから削除すること
+- 非同期処理を許容します: ワーカーがキャッシュされたオブジェクトの中で最新のものを集めてきます

 何をキャッシュするか:

-* ユーザーのセッション
-* 完全にレンダーされたウェブページ
-* アクテビティストリーム
-* ユーザーグラフデータ
+- ユーザーのセッション
+- 完全にレンダーされたウェブページ
+- アクテビティストリーム
+- ユーザーグラフデータ

 ### いつキャッシュを更新するか

@ -1161,10 +1161,10 @@ Redisはさらに以下のような機能を備えています:

 アプリケーションはストレージへの読み書きの処理をします。キャッシュはストレージとは直接やりとりをしません。アプリケーションは以下のことをします:

-* キャッシュの中のエントリを参照しますが、結果としてキャッシュミスになります
-* データベースからエントリを取得します
-* エントリをキャッシュに追加します
-* エントリを返します
+- キャッシュの中のエントリを参照しますが、結果としてキャッシュミスになります
+- データベースからエントリを取得します
+- エントリをキャッシュに追加します
+- エントリを返します

 ```python
 def get_user(self, user_id):
@ -1183,9 +1183,9 @@ def get_user(self, user_id):

 ##### 欠点: キャッシュアサイド

-* 各キャッシュミスは三つのトリップを呼び出すことになり、体感できるほどの遅延が起きてしまいます。
-* データベースのデータが更新されるとキャッシュデータは古いものになってしまいます。time-to-live (TTL)を設定することでキャッシュエントリの更新を強制的に行う、もしくはライトスルーを採用することでこの問題は緩和できます。
-* ノードが落ちると、新規の空のノードで代替されることでレイテンシーが増加することになります。
+- 各キャッシュミスは三つのトリップを呼び出すことになり、体感できるほどの遅延が起きてしまいます。
+- データベースのデータが更新されるとキャッシュデータは古いものになってしまいます。time-to-live (TTL)を設定することでキャッシュエントリの更新を強制的に行う、もしくはライトスルーを採用することでこの問題は緩和できます。
+- ノードが落ちると、新規の空のノードで代替されることでレイテンシーが増加することになります。

 #### ライトスルー

@ -1197,9 +1197,9 @@ def get_user(self, user_id):

 アプリケーションはキャッシュをメインのデータストアとして使い、そこにデータの読み書きを行います。一方、キャッシュはデータベースへの読み書きを担当します。

-* アプリケーションはキャッシュにあるエントリを追加・更新します
-* キャッシュは同期的にデータストアに書き込みを行います
-* エントリを返します
+- アプリケーションはキャッシュにあるエントリを追加・更新します
+- キャッシュは同期的にデータストアに書き込みを行います
+- エントリを返します

 アプリケーションコード:

@ -1219,8 +1219,8 @@ def set_user(user_id, values):

 ##### 欠点: ライトスルー

-* ノードが落ちたこと、もしくはスケーリングによって新しいノードが作成された時に、新しいノードはデータベース内のエントリーが更新されるまではエントリーをキャッシュしません。キャッシュアサイドとライトスルーを併用することでこの問題を緩和できます。
-* 書き込まれたデータの大部分は一度も読み込まれることはありません。このデータはTTLによって圧縮することができます。
+- ノードが落ちたこと、もしくはスケーリングによって新しいノードが作成された時に、新しいノードはデータベース内のエントリーが更新されるまではエントリーをキャッシュしません。キャッシュアサイドとライトスルーを併用することでこの問題を緩和できます。
+- 書き込まれたデータの大部分は一度も読み込まれることはありません。このデータは TTL によって圧縮することができます。

 #### ライトビハインド (ライトバック)

@ -1232,13 +1232,13 @@ def set_user(user_id, values):

 ライトビハインドではアプリケーションは以下のことをします:

-* キャッシュのエントリーを追加・更新します
-* データストアへの書き込みを非同期的に行うことで、書き込みパフォーマンスを向上させます。
+- キャッシュのエントリーを追加・更新します
+- データストアへの書き込みを非同期的に行うことで、書き込みパフォーマンスを向上させます。

 ##### 欠点: ライトビハインド

-* キャッシュがデータストア内のコンテンツにヒットする前にキャッシュが落ちるとデータ欠損が起きる可能性があります。
-* キャッシュアサイドやライトスルーよりも実装が複雑になります。
+- キャッシュがデータストア内のコンテンツにヒットする前にキャッシュが落ちるとデータ欠損が起きる可能性があります。
+- キャッシュアサイドやライトスルーよりも実装が複雑になります。

 #### リフレッシュアヘッド

@ -1254,23 +1254,23 @@ def set_user(user_id, values):

 ##### 欠点: リフレッシュアヘッド

-* どのアイテムが必要になるかの予測が正確でない場合にはリフレッシュアヘッドがない方がレイテンシーは良いという結果になってしまいます。
+- どのアイテムが必要になるかの予測が正確でない場合にはリフレッシュアヘッドがない方がレイテンシーは良いという結果になってしまいます。

 ### 欠点: キャッシュ

-* [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms)などを用いて、データベースなどの真のデータとキャッシュの間の一貫性を保つ必要があります。
-* Redisやmemcachedを追加することでアプリケーション構成を変更する必要があります。
-* Cache invalidationも難しいですがそれに加えて、いつキャッシュを更新するかという複雑な問題にも悩まされることになります。
+- [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms)などを用いて、データベースなどの真のデータとキャッシュの間の一貫性を保つ必要があります。
+- Redis や memcached を追加することでアプリケーション構成を変更する必要があります。
+- Cache invalidation も難しいですがそれに加えて、いつキャッシュを更新するかという複雑な問題にも悩まされることになります。

 ### その他の参考資料、ページ

-* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
-* [スケーラブルなシステムデザインパターン](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
-* [スケールできるシステムを設計するためのイントロダクション](http://lethain.com/introduction-to-architecting-systems-for-scale/)
-* [スケーラビリティ、可用性、安定性、パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
-* [スケーラビリティ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
-* [AWS ElastiCacheのストラテジー](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html)
-* [Wikipedia](https://en.wikipedia.org/wiki/Cache_(computing))
+- [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
+- [スケーラブルなシステムデザインパターン](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
+- [スケールできるシステムを設計するためのイントロダクション](http://lethain.com/introduction-to-architecting-systems-for-scale/)
+- [スケーラビリティ、可用性、安定性、パターン](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
+- [スケーラビリティ](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
+- [AWS ElastiCache のストラテジー](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html)
+- [Wikipedia](<https://en.wikipedia.org/wiki/Cache_(computing)>)

 ## 非同期処理

@ -1286,8 +1286,8 @@ def set_user(user_id, values):

 メッセージキューはメッセージを受け取り、保存し、配信します。もし、処理がインラインで行うには遅すぎる場合、以下のようなワークフローでメッセージキューを用いるといいでしょう:

-* アプリケーションはジョブをキューに配信し、ユーザーにジョブステータスを伝えます。
-* ワーカーがジョブキューから受け取って、処理を行い、終了したらそのシグナルを返します。
+- アプリケーションはジョブをキューに配信し、ユーザーにジョブステータスを伝えます。
+- ワーカーがジョブキューから受け取って、処理を行い、終了したらそのシグナルを返します。

 ユーザーの処理が止まることはなく、ジョブはバックグラウンドで処理されます。この間に、クライアントはオプションとして、タスクが完了したかのように見せるために小規模の処理を行います。例えば、ツイートを投稿するときに、ツイートはすぐにあなたのタイムラインに反映されたように見えますが、そのツイートが実際に全てのフォロワーに配信されるまでにはもう少し時間がかかっているでしょう。

@ -1309,14 +1309,14 @@ def set_user(user_id, values):

 ### 欠点: 非同期処理

-* キューを用いることで遅延が起こり、複雑さも増すため、あまり重くない計算処理やリアルタイムワークフローにおいては同期処理の方がいいでしょう。
+- キューを用いることで遅延が起こり、複雑さも増すため、あまり重くない計算処理やリアルタイムワークフローにおいては同期処理の方がいいでしょう。

 ### その他の参考資料、ページ

-* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
-* [オーバーロードした時にバックプレッシャーを適用する](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
-* [Little's law](https://en.wikipedia.org/wiki/Little%27s_law)
-* [メッセージキューとタスクキューの違いとは？](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)
+- [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
+- [オーバーロードした時にバックプレッシャーを適用する](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
+- [Little's law](https://en.wikipedia.org/wiki/Little%27s_law)
+- [メッセージキューとタスクキューの違いとは？](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)

 ## 通信

@ -1332,23 +1332,23 @@ HTTP はクライアントとサーバー間でのデータをエンコードし

 基本的な HTTP リクエストは HTTP 動詞(メソッド)とリソース(エンドポイント)で成り立っています。以下がよくある HTTP 動詞です。:

-| 動詞 | 詳細 | 冪等性* | セーフ | キャッシュできるか |
-|---|---|---|---|---|
+| 動詞   | 詳細                                               | 冪等性\* | セーフ | キャッシュできるか                   |
+| ------ | -------------------------------------------------- | -------- | ------ | ------------------------------------ |
 | GET    | リソースを読み取る                                 | Yes      | Yes    | Yes                                  |
 | POST   | リソースを作成するもしくはデータを処理するトリガー | No       | No     | Yes レスポンスが新しい情報を含む場合 |
 | PUT    | リソースを作成もしくは入れ替える                   | Yes      | No     | No                                   |
 | PATCH  | リソースを部分的に更新する                         | No       | No     | Yes レスポンスが新しい情報を含む場合 |
 | DELETE | リソースを削除する                                 | Yes      | No     | No                                   |

-*何度呼んでも同じ結果が返ってくること*
+_何度呼んでも同じ結果が返ってくること_

 HTTP は**TCP** や **UDP** などの低級プロトコルに依存しているアプリケーションレイヤーのプロトコルである。

 #### その他の参考資料、ページ: HTTP

-* [HTTPってなに?](https://www.nginx.com/resources/glossary/http/)
-* [HTTP と TCPの違い](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
-* [PUT と PATCHの違い](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)
+- [HTTP ってなに?](https://www.nginx.com/resources/glossary/http/)
+- [HTTP と TCP の違い](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
+- [PUT と PATCH の違い](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)

 ### 伝送制御プロトコル (TCP)

@ -1360,10 +1360,10 @@ HTTPは**TCP** や **UDP** などの低級プロトコルに依存している

 TCP は[IP network](https://en.wikipedia.org/wiki/Internet_Protocol)の上で成り立つ接続プロトコルです。接続は[handshake](https://en.wikipedia.org/wiki/Handshaking)によって開始、解除されます。全ての送信されたパケットは欠損なしで送信先に送信された順番で到達するように以下の方法で保証されています:

-* シーケンス番号と[checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation)が全てのパケットに用意されている
-* [Acknowledgement](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks))パケットと自動再送信
+- シーケンス番号と[checksum fields](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation)が全てのパケットに用意されている
+- [Acknowledgement](<https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)>)パケットと自動再送信

-もし送信者が正しいレスポンスを受け取らなかったとき、パケットを再送信します。複数のタイムアウトがあったとき、接続は解除されます。TCP は[フロー制御](https://en.wikipedia.org/wiki/Flow_control_(data)) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの機能によって速度は低下し、一般的にUDPよりも非効率な転送手段になっています。
+もし送信者が正しいレスポンスを受け取らなかったとき、パケットを再送信します。複数のタイムアウトがあったとき、接続は解除されます。TCP は[フロー制御](<https://en.wikipedia.org/wiki/Flow_control_(data)>) と [輻輳制御](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control)も実装しています。これらの機能によって速度は低下し、一般的に UDP よりも非効率な転送手段になっています。

 ハイスループットを実現するために、ウェブサーバーはかなり大きな数の TCP 接続を開いておくことがあり、そのことでメモリー使用が圧迫されます。ウェブサーバスレッドと例えば[memcached](#memcached) サーバーの間で多数のコネクションを保っておくことは高くつくかもしれません。可能なところでは UDP に切り替えるだけでなく[コネクションプーリング](https://en.wikipedia.org/wiki/Connection_pool)なども役立つかもしれません。

@ -1371,8 +1371,8 @@ TCPは高い依存性を要し、時間制約が厳しくないものに適し

 以下の時に UDP よりも TCP を使うといいでしょう:

-* 全てのデータが欠損することなしに届いてほしい
-* ネットワークスループットの最適な自動推測をしてオペレーションしたい
+- 全てのデータが欠損することなしに届いてほしい
+- ネットワークスループットの最適な自動推測をしてオペレーションしたい

 ### ユーザデータグラムプロトコル (UDP)

@ -1390,18 +1390,18 @@ UDPは信頼性の面では劣りますが、VoIP、ビデオチャット、ス

 TCP よりも UDP を使うのは:

-* レイテンシーを最低限に抑えたい時
-* データ欠損よりも、データ遅延を重視するとき
-* エラー修正を自前で実装したいとき
+- レイテンシーを最低限に抑えたい時
+- データ欠損よりも、データ遅延を重視するとき
+- エラー修正を自前で実装したいとき

 #### その他の参考資料、ページ: TCP と UDP

-* [ゲームプログラミングのためのネットワーク](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
-* [TCP と UDP プロトコルの主な違い](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
-* [TCP と UDPの違い](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
-* [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
-* [User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
-* [Facebookのメムキャッシュスケーリング](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)
+- [ゲームプログラミングのためのネットワーク](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
+- [TCP と UDP プロトコルの主な違い](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
+- [TCP と UDP の違い](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
+- [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
+- [User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
+- [Facebook のメムキャッシュスケーリング](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)

 ### 遠隔手続呼出 (RPC)

@ -1415,12 +1415,12 @@ RPCではクライアントがリモートサーバーなどの異なるアド

 RPC は リクエストレスポンスプロトコル:

-* **クライアントプログラム** - クライアントスタブプロシージャーを呼び出します。パラメータはローカルでのプロシージャーコールのようにスタックへとプッシュされていきます。
-* **クライアントスタブプロシージャー** - プロシージャIDとアーギュメントをパックしてリクエストメッセージにします。
-* **クライアント通信モジュール** - OSがクライアントからサーバーへとメッセージを送ります。
-* **サーバー通信モジュール** - OSが受け取ったパケットをサーバースタブプロシージャーに受け渡します。
-* **サーバースタブプロシージャー** -  結果を展開し、プロシージャーIDにマッチするサーバープロシージャーを呼び出し、結果を返します。
-* サーバーレスポンスは上記のステップを逆順で繰り返します。
+- **クライアントプログラム** - クライアントスタブプロシージャーを呼び出します。パラメータはローカルでのプロシージャーコールのようにスタックへとプッシュされていきます。
+- **クライアントスタブプロシージャー** - プロシージャ ID とアーギュメントをパックしてリクエストメッセージにします。
+- **クライアント通信モジュール** - OS がクライアントからサーバーへとメッセージを送ります。
+- **サーバー通信モジュール** - OS が受け取ったパケットをサーバースタブプロシージャーに受け渡します。
+- **サーバースタブプロシージャー** - 結果を展開し、プロシージャー ID にマッチするサーバープロシージャーを呼び出し、結果を返します。
+- サーバーレスポンスは上記のステップを逆順で繰り返します。

 Sample RPC calls:

@ -1438,19 +1438,19 @@ RPCは振る舞いを公開することに焦点を当てています。RPCは

 ネイティブライブラリー (aka SDK) を呼ぶのは以下の時:

-* ターゲットのプラットフォームを知っている時
-* ロジックがどのようにアクセスされるのかを管理したいとき
-* ライブラリー外でエラーがどのようにコントロールされるかを管理したい時
-* パフォーマンスとエンドユーザーエクスペリエンスが最優先の時
+- ターゲットのプラットフォームを知っている時
+- ロジックがどのようにアクセスされるのかを管理したいとき
+- ライブラリー外でエラーがどのようにコントロールされるかを管理したい時
+- パフォーマンスとエンドユーザーエクスペリエンスが最優先の時

 **REST** プロトコルに従う HTTP API はパブリック API においてよく用いられます。

 #### 欠点: RPC

-* RPCクライアントとはサービス実装により厳密に左右されることになります。
-* 新しいオペレーション、使用例があるたびに新しくAPIが定義されなければなりません。
-* RPCをデバッグするのは難しい可能性があります。
-* 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPCコールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。
+- RPC クライアントとはサービス実装により厳密に左右されることになります。
+- 新しいオペレーション、使用例があるたびに新しく API が定義されなければなりません。
+- RPC をデバッグするのは難しい可能性があります。
+- 既存のテクノロジーをそのまま使ってサービスを構築することはできないかもしれません。例えば、[Squid](http://www.squid-cache.org/)などのサーバーに[RPC コールが正しくキャッシュ](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) されるように追加で骨を折る必要があるかもしれません。

 ### Representational state transfer (REST)

@ -1458,10 +1458,10 @@ RESTは、クライアントがサーバーによってマネージされるリ

 RESTful なインターフェースには次の四つの特徴があります:

-* **特徴的なリソース (URI in HTTP)** - どのオペレーションであっても同じURIを使う。
-* **HTTP動詞によって変わる (Verbs in HTTP)** - 動詞、ヘッダー、ボディを使う
-* **自己説明的なエラーメッセージ (status response in HTTP)** - ステータスコードを使い、新しく作ったりしないこと。
-* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - 自分のwebサービスがブラウザで完全にアクセスできること。
+- **特徴的なリソース (URI in HTTP)** - どのオペレーションであっても同じ URI を使う。
+- **HTTP 動詞によって変わる (Verbs in HTTP)** - 動詞、ヘッダー、ボディを使う
+- **自己説明的なエラーメッセージ (status response in HTTP)** - ステータスコードを使い、新しく作ったりしないこと。
+- **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTML interface for HTTP)** - 自分の web サービスがブラウザで完全にアクセスできること。

 サンプル REST コール:

@ -1476,15 +1476,15 @@ RESTはデータを公開することに焦点を当てています。クライ

 #### 欠点: REST

-* RESTはデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、とあるイベントのセットにマッチするすべての更新情報を返すと言った処理は簡単にはパスで表現することができません。RESTでは、URIパス、クエリパラメータ、そして場合によってはリクエストボディなどによって実装されることが多いでしょう。
-* RESTは少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。
-* ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。
-* 時が経つにつれて、APIレスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。
+- REST はデータ公開に焦点を当てているので、リソースが自然に整理されていなかったり、シンプルなヒエラルキーで表せられない時にはよい選択肢とは言えないかもしれません。例えば、とあるイベントのセットにマッチするすべての更新情報を返すと言った処理は簡単にはパスで表現することができません。REST では、URI パス、クエリパラメータ、そして場合によってはリクエストボディなどによって実装されることが多いでしょう。
+- REST は少数の動詞に依存しています(GET、POST、PUT、DELETE、そして PATCH) が時には使いたい事例に合わないことがあります。例えば、期限の切れたドキュメントをアーカイブに移したい場合などはこれらの動詞の中には綺麗にはフィットしません。
+- ネストされたヒエラルキーの中にあるリソースをとってくるのはシングルビューを描画するのにクライアントとサーバー間で数回やりとりしなければなりません。例として、ブログエントリーのコンテンツとそれに対するコメントを表示する場合などです。様々なネットワーク環境で動作する可能性が考えられるモバイルアプリケーションにおいてはこのような複数のやり取りは好ましくありません。
+- 時が経つにつれて、API レスポンスにより多くのフィールドが与えられて、古いクライアントはすでにいらないものも含めてすべてのデータフィールドを受け取ることになります。そのことで、ペイロードが大きくなりすぎて、レイテンシーも拡大することになります。

 ### RPC と REST 比較

 | Operation                         | RPC                                                                                       | REST                                                         |
-|---|---|---|
+| --------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
 | サインアップ                      | **POST** /signup                                                                          | **POST** /persons                                            |
 | リザイン                          | **POST** /resign<br/>{<br/>"personid": "1234"<br/>}                                       | **DELETE** /persons/1234                                     |
 | Person 読み込み                   | **GET** /readPerson?personid=1234                                                         | **GET** /persons/1234                                        |
@ -1499,14 +1499,14 @@ RESTはデータを公開することに焦点を当てています。クライ

 #### その他の参考資料、ページ: REST と RPC

-* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
-* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)
-* [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc)
-* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)
-* [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
-* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
-* [Thrift](https://code.facebook.com/posts/1468950976659943/)
-* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)
+- [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
+- [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)
+- [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc)
+- [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)
+- [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
+- [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
+- [Thrift](https://code.facebook.com/posts/1468950976659943/)
+- [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)

 ## セキュリティ

@ -1514,15 +1514,15 @@ RESTはデータを公開することに焦点を当てています。クライ

 セキュリティは幅広いトピックです。十分な経験、セキュリティ分野のバックグラウンドがなくても、セキュリティの知識を要する職に応募するのでない限り、基本以上のことを知る必要はないでしょう。

-* 情報伝達、保存における暗号化
-* [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) や [SQL injection](https://en.wikipedia.org/wiki/SQL_injection)を防ぐために、全てのユーザー入力もしくはユーザーに露出される入力パラメーターをサニタイズする
-* SQL injectionを防ぐためにパラメータ化されたクエリを用いる。
-* [least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)の原理を用いる
+- 情報伝達、保存における暗号化
+- [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) や [SQL injection](https://en.wikipedia.org/wiki/SQL_injection)を防ぐために、全てのユーザー入力もしくはユーザーに露出される入力パラメーターをサニタイズする
+- SQL injection を防ぐためにパラメータ化されたクエリを用いる。
+- [least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)の原理を用いる

 ### その他の参考資料、ページ:

-* [開発者のためのセキュリティガイド](https://github.com/FallibleInc/security-guide-for-developers)
-* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)
+- [開発者のためのセキュリティガイド](https://github.com/FallibleInc/security-guide-for-developers)
+- [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)

 ## 補遺

@ -1545,7 +1545,7 @@ RESTはデータを公開することに焦点を当てています。クライ

 #### その他の参考資料、ページ:

-* [2の乗数表](https://en.wikipedia.org/wiki/Power_of_two)
+- [2 の乗数表](https://en.wikipedia.org/wiki/Power_of_two)

 ### 全てのプログラマーが知るべきレイテンシー値

@ -1577,12 +1577,12 @@ Notes

 上記表に基づいた役に立つ数値:

-* ディスクからの連続読み取り速度 30 MB/s
-* 1 Gbps Ethernetからの連続読み取り速度　100 MB/s
-* SSDからの連続読み取り速度 1 GB/s
-* main memoryからの連続読み取り速度 4 GB/s
-* 1秒で地球6-7周できる
-* 1秒でデータセンターと2000周やりとりできる
+- ディスクからの連続読み取り速度 30 MB/s
+- 1 Gbps Ethernet からの連続読み取り速度　 100 MB/s
+- SSD からの連続読み取り速度 1 GB/s
+- main memory からの連続読み取り速度 4 GB/s
+- 1 秒で地球 6-7 周できる
+- 1 秒でデータセンターと 2000 周やりとりできる

 #### レイテンシーの視覚的表

@ -1590,17 +1590,17 @@ Notes

 #### その他の参考資料、ページ:

-* [全てのプログラマーが知るべきレイテンシー値 - 1](https://gist.github.com/jboner/2841832)
-* [全てのプログラマーが知るべきレイテンシー値 - 2](https://gist.github.com/hellerbarde/2843375)
-* [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
-* [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)
+- [全てのプログラマーが知るべきレイテンシー値 - 1](https://gist.github.com/jboner/2841832)
+- [全てのプログラマーが知るべきレイテンシー値 - 2](https://gist.github.com/hellerbarde/2843375)
+- [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
+- [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)

 ### 他のシステム設計面接例題

 > 頻出のシステム設計面接課題とその解答へのリンク

 | 質問                                                   | 解答                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-|---|---|
+| ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Dropbox のようなファイル同期サービスを設計する         | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc)                                                                                                                                                                                                                                                                                                                                                                                                  |
 | Google のような検索エンジンの設計                      | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)<br/>[stackexchange.com](http://programmers.stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)<br/>[ardendertat.com](http://www.ardendertat.com/2012/01/11/implementing-search-engines/)<br/>[stanford.edu](http://infolab.stanford.edu/~backrub/google.html)                                                                                            |
 | Google のようなスケーラブルな web クローラーの設計     | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch)                                                                                                                                                                                                                                                                                                                                                                               |
@ -1609,7 +1609,7 @@ Notes
 | Memcached のようなキャッシュシステムの設計             | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached)                                                                                                                                                                                                                                                                                                                                                                              |
 | Amazon のようなレコメンデーションシステムの設計        | [hulu.com](http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)<br/>[ijcai13.org](http://ijcai13.org/files/tutorial_slides/td3.pdf)                                                                                                                                                                                                                                                                                                             |
 | Bitly のような URL 短縮サービスの設計                  | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/)                                                                                                                                                                                                                                                                                                                                                                                                    |
-| WhatsAppのようなチャットアプリの設計 | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)
+| WhatsApp のようなチャットアプリの設計                  | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)                                                                                                                                                                                                                                                                                                                              |
 | Instagram のような写真共有サービスの設計               | [highscalability.com](http://highscalability.com/flickr-architecture)<br/>[highscalability.com](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)                                                                                                                                                                                                                                                 |
 | Facebook ニュースフィードの設計                        | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)<br/>[quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed)<br/>[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture)                                                                                                                    |
 | Facebook タイムラインの設計                            | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)<br/>[highscalability.com](http://highscalability.com/blog/2012/1/23/facebook-timeline-brought-to-you-by-the-power-of-denormaliza.html)                                                                                                                                                                                                                                          |
@ -1636,19 +1636,19 @@ Notes

 **以下の記事の重箱の隅をつつくような細かい詳細にこだわらないこと。むしろ**

-* 共通の原理、技術、パターンを探ること
-* それぞれのコンポーネントでどんな問題が解決され、コンポーネントはどこでうまく使えもしくは使えないかを知ること
-* 学んだことを復習すること
+- 共通の原理、技術、パターンを探ること
+- それぞれのコンポーネントでどんな問題が解決され、コンポーネントはどこでうまく使えもしくは使えないかを知ること
+- 学んだことを復習すること

 | 種類             | システム                                                                       | 参考ページ                                                                                                                                     |
-|---|---|---|
+| ---------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
 | データ処理       | **MapReduce** - Google の分散データ処理システム                                | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf)                     |
 | データ処理       | **Spark** - Databricks の分散データ処理システム                                | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture)                                                             |
 | データ処理       | **Storm** - Twitter の分散データ処理システム                                   | [slideshare.net](http://www.slideshare.net/previa/storm-16094009)                                                                              |
 |                  |                                                                                |                                                                                                                                                |
 | データストア     | **Bigtable** - Google のカラム指向分散データベース                             | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)                                                    |
 | データストア     | **HBase** - Bigtable のオープンソース実装                                      | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase)                                                                         |
-| データストア | **Cassandra** - Facebookのカラム指向分散データベース | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)
+| データストア     | **Cassandra** - Facebook のカラム指向分散データベース                          | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666)                                           |
 | データストア     | **DynamoDB** - Amazon のドキュメント指向分散データベース                       | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf)                                                   |
 | データストア     | **MongoDB** - ドキュメント指向分散データベース                                 | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb)                                                                    |
 | データストア     | **Spanner** - Google のグローバル分散データベース                              | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf)                                                                 |
@ -1659,7 +1659,7 @@ Notes
 | ファイルシステム | **Hadoop File System (HDFS)** - GFS のオープンソース実装                       | [apache.org](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html)                                                                           |
 |                  |                                                                                |                                                                                                                                                |
 | Misc             | **Chubby** - 疎結合の分散システムをロックする Google のサービス                | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
-| Misc | **Dapper** - 分散システムを追跡するインフラ | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf)
+| Misc             | **Dapper** - 分散システムを追跡するインフラ                                    | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf)                                |
 | Misc             | **Kafka** - LinkedIn による Pub/sub メッセージキュー                           | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug)                                                                          |
 | Misc             | **Zookeeper** - 同期を可能にする中央集権インフラとサービス                     | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper)                                                       |
 |                  | アーキテクチャを追加する                                                       | [Contribute](#contributing)                                                                                                                    |
@ -1667,7 +1667,7 @@ Notes
 ### 各企業のアーキテクチャ

 | 企業           | 参考ページ                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-|---|---|
+| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
 | Amazon         | [Amazon architecture](http://highscalability.com/amazon-architecture)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
 | Cinchcast      | [Producing 1,500 hours of audio every day](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | DataSift       | [Realtime datamining At 120,000 tweets per second](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
@ -1697,51 +1697,51 @@ Notes
 >
 > 投げられる質問は同じ分野から来ることもあるでしょう

-* [Airbnb Engineering](http://nerds.airbnb.com/)
-* [Atlassian Developers](https://developer.atlassian.com/blog/)
-* [Autodesk Engineering](http://cloudengineering.autodesk.com/blog/)
-* [AWS Blog](https://aws.amazon.com/blogs/aws/)
-* [Bitly Engineering Blog](http://word.bitly.com/)
-* [Box Blogs](https://www.box.com/blog/engineering/)
-* [Cloudera Developer Blog](http://blog.cloudera.com/blog/)
-* [Dropbox Tech Blog](https://tech.dropbox.com/)
-* [Engineering at Quora](http://engineering.quora.com/)
-* [Ebay Tech Blog](http://www.ebaytechblog.com/)
-* [Evernote Tech Blog](https://blog.evernote.com/tech/)
-* [Etsy Code as Craft](http://codeascraft.com/)
-* [Facebook Engineering](https://www.facebook.com/Engineering)
-* [Flickr Code](http://code.flickr.net/)
-* [Foursquare Engineering Blog](http://engineering.foursquare.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/)
-* [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering)
-* [High Scalability](http://highscalability.com/)
-* [Instagram Engineering](http://instagram-engineering.tumblr.com/)
-* [Intel Software Blog](https://software.intel.com/en-us/blogs/)
-* [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/)
-* [LinkedIn Engineering](http://engineering.linkedin.com/blog)
-* [Microsoft Engineering](https://engineering.microsoft.com/)
-* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)
-* [Netflix Tech Blog](http://techblog.netflix.com/)
-* [Paypal Developer Blog](https://devblog.paypal.com/category/engineering/)
-* [Pinterest Engineering Blog](http://engineering.pinterest.com/)
-* [Quora Engineering](https://engineering.quora.com/)
-* [Reddit Blog](http://www.redditblog.com/)
-* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)
-* [Slack Engineering Blog](https://slack.engineering/)
-* [Spotify Labs](https://labs.spotify.com/)
-* [Twilio Engineering Blog](http://www.twilio.com/engineering)
-* [Twitter Engineering](https://engineering.twitter.com/)
-* [Uber Engineering Blog](http://eng.uber.com/)
-* [Yahoo Engineering Blog](http://yahooeng.tumblr.com/)
-* [Yelp Engineering Blog](http://engineeringblog.yelp.com/)
-* [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering)
+- [Airbnb Engineering](http://nerds.airbnb.com/)
+- [Atlassian Developers](https://developer.atlassian.com/blog/)
+- [Autodesk Engineering](http://cloudengineering.autodesk.com/blog/)
+- [AWS Blog](https://aws.amazon.com/blogs/aws/)
+- [Bitly Engineering Blog](http://word.bitly.com/)
+- [Box Blogs](https://www.box.com/blog/engineering/)
+- [Cloudera Developer Blog](http://blog.cloudera.com/blog/)
+- [Dropbox Tech Blog](https://tech.dropbox.com/)
+- [Engineering at Quora](http://engineering.quora.com/)
+- [Ebay Tech Blog](http://www.ebaytechblog.com/)
+- [Evernote Tech Blog](https://blog.evernote.com/tech/)
+- [Etsy Code as Craft](http://codeascraft.com/)
+- [Facebook Engineering](https://www.facebook.com/Engineering)
+- [Flickr Code](http://code.flickr.net/)
+- [Foursquare Engineering Blog](http://engineering.foursquare.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/)
+- [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering)
+- [High Scalability](http://highscalability.com/)
+- [Instagram Engineering](http://instagram-engineering.tumblr.com/)
+- [Intel Software Blog](https://software.intel.com/en-us/blogs/)
+- [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/)
+- [LinkedIn Engineering](http://engineering.linkedin.com/blog)
+- [Microsoft Engineering](https://engineering.microsoft.com/)
+- [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)
+- [Netflix Tech Blog](http://techblog.netflix.com/)
+- [Paypal Developer Blog](https://devblog.paypal.com/category/engineering/)
+- [Pinterest Engineering Blog](http://engineering.pinterest.com/)
+- [Quora Engineering](https://engineering.quora.com/)
+- [Reddit Blog](http://www.redditblog.com/)
+- [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)
+- [Slack Engineering Blog](https://slack.engineering/)
+- [Spotify Labs](https://labs.spotify.com/)
+- [Twilio Engineering Blog](http://www.twilio.com/engineering)
+- [Twitter Engineering](https://engineering.twitter.com/)
+- [Uber Engineering Blog](http://eng.uber.com/)
+- [Yahoo Engineering Blog](http://yahooeng.tumblr.com/)
+- [Yelp Engineering Blog](http://engineeringblog.yelp.com/)
+- [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering)

 #### その他の参考資料、ページ:

-* [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)
+- [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)

 ここにあるリストは比較的小規模なものにとどめ、[kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)により詳細に記すことで重複しないようにしておくことにする。エンジニアブログへのリンクを追加する場合はここではなく、engineering-blogs レボジトリに追加することを検討してください。

@ -1749,10 +1749,10 @@ Notes

 セクションの追加や、進行中の作業を手伝っていただける場合は[こちら](#contributing)!

-* MapReduceによる分散コンピューティング
-* Consistent hashing
-* Scatter gather
-* [Contribute](#contributing)
+- MapReduce による分散コンピューティング
+- Consistent hashing
+- Scatter gather
+- [Contribute](#contributing)

 ## クレジット

@ -1760,15 +1760,15 @@ Notes

 Special thanks to:

-* [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/)
-* [Cracking the coding interview](https://www.amazon.com/dp/0984782850/)
-* [High scalability](http://highscalability.com/)
-* [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview)
-* [shashank88/system_design](https://github.com/shashank88/system_design)
-* [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering)
-* [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f)
-* [A distributed systems reading list](http://dancres.github.io/Pages/)
-* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
+- [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/)
+- [Cracking the coding interview](https://www.amazon.com/dp/0984782850/)
+- [High scalability](http://highscalability.com/)
+- [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview)
+- [shashank88/system_design](https://github.com/shashank88/system_design)
+- [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering)
+- [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f)
+- [A distributed systems reading list](http://dancres.github.io/Pages/)
+- [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)

 ## Contact info

@ -1778,7 +1778,7 @@ My contact info can be found on my [GitHub page](https://github.com/donnemartin)

 ## License

-*I am providing code and resources in this repository to you under an open source license.  Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook).*
+_I am providing code and resources in this repository to you under an open source license. Because this is my personal repository, the license you receive to my code and resources is from me and not my employer (Facebook)._

    Copyright 2017 Donne Martin