<p>A System with components is operating in parallel If the failure of a part leads to the other part taking over the operations of the failed part.</p>
<p>If we have more than one LB and if the rest of the LBs can take over the traffic during one LB failure then LBs are operating in parallel</p>
<p>A System with components is operating in parallel if the failure of a part leads to the other part taking over the operations of the failed part.</p>
<p>If we have more than one LB and if the rest of the LBs can take over the traffic during one LB failure, then LBs are operating in parallel.</p>
<p><strong>Elimination of single points of failure (SPOF)</strong> This means adding redundancy to the system so that the failure of a component does not mean failure of the entire system.</p>
<p><strong>Reliable crossover</strong> In redundant systems, the crossover point itself tends to become a single point of failure. Reliable systems must provide for reliable crossover.</p>
<p><strong>Detection of failures as they occur</strong> If the two principles above are observed, then a user may never see a failure </p>
<p><strong>Detection of failures as they occur</strong> If the two principles above are observed, then a user may never see a failure.</p>
<p><strong>WHAT:</strong> Never implement and always eliminate single points of failure.</p>
<p><strong>WHEN TO USE:</strong> During architecture reviews and new designs.</p>
<p><strong>HOW TO USE:</strong> Identify single instances on architectural diagrams. Strive for active/active configurations. At the very least we should have a standby to take control when active instances fail.</p>
<p><strong>HOW TO USE:</strong> Identify single instances on architectural diagrams. Strive for active/active configurations. At the very least, we should have a standby to take control when active instances fail.</p>
<p><strong>WHY:</strong> Maximize availability through multiple instances.</p>
<p><strong>KEY TAKEAWAYS:</strong> Strive for active/active rather than active/passive solutions. Use load balancers to balance traffic across instances of a service. Use control services with active/passive instances for patterns that require singletons.</p>
<p><strong>WHEN TO USE:</strong> During architecture reviews, failure modeling, and designs.</p>
<p><strong>HOW TO USE:</strong> Identify how available a system is during the crossover and ensure it is within acceptable limits. </p>
<p><strong>WHY:</strong> Maximize availability and ensure data handling semantics are preserved. </p>
<p><strong>KEY TAKEAWAYS:</strong> Strive for active/active rather than active/passive solutions, they have a lesser risk of cross over being unreliable. Use LB and the right loadbalancing methods to ensure reliable failover. Model and build your data systems to ensure data is correctly handled when crossover happens. Generally, DB systems follow active/passive semantics for writes. Masters accept writes and when the master goes down, the follower is promoted to master(active from being passive) to accept writes. We have to be careful here that the cutover never introduces more than one master. This problem is called a split brain.</p>
<p><strong>KEY TAKEAWAYS:</strong> Strive for active/active rather than active/passive solutions, they have a lesser risk of cross over being unreliable. Use LB and the right load-balancing methods to ensure reliable failover. Model and build your data systems to ensure data is correctly handled when crossover happens. Generally, DB systems follow active/passive semantics for writes. Masters accept writes and when the master goes down, the follower is promoted to master(active from being passive) to accept writes. We have to be careful here that the cutover never introduces more than one master. This problem is called a split brain.</p>
<h2id="applications-in-sre-role">Applications in SRE role</h2>
<ol>
<li>SRE works on deciding an acceptable SLA and make sure the system is available to achieve the SLA</li>
<li>SRE is involved in architecture design right from building the data center to make sure the site is not affected by a network switch, hardware, power, or software failures</li>
<li>SRE also run mock drills of failures to see how the system behaves in uncharted territory and comes up with a plan to improve availability if there are misses.
<p>Armed with these principles, we hope the course will give a fresh perspective to design software systems. It might be over-engineering to get all this on day zero. But some are really important from day 0 like eliminating single points of failure, making scalable services by just increasing replicas. As a bottleneck is reached, we can split code by services, shard data to scale. As the organization matures, bringing in <ahref="https://en.wikipedia.org/wiki/Chaos_engineering">chaos engineering</a> to measure how systems react to failure will help in designing robust software systems.</p>
<p>Armed with these principles, we hope the course will give a fresh perspective to design software systems. It might be over-engineering to get all this on day zero. But some are really important from day 0 like eliminating single points of failure, making scalable services by just increasing replicas. As a bottleneck is reached, we can <em>split code by services</em>, <em>shard data</em> to scale. As the organization matures, bringing in <ahref="https://en.wikipedia.org/wiki/Chaos_engineering">chaos engineering</a> to measure how systems react to failure will help in designing robust software systems.</p>
<p>Failures are not avoidable in any system and will happen all the time, hence we need to build systems that can tolerate failures or recover from them.</p>
<ul>
<li>In systems, failure is the norm rather than the exception.</li>
<li>"Anything that can go wrong will go wrong” -- Murphy’s Law</li>
<li>“Complex systems contain changing mixtures of failures latent within them” -- How Complex Systems Fail.</li>
<li>"Anything that can go wrong will go wrong”—Murphy’s Law</li>
<li>“Complex systems contain changing mixtures of failures latent within them”—How Complex Systems Fail.</li>
<p>Common failure metrics that get measured and tracked for any system.</p>
<p><strong>Mean time to repair (MTTR):</strong> The average time to repair and restore a failed system. </p>
<p><strong>Mean time between failures (MTBF):</strong> The average operational time between one device failure or system breakdown and the next. </p>
@@ -2275,32 +2275,31 @@
<p><strong>Failure rate:</strong> Another reliability metric, which measures the frequency with which a component or system fails. It is expressed as a number of failures over a unit of time.</p>
<p>Systems should have a short circuit. Say in our content sharing system, if “Notifications” is not working, the site should gracefully handle that failure by removing the functionality instead of taking the whole site down. </p>
<p>Swimlane is one of the commonly used fault isolation methodologies. Swimlane adds a barrier to the service from other services so that failure on either of them won’t affect the other. Say we roll out a new feature ‘Advertisement’ in our content sharing app.
<p>If Ads are generated on the fly synchronously during each Newsfeed request, the faults in the Ads feature get propagated to the Newsfeed feature. Instead if we swimlane the “Generation of Ads” service and use a shared storage to populate Newsfeed App, Ads failures won’t cascade to Newsfeed, and worst case if Ads don’t meet SLA, we can have Newsfeed without Ads.</p>
<p>Let's take another example, we have come up with a new model for our Content sharing App. Here we roll out an enterprise content sharing App where enterprises pay for the service and the content should never be shared outside the enterprise. </p>
<p>If Ads are generated on the fly synchronously during each Newsfeed request, the faults in the Ads feature get propagated to the Newsfeed feature. Instead if we swimlane the “Generation of Ads” service and use a shared storage to populate Newsfeed App, Ads failures won’t cascade to Newsfeed, and worst case if Ads don’t meet SLA, we can have Newsfeed without Ads.</p>
<p>Let's take another example, we have come up with a new model for our Content sharing App. Here, we roll out an enterprise content sharing App where enterprises pay for the service and the content should never be shared outside the enterprise. </p>
<p><strong>Principle 1:</strong> Nothing is shared (also known as “share as little as possible”). The less that is shared within a swimlane, the more fault isolative the swimlane becomes. (as shown in Enterprise use-case)</p>
<p><strong>Principle 2:</strong> Nothing crosses a swimlane boundary. Synchronous (defined by expecting a request—not the transfer protocol) communication never crosses a swimlane boundary; if it does, the boundary is drawn incorrectly. (as shown in Ads feature)</p>
<p><strong>Principle 1:</strong> Nothing is shared (also known as “share as little as possible”). The less that is shared within a swimlane, the more fault isolative the swimlane becomes. (as shown in Enterprise use-case)</p>
<p><strong>Principle 2:</strong> Nothing crosses a swimlane boundary. Synchronous (defined by expecting a request—not the transfer protocol) communication never crosses a swimlane boundary; if it does, the boundary is drawn incorrectly. (as shown in Ads feature)</p>
<p><strong>Approach 1:</strong> Swimlane the money-maker. Never allow your cash register to be compromised by other systems. (Tier 1 vs Tier 2 in enterprise use case)</p>
<p><strong>Approach 2:</strong> Swimlane the biggest sources of incidents. Identify the recurring causes of pain and isolate them. (if Ads feature is in code yellow, swimlaning it is the best option)</p>
<p><strong>Approach 3:</strong> Swimlane natural barriers. Customer boundaries make good swimlanes. (Public vs Enterprise customers)</p>
<p><strong>Approach 1:</strong> Swimlane the money-maker. Never allow your cash register to be compromised by other systems. (Tier 1 vs Tier 2 in enterprise use case)</p>
<p><strong>Approach 2:</strong> Swimlane the biggest sources of incidents. Identify the recurring causes of pain and isolate them. (If Ads feature is in code yellow, swimlaning it is the best option.)</p>
<p><strong>Approach 3:</strong> Swimlane natural barriers. Customer boundaries make good swimlanes. (Public vs Enterprise customers)</p>
<h3id="applications-in-sre-role">Applications in SRE role</h3>
<ol>
<li>Work with the DC tech or cloud team to distribute infrastructure such that its immune to switch or power failures by creating fault zones within a Data Center
<li>Work with the partners and design interaction between services such that one service breakdown is not amplified in a cascading fashion to all upstreams</li>
<li>Work with the DC tech or cloud team to distribute infrastructure such that it's immune to switch or power failures by creating fault zones within a Data Center (<ahref="https://docs.microsoft.com/en-us/azure/virtual-machines/manage-availability#use-availability-zones-to-protect-from-datacenter-level-failures">https://docs.microsoft.com/en-us/azure/virtual-machines/manage-availability#use-availability-zones-to-protect-from-datacenter-level-failures</a>).</li>
<li>Work with the partners and design interaction between services such that one service breakdown is not amplified in a cascading fashion to all upstreams.</li>
<p>So, how do you go about learning to design a system?</p>
<p><em>” Like most great questions, it showed a level of naivety that was breathtaking. The only short answer I could give was, essentially, that you learned how to design a system by designing systems and finding out what works and what doesn’t work.”
Jim Waldo, Sun Microsystems, On System Design</em></p>
<p>"<em>Like most great questions, it showed a level of naivety that was breathtaking. The only short answer I could give was, essentially, that you learned how to design a system by designing systems and finding out what works and what doesn’t work.</em>"—Jim Waldo, Sun Microsystems, On System Design</p>
<p>As software and hardware systems have multiple moving parts, we need to think about how those parts will grow, their failure modes, their inter-dependencies, how it will impact the users and the business.</p>
<p>There is no one-shot method or way to learn or do system design, we only learn to design systems by designing and iterating on them.</p>
<p>This course will be a starter to make one think about scalability, availability, and fault tolerance during systems design.</p>
<p>This course will be a starter to make one think about <em>scalability</em>, <em>availability</em>, and <em>fault tolerance</em> during systems design.</p>
<h2id="backstory">Backstory</h2>
<p>Let’s design a simple content sharing application where users can share photos, media in our application which can be liked by their friends. Let’s start with a simple design of the application and evolve it as we learn system design concepts</p>
<p>Let’s design a simple content sharing application where users can share photos, media in our application which can be liked by their friends. Let’s start with a simple design of the application and evolve it as we learn system design concepts.</p>
<p>What does scalability mean for a system/service? A system is composed of services/components, each service/component scalability needs to be tackled separately, and the scalability of the system as a whole.</p>
<p>A service is said to be scalable if, as resources are added to the system, it results in increased performance in a manner proportional to resources added</p>
<p>An always-on service is said to be scalable if adding resources to facilitate redundancy does not result in a loss of performance</p>
<p><strong>What does scalability mean for a system/service?</strong> A system is composed of services/components, each service/component scalability needs to be tackled separately, and the scalability of the system as a whole.</p>
<p>A service is said to be scalable if, as resources are added to the system, it results in increased performance in a manner proportional to resources added.</p>
<p>An always-on service is said to be scalable if adding resources to facilitate redundancy does not result in a loss of performance.</p>
<p>The <ahref="https://akfpartners.com/growth-blog/scale-cube">Scale Cube</a> is a model for segmenting services, defining microservices, and scaling products. It also creates a common language for teams to discuss scalerelated options in designing solutions. The following section talks about certain scaling patterns based on our inferences from the AKF cube</p>
<p>The <ahref="https://akfpartners.com/growth-blog/scale-cube">Scale Cube</a> is a model for segmenting services, defining microservices, and scaling products. It also creates a common language for teams to discuss scale-related options in designing solutions. The following section talks about certain scaling patterns based on our inferences from the AKF cube.</p>
<p>Horizontal scaling stands for cloning of an application or service such that work can easily be distributed across instances with absolutely no bias.</p>
<p>Let's see how our monolithic application improves with this principle</p>
<p>Let's see how our monolithic application improves with this principle.</p>
<p>Here DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one leader to make sure data is consistent. There are some DBs that support multi-leader writes but we are keeping them out of scope at this point.</p>
<p>Here, DB is scaled separately from the application. This is to let you know each component’s scaling capabilities can be different. Usually, web applications can be scaled by adding resources unless there is state stored inside the application. But DBs can be scaled only for Reads by adding more followers but Writes have to go to only one leader to make sure data is consistent. There are some DBs that support multi-leader writes but we are keeping them out of scope at this point.</p>
<p>Apps should be able to differentiate between Reads and Writes to choose appropriate DB servers. Load balancers can split traffic between identical servers transparently.</p>
<p><strong>WHAT:</strong> Duplication of services or databases to spread transaction load.</p>
<p><strong>WHEN TO USE:</strong> Databases with a very high read-to-write ratio (5:1 or greater—the higher the better). Because only read replicas of DBs can be scaled, not the Leader.</p>
<p><strong>HOW TO USE:</strong> Simply clone services and implement a load balancer. For databases, ensure that the accessing code understands the difference between a read and a write.</p>
<p><strong>WHY:</strong> Allows for the fast scale of transactions at the cost of duplicated data and functionality.</p>
<p><strong>KEY TAKEAWAYS:</strong> This is fast to implement, is a low cost from a developer effort perspective, and can scale transaction volumes nicely. However, they tend to be high cost from the perspective of the operational cost of data. The cost here means if we have 3 followers and 1 Leader DB, the same database will be stored as 4 copies in the 4 servers. Hence added storage cost</p>
<p><strong>KEY TAKEAWAYS:</strong> This is fast to implement, is a low cost from a developer effort perspective, and can scale transaction volumes nicely. However, they tend to be high cost from the perspective of the operational cost of data. The cost here means if we have 3 followers and 1 Leader DB, the same database will be stored as 4 copies in the 4 servers. Hence added storage cost.</p>
<p>Improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. A commonly used technique is load balancing traffic across identical server clusters. A similar philosophy is used to load balance traffic across network links by <ahref="https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing">ECMP</a>, disk drives by <ahref="https://en.wikipedia.org/wiki/RAID">RAID</a>,etc</p>
<p>Improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. A commonly used technique is load balancing traffic across identical server clusters. A similar philosophy is used to load balance traffic across network links by <ahref="https://en.wikipedia.org/wiki/Equal-cost_multi-path_routing">ECMP</a>, disk drives by <ahref="https://en.wikipedia.org/wiki/RAID">RAID</a>,etc.</p>
<p>Aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource.
Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. In our updated architecture diagram we have 4 servers to handle app traffic instead of a single server</p>
Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. In our updated architecture diagram, we have 4 servers to handle app traffic instead of a single server.</p>
<p>The device or system that performs load balancing is called a load balancer, abbreviated as LB.</p>
<h4id="refer_2">Refer</h4>
<ul>
@@ -2536,57 +2536,61 @@ Using multiple components with load balancing instead of a single component may
<p>What backends are available in the system? In our architecture, 4 servers are available to serve App traffic. LB acts as a single endpoint that clients can use transparently to reach one of the 4 servers.</p>
<h4id="health-checking">Health checking:</h4>
<p>What backends are currently healthy and available to accept requests? If one out of the 4 App servers turns bad, LB should automatically short circuit the path so that clients don’t sense any application downtime</p>
<p>What backends are currently healthy and available to accept requests? If one out of the 4 App servers turns bad, LB should automatically short circuit the path so that clients don’t sense any application downtime.</p>
<h4id="load-balancing">Load balancing:</h4>
<p>What algorithm should be used to balance individual requests across the healthy backends? There are many algorithms to distribute traffic across one of the four servers. Based on observations/experience, SRE can pick the algorithm that suits their pattern</p>
<p>What algorithm should be used to balance individual requests across the healthy backends? There are many algorithms to distribute traffic across one of the four servers. Based on observations/experience, SRE can pick the algorithm that suits their pattern.</p>
<p>directs traffic to the server with the fewest active connections. Most useful when there are a large number of persistent connections in the traffic unevenly distributed between the servers. Works if clients maintain long-lived connections</p>
<p>This method directs traffic to the server with the fewest active connections. Most useful when there are a large number of persistent connections in the traffic unevenly distributed between the servers. Works if clients maintain long-lived connections.</p>
<h4id="least-response-time-method">Least Response Time Method</h4>
<p>directs traffic to the server with the fewest active connections and the lowest average response time. Here response time is used to provide feedback of the server’s health</p>
<p>This method directs traffic to the server with the fewest active connections and the lowest average response time. Here, response time is used to provide feedback of the server’s health.</p>
<h4id="round-robin-method">Round Robin Method</h4>
<p>rotates servers by directing traffic to the first available server and then moves that server to the bottom of the queue. Most useful when servers are of equal specification and there are not many persistent connections.</p>
<p>This method rotates servers by directing traffic to the first available server and then moves that server to the bottom of the queue. Most useful when servers are of equal specification and there are not many persistent connections.</p>
<h4id="ip-hash">IP Hash</h4>
<p>the IP address of the client determines which server receives the request. This can sometimes cause skewness in distribution but is useful if apps store some state locally and need some stickiness</p>
<p>More advanced client/server-side example techniques
<p>CDNs are added closer to the client’s location. If the app has static data like images, Javascript, CSS which don’t change very often, they can be cached. Since our example is a content sharing site, static content can be cached in CDNs with a suitable expiry.</p>
<p>The IP address of the client determines which server receives the request. This can sometimes cause skewness in distribution but is useful if apps store some state locally and need some stickiness.</p>
<p>More advanced client/server-side example techniques:</p>
<p>CDNs are added closer to the client’s location. If the app has static data like images, JavaScript, CSS which don’t change very often, they can be cached. Since our example is a content-sharing site, static content can be cached in CDNs with a suitable expiry.</p>
<p><strong>WHAT:</strong> Use CDNs (content delivery networks) to offload traffic from your site.</p>
<p><strong>WHEN TO USE:</strong> When speed improvements and scale warrant the additional cost.</p>
<p><strong>HOW TO USE:</strong> Most CDNs leverage DNS to serve content on your site’s behalf. Thus you may need to make minor DNS changes or additions and move content to be served from new subdomains.</p>
<p>Eg
media-exp1.licdn.com is a domain used by Linkedin to serve static content</p>
<p>Here a CNAME points the domain to the DNS of the CDN provider</p>
<p>dig media-exp1.licdn.com +short</p>
<p>2-01-2c3e-005c.cdx.cedexis.net.</p>
<code>media-exp1.licdn.com</code> is a domain used by Linkedin to serve static content</p>
<p>Here, a CNAME points the domain to the DNS of the CDN provider.</p>
<pre><code>dig media-exp1.licdn.com +short
2-01-2c3e-005c.cdx.cedexis.net.
</code></pre>
<p><strong>WHY:</strong> CDNs help offload traffic spikes and are often economical ways to scale parts of a site’s traffic. They also often substantially improve page download times.</p>
<p><strong>KEY TAKEAWAYS:</strong> CDNs are a fast and simple way to offset the spikiness of traffic as well as traffic growth in general. Make sure you perform a cost-benefit analysis and monitor the CDN usage. If CDNs have a lot of cache misses, then we don’t gain much from CDN and are still serving requests using our compute resources. </p>
<p>This pattern represents the separation of work by service or function within the application. Microservices are meant to address the issues associated with growth and complexity in the codebase and datasets. The intent is to create fault isolation as well as to reduce response times.</p>
<p>This pattern represents the separation of work by service or function within the application. Microservices are meant to address the issues associated with growth and complexity in the codebase and datasets. The intent is to create fault isolation as well as to reduce response times.</p>
<p>Microservices can scale transactions, data sizes, and codebase sizes. They are most effective in scaling the size and complexity of your codebase. They tend to cost a bit more than horizontal scaling because the engineering team needs to rewrite services or, at the very least, disaggregate them from the original monolithic application.</p>
<p><strong>WHAT:</strong> Sometimes referred to as scale through services or resources, this rule focuses on scaling by splitting datasets, transactions, and engineering teams along verb (services) or noun (resources) boundaries.</p>
<p><strong>WHEN TO USE:</strong> Very large datasets where relations between data are not necessary. Large, complex systems where scaling engineering resources requires specialization.</p>
<p><strong>WHAT:</strong> Sometimes referred to as scale through services or resources, this rule focuses on scaling by splitting datasets, transactions, and engineering teams along verb (services) or noun (resources) boundaries.</p>
<p><strong>WHEN TO USE:</strong> Very large datasets where relations between data are not necessary. Large, complex systems where scaling engineering resources requires specialization.</p>
<p><strong>HOW TO USE:</strong> Split up actions by using verbs, or resources by using nouns, or use a mix. Split both the services and the data along the lines defined by the verb/noun approach.</p>
<p><strong>WHY:</strong> Allows for efficient scaling of not only transactions but also very large datasets associated with those transactions. It also allows for the efficient scaling of teams.</p>
<p><strong>KEY TAKEAWAYS:</strong> Microservices allow for efficient scaling of transactions, large datasets, and can help with fault isolation. It helps reduce the communication overhead of teams. The codebase becomes less complex as disjoint features are decoupled and spun as new services thereby letting each service scale independently specific to its requirement.</p>
<p><strong>WHY:</strong> Allows for efficient scaling of not only transactions but also very large datasets associated with those transactions. It also allows for the efficient scaling of teams.</p>
<p><strong>KEY TAKEAWAYS:</strong> Microservices allow for efficient scaling of transactions, large datasets, and can help with fault isolation. It helps reduce the communication overhead of teams. The codebase becomes less complex as disjoint features are decoupled and spun as new services thereby letting each service scale independently specific to its requirement.</p>
<p>This pattern represents the separation of work based on attributes that are looked up to or determined at the time of the transaction. Most often, these are implemented as splits by requestor, customer, or client.</p>
<p>Very often, a lookup service or deterministic algorithm will need to be written for these types of splits.</p>
<p>Sharding aids in scaling transaction growth, scaling instruction sets, and decreasing processing time (the last by limiting the data necessary to perform any transaction). This is more effective at scaling growth in customers or clients. It can aid with disaster recovery efforts, and limit the impact of incidents to only a specific segment of customers.</p>
@@ -2594,24 +2598,24 @@ media-exp1.licdn.com is a domain used by Linkedin to serve static content</p>
<p>Here the auth data is sharded based on user names so that DBs can respond faster as the amount of data DBs have to work on has drastically reduced during queries.</p>
<p>Here the whole data center is split and replicated and clients are directed to a data center based on their geography. This helps in improving performance as clients are directed to the closest data center and performance increases as we add more data centers. There are some replication and consistency overhead with this approach one needs to be aware of. This also gives fault tolerance by rolling out test features to one site and rollback if there is an impact to that geography</p>
<p>Here the whole data center is split and replicated and clients are directed to a data center based on their geography. This helps in improving performance as clients are directed to the closest data center and performance increases as we add more data centers. There are some replication and consistency overhead with this approach one needs to be aware of. This also gives fault tolerance by rolling out test features to one site and rollback if there is an impact to that geography.</p>
<p><strong>WHAT:</strong> This is very often a split by some unique aspect of the customer such as customer ID, name, geography, and so on.</p>
<p><strong>WHEN TO USE:</strong> Very large, similar datasets such as large and rapidly growing customer bases or when the response time for a geographically distributed customer base is important.</p>
<p><strong>WHEN TO USE:</strong> Very large, similar datasets such as large and rapidly growing customer bases or when the response time for a geographically distributed customer base is important.</p>
<p><strong>HOW TO USE:</strong> Identify something you know about the customer, such as customer ID, last name, geography, or device, and split or partition both data and services based on that attribute.</p>
<p><strong>WHY:</strong> Rapid customer growth exceeds other forms of data growth, or you have the need to perform fault isolation between certain customer groups as you scale.</p>
<p><strong>KEY TAKEAWAYS:</strong> Shards are effective at helping you to scale customer bases but can also be applied to other very large datasets that can’t be pulled apart using the microservices methodology.</p>
<p><strong>KEY TAKEAWAYS:</strong> Shards are effective at helping you to scale customer bases but can also be applied to other very large datasets that can’t be pulled apart using the microservices methodology.</p>
<li>SREs work to set up, configure, and improve the CDN cache hit rate.</li>
</ol>
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
github-actions