Correct spelling

1 files changed, 4 insertions, 5 deletions

diff --git a/doc/DESIGN.md b/doc/DESIGN.md
index 43e8c7572..515e3210a 100644
--- a/doc/DESIGN.md
+++ b/doc/DESIGN.md
@@ -10,8 +10,7 @@ Gitaly is a layer that brings horizontal scaling and higher availability to mass
 #### Git Architectural Characteristics and Assumptions
 
 - **Stateful, Atomic, ACID Transactions** (“database synonymous” workload with regard to memory / CPU / disk IO).
-- **Atomic Process** - that one git process is all that can be involved in servicing individual git requests.
-- **"Process Atomic" Transactions** - requires one commit to be completed by one and only one Git process.
+- **"Process Atomic" Transactions** - requires one commit to be coordinated by one and only one Git process.
 - **Atomic Storage** - assumes that operations of a single git command write to a single storage end-point.
 - **Storage channel speeds** - assumes low latency, high bandwidth storage access (near bus speeds).
 - **ACID Isolation** - by design Git allows concurrent update access to the same repository as much as possible, in the area of updating Git Refs, record locking is necessary and implemented by Git.
@@ -24,8 +23,8 @@ Gitaly is a layer that brings horizontal scaling and higher availability to mass
 These workload characteristics are not fundamentally predictable across the portfolio of source code that a given GitLab server may need to store. Large monorepos might exist at companies with few employees.  Binaries storage - while not considered an ideal file type for Git file systems - is common in some industry segments or project types. This means that architecting a GitLab instance with built-in Git headroom limitations causes unexpected limitations of specific Git usage patterns of the people using the instance.
 
 These are some of the most challenging git workloads for Git:
-- Large scale, busy monorepos (commit volume is and packs for full clones are very large).
-- High commit volume on a single repository (commits and packs for full clones are very frequent).
+- Large scale, busy monorepos (commit volume is high and packs for full clones are very large).
+- High commit volume on a single repository (commit volume is high packs for full clones are very frequent).
 - Binaries stored in the Git object database. (In GitLab Git LFS can be redirected to PaaS storage).
 - Full history cloning - due to packfile creation requirements.
 
@@ -108,4 +107,4 @@ All design decisions should be added here.
 1. By default all Go packages in the Gitaly repository use the `/internal` directory, unless we explicitly want to export something. The only exception is the `/cmd` directory for executables.
 1. GitLab requests should use as few Gitaly gRPC calls as possible. This means it is OK to move GitLab application logic into Gitaly when it saves us gRPC round trips.
 1. Defining new gRPC calls is cheap. It is better to define a new 'high level' gRPC call and save gRPC round trips than to chain / combine 'low level' gRPC calls.
-1. Why is Gitaly written in Go? At the time the project started the only practical options were Ruby and Go. We expected to be able to handle more traffic with fewer resources if we used Go. Today (Q3 2019), part of Gitaly is written in Ruby. On the particular Gitaly server that hosts gitlab-org/gitlab-ce, we have a pool of gitaly-ruby processes using a total 20GB of RSS and handling 5 requests per second. The single Gitaly Go process on that machine uses less than 3GB of memory and handles 90 requests per second.
+1. Why is Gitaly written in Go? At the time the project started the only practical options were Ruby and Go. We expected to be able to handle more traffic with fewer resources if we used Go. Today (Q3 2019), part of Gitaly is written in Ruby. On the particular Gitaly server that hosts gitlab-org/gitlab-ce, we have a pool of gitaly-ruby processes using a total 20GB of RSS and handling 5 requests per second. The single Gitaly Go process on that machine uses less than 3GB of memory and handles 90 requests per second.
\ No newline at end of file