Perspectives on Scalability

#todayilearned #devops #architecture #programming

TL;DR style notes from articles I read today.

Plan for problems. Design each layer of an application to work independently and redundantly. Use distributed architecture patterns: load balancers, web farms, clustering, mirroring and read-only replicas to manage failure.
To get a better understanding of how the application will function in the real world, view every decision as a trade-off between possibilities.
Scale out rather than scaling up, adding resources dynamically in response to demand, which allows you to scale back in as well. Simply scaling up is costlier in terms of technology cost vs returns.
Scale storage and not just servers; more of small, fast disks are better than fewer, larger disks.
Be prepared to try multiple ideas in rapid succession if the first (several) does not work.
Be prepared to rewrite even the core code as you scale.

Full post here, 5 mins read

ORMs (object relational mappers) abstract away the SQL difficulties of interacting with the backend but result in complex queries that the database cannot optimize easily. They also make tweaking of queries difficult, slowing the process down.
Synchronous, serial, coupled or locking processes such as table-level locking, waiting for a message from another node to continue or two-phase commit mechanisms should be replaced more efficiently by granular row-level locking using InnoDB and multi-phase commits.
A single copy of your database can become a bottleneck; use replication instead.
Lack of metrics like user registrations, accounts, widgets sold; low-level activities like system CPU, memory, disk & network usage; and database level activity like buffer-pool, transaction log, locking sorting, temp table and queries per second can leave dev ops and business units struggling.
Lack of feature flags leaves operations teams unable to reduce the server load in case of a spike in traffic.

Full post here, 4 mins read

A scalable distributed system continues to perform effectively as its users and/or resources grow in different directions.
Usually, a system grows in terms of more data, more processes, more machines, more users.
Scalability can be measured in terms of size, geography & administrative effort.
Size scalability is the one most developers think about. It can be in terms of resources and/or users. Adding nodes should not degrade the performance or slow the system down irrespective of resources available.
Geographical scalability implies that adding nodes is done in a way that takes cognizance of the geographical distance between existing and new nodes. Adding new nodes shouldn’t slow down the amount of time it takes to communicate among the nodes.
Administrative scalability requires that adding new nodes does not greatly increase overheads on human engineering and management resources or on security concerns.

Full post here, 9 mins read

DEV Community