Design system question

Question 1

What is Scaling, vertical scaling, horizontal scaling and difference between them and adventages and disadventages?

Answer 1

[1] Scalability
Scalability is the property of a system to handle a growing amount of work by adding resources to the system

[2] Vertical Scaling vs Horizontal scaling
vertical scaling (aka scaling up) describes adding additional resources to a system so that it meets demand. How is this different from horizontal scaling? While horizontal scaling refers to adding additional nodes, vertical scaling describes adding more power to your current machines

One of the fundamental differences between the two is that horizontal scaling requires breaking a sequential piece of logic into smaller pieces so that they can be executed in parallel across multiple machines. In many respects, vertical scaling is easier because the logic really doesn’t need to change. Rather, you’re just running the same code on higher-spec machines. However, there are many other factors to consider when determining the appropriate approach.

Question 2

How to scale Databse horizontaly and vertically?

Answer 2

[1] Horizontal scaling of DB
In a database world, horizontal scaling is usually based on the partitioning of data (each node only contains part of the data).

[2] Vertical Scaling of DB
In vertical scaling, the data lives on a single node and scaling is done through multi-core, e.g. spreading the load between the CPU and RAM resources of the machine.

Question 3

How to measure scalability?

Answer 3

The scalability of an application can be measured by the number of requests it can effectively support simultaneously. The point at which an application can no longer handle additional requests effectively is the limit of its scalability. This limit is reached when a critical hardware resource runs out, requiring different or more machines. Scaling these resources can include any combination of adjustments to CPU and physical memory (different or more machines), hard disk (bigger hard drives, less “live” data, solid state drives), and/or the network bandwidth (multiple network interface controllers, bigger NICs, fiber, etc.).

Scaling horizontally and scaling vertically are similar in that they both involve adding computing resources to your infrastructure. There are distinct differences between the two in terms of implementation and performance.

Question 4

Whered do servers come from?

Answer 4

[1] Provisioned within your own company’s data center
[2] Cloud services (Amazon EC2, Google Compute Engine, Azure VM’s)
[3] Fully managed ‘serverless’ services (Lambda, kineisi, Athena)

Question 5

What is a ‘failover’?

Answer 5

Failover is a backup operational mode in which the functions of a system component are assumed by a secondary component when the primary component becomes unavailable – either through failure or scheduled down time.

Question 6

What is cold standby failover?

Answer 6

[Secondary node behavior]
A cold failover is a manual, and therefore, delayed switch-over to a secondary system. The delay occurs because the secondary system needs to be brought online and consequently, some data can be lost.
it takes to “spin up” these cold systems. This type of configuration is far less resource-intensive than a hot configuration but it does leave potential information gaps and these can be critically important in a security event.

Cold Standby, is a redundancy method where you have a standby node (as a backup) for the primary one. This node is only used during a master failure. The rest of the time the cold standby node is shut down and only used to load a backup when needed.

[2] Data protection
Data from a primary system can be backed up on a storage system and restored on a secondary system when it is required.

[3] Failover time
a Few hours

Question 7

What is ‘Warm Standby’ failover?

Answer 7

[1] Secondary node behavior
The software component is installed and available on the secondary server, which is up and running. If a failure occurs on the primary node, the software components are started on the secondary node. This process is automated by using a cluster manager.\

[2] Data protection
Data is regularly replicated to the secondary system or stored on a shared disk

[3] Failover time
A few minutes

Question 8

What is ‘Hot Standby’ failover?

Answer 8

[1] Secondary behaviour
The software component is installed and available on both the primary node and the secondary node. The secondary system is up and running, but it does not process data until the primary node fails.

[2] Data protection
Data is replicated and both systems contain identical data. Data replication is performed based on the software capabilities.

[3] Filover time
a Few seconds

Question 9

What is sharding?

Answer 9

Sharding is a database architecture pattern related to horizontal partitioning — the practice of separating one table’s rows into multiple different tables, known as partitions. Each partition has the same schema and columns, but also entirely different rows. Likewise, the data held in each is unique and independent of the data held in other partitions.

Sharding involves breaking up one’s data into two or more smaller chunks, called logical shards. The logical shards are then distributed across separate database nodes, referred to as physical shards, which can hold multiple logical shards. Despite this, the data held within all the shards collectively represent an entire logical dataset.

Question 10

What is sharding?

medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6

Answer 10

Sharding is a method of splitting and storing a single logical dataset in multiple databases. By distributing the data among multiple machines, a cluster of database systems can store larger dataset and handle additional requests. Sharding is necessary if a dataset is too large to be stored in a single database. Moreover, many sharding strategies allow additional machines to be added. Sharding allows a database cluster to scale along with its data and traffic growth.

Question 11

What is denormalization and how does it work? Pros and cons of denormalization

Answer 11

Denormalization is a strategy used on a previously-normalized database to increase performance. The idea behind it is to add redundant data where we think it will help us the most. We can use extra attributes in an existing table, add new tables, or even create instances of existing tables

[1] Denormalization pros

• Faster reads for denormalized data
• Simpler queries for application developers
• Less compute on read operations

[2] Denormalization cons

• Slower write operations
• Additional database complexity
• Potential for data inconsistency
• Additional storage required for redundant tables

Question 12

What is CAP theorem?

https://www.bmc.com/blogs/cap-theorem/

Answer 12

In theoretical computer science, the CAP theorem also named Brewer’s theorem after computer scientist Eric Brewer, states that any distributed data store can provide only two of the following three guarantees:

CONSISTENCY - Every node provides the most recent state or does not provide a state at all. None two nodes will return different state any different time

AVAILABILITY - all reads contain data, but it might not be the most recent

PARTITION TOLERANCE - The system continues to operate despite network failures (ie; dropped partitions, slow network connections, or unavailable network connections between nodes.)

When a network partition failure happens, it must be decided whether to:
- cancel the operation and thus decrease the availability but ensure consistency or to
- proceed with the operation and thus provide availability but risk inconsistency.
Thus, if there is a network partition, one has to choose between consistency and availability. Note that consistency, as defined in the CAP theorem, is quite different from the consistency guaranteed in ACID database transactions.[4]

Eric Brewer argues that the often-used “two out of three” concept can be somewhat misleading because system designers need only to sacrifice consistency or availability in the presence of partitions, but that in many systems partitions are rare

EXPLANATION:
No distributed system is safe from network failures, thus network partitioning generally has to be tolerated. In the presence of a partition, one is then left with two options: consistency or availability. When choosing consistency over availability, the system will return an error or a time out if particular information cannot be guaranteed to be up to date due to network partitioning. When choosing availability over consistency, the system will always process the query and try to return the most recent available version of the information, even if it cannot guarantee it is up to date due to network partitioning.

In the absence of a partition, both availability and consistency can be satisfied.[9]

Database systems designed with traditional ACID guarantees in mind such as RDBMS choose consistency over availability, whereas systems designed around the BASE philosophy, common in the NoSQL movement for example, choose availability over consistency.

Question 13

What ACID?

Answer 13

ATOMICITY - either the entire transaction succeeds or the entire thing fails

CONSISTENCY - All database rules are enforced, or the entire transaction is rolled back

ISOLATION - No transaction is affected by other transaction that is still in progress

DURABILITY - Once a transaction is committed, it stays even if the system crashes immediately after.

Question 14

Give some real world scenarios when to choose Consistency and when Availability. What types f DB would you use?

Answer 14

[1] CONSISTENCY
Consistent databases should be used when the value of the information returned needs to be accurate.

Financial data is a good example. When a user logs in to their banking institution, they do not want to see an error that no data is returned, or that the value is higher or lower than it actually is. Banking apps should return the exact value of a user’s account information. In this case, banks would rely on consistent databases.

Examples of a consistent database include:

• Bank account balances
• Text messages

Database options for consistency:

• MongoDB
• Redis
• HBase

[2] AVAILABILITY
Availability databases should be used when the service is more important than the information.

An example of having a highly available database can be seen in e-commerce businesses. Online stores want to make their store and the functions of the shopping cart available 24/7 so shoppers can make purchases exactly when they need.

Database options for availability:

• Cassandra
• DynamoDB
• Cosmos DB

Some database options, like Cosmos and Cassandra, allow a user to turn a knob on which guarantee they prefer—consistency or availability.

Question 15

List problems that can occur when using caching

Answer 15

[1] EXPIRATION POLICY
The “expiration policy” dictates how long data is cached. Too long and your data might go stale, too short on your data won’t do much good.

[2] HOTSPOT PROBLEM (celebrity problem)
frequent access of the same key in a partition is known as a hotspot key

[3] COLD-START problem
There is an analogy with a cold engine and warm engine of the car. Cold cache - doesn’t have any values and can’t give you any speedup because, well, it’s empty. Warm cache has some values and can give you that speedup.

Question 16

What is IOPS?

Answer 16

the number of input-output operations per second, performed from/towards the SSD drives of the server

Question 17

Describe various eviction strategies?

Answer 17

The local cache storage is managed by an eviction strategy. The strategy determines when and if Entries needs to be evicted from the space, and is also in charge of deciding which specific Entries to evict.

[1] LRU - Least Recently Used
The oldest element is the Less Recently Used (LRU) element. The last used timestamp is updated when an element is put into the cache or an element is retrieved from the cache with a get call

[2] LFU - Least Frequently Used
For each get call on the element the number of hits is updated. When a put call is made for a new element (and assuming that the max limit is reached) the element with least number of hits, the Least Frequently Used element, is evicted.

[3] FIFO - First In First Out
Elements are evicted in the same order as they come in. When a put call is made for a new element (and assuming that the max limit is reached for the memory store) the element that was placed first (First-In) in the store is the candidate for eviction (First-Out).

Question 18

What is CDN?

Answer 18

CDN - Content Delivery Networks (CDNs)

• Geogrephically distributed
• Local hostig of: HTML, CSS, javaScript, Images
• Some limited computation may be availablea as well
• Mainly useful for static content, such as images or static web pages

A content delivery network (CDN) refers to a geographically distributed group of servers which work together to provide fast delivery of Internet content. A CDN allows for the quick transfer of assets needed for loading Internet content including HTML pages, javascript files, stylesheets, images, and videos

Question 19

What are ’The Twelve-Factor App’ principles?

https://www.redhat.com/architect/12-factor-app

Answer 19

he 12 Factor App is a set of principles that describes a way of making software that, when followed, enables companies to create code that can be released reliably, scaled quickly, and maintained in a consistent and predictable manner.

[]1 CODEBASE
One codebase tracked in revision control, many deploys
The Codebase principle states that all assets related to an application, everything from source code, the provisioning script, and configuration settings, are stored in a source code repository that is accessible to development, testing, and system administration staff. The source code repository is also accessible to all automation scripts that are part of the Continuous Integration/Continuous Delivery (CI/CD) processes that are part of the enterprise’s Software Development Lifecycle. (SDLC).

[2] DEPENDENCIES
Explicitly declare and isolate dependencies.
The principle of Dependencies asserts that only code that is unique and relevant to the purpose of the application is stored in source control.
External artifacts such as Node.js packages, Java .jar files, or .NET DLLs should be referenced in a dependencies manifest loaded into memory at development, testing, and production runtime. You want to avoid storing artifacts along with source code in the source code repository.

[3] CONFIG
Store config in the environment.
The Config principle states that configuration information is injected into the runtime environment as environment variables or as settings defined in an independent configuration file. While, in certain cases, it’s permissible to store default settings that can be overridden directly in code, settings such as port number, dependency URLs, and state settings such as DEBUG should exist separately and be applied upon deployment. Good examples of external configuration files are a Java properties file, a Kubernetes manifest file, or a docker-compose.yml file.

The benefit of keeping configuration settings separate from application logic is that you can apply configuration settings according to the deployment path. For example, you can have one set of configuration settings for a deployment intended for a testing environment and a different set for a deployment designed for a production environment.

[4] BACKING SERVICES
The Backing Services principle encourages architects to treat external components such as databases, email servers, message brokers, and independent services that can be provisioned and maintained by systems personnel as attached resources. Treating resources as backing services promotes flexibility and efficiency in the software development lifecycle (SDLC).

[5] BUILD, RELEASE, RUN
Strictly separate build and run stages.
The principle of Build, Release, and Run breaks the deployment process down into three replicable stages that can be instantiated at any time. The Build stage is where code is retrieved from the source code management system and built/compiled into artifacts stored in an artifact repository such as Docker Hub or a Maven repository. After the code is built, configuration settings are applied in the Release stage. Then, in the Run stage, a runtime environment is provisioned via scripts using a tool such as Ansible. The application and its dependencies are deployed into the newly provisioned runtime environment.

The key to Build, Release, and Run is that the process is completely ephemeral. Should anything in the pipeline be destroyed, all artifacts and environments can be reconstituted from scratch using assets stored in the source code repository.

[6] PROCESSES
Execute the app as one or more stateless processes
The principle of Processes, which can be more accurately termed stateless processes, asserts that an application developed under The 12 Factor App structure will run as a collection of stateless processes. This means that no single process keeps track of the state of another process and that no process keeps track of information such as session or workflow status. A stateless process makes scaling easier. When a process is stateless, instances can be added and removed to address a particular load burden at a given point in time. Since each process operates independently, statelessness prevents unintended side effects.

[7] PORT BINDING
Export services via port binding
The principle of Port Binding asserts that a service or application is identifiable to the network by port number, not a domain name. The reasoning is that domain names and associated IP addresses can be assigned on-the-fly by manual manipulation and automated service discovery mechanisms. Thus, using them as a point of reference is unreliable. However, exposing a service or application to the network according to port number is more reliable and easier to manage. At the least, potential issues due to a collision between port number assignment private to the network and public use of that same port number by another process publicly can be avoided using port forwarding.

[8] CONCURRENCY
Scale-out via the process mode
The principle of Concurrency recommends organizing processes according to their purpose and then separating those processes so that they can be scaled up and down according to need. As shown in the illustration above, an application is exposed to the network via web servers that operate behind a load balancer. The group of web servers behind the load balancer, in turn, uses business logic that is in Business Service processes that operate behind their own load balancer. Should the burden on the web servers increase, that group can be scaled up in an isolated manner to meet the demands at hand. However, should a bottleneck occur due to a burden placed on the Business Service, that layer can be scaled up independently.

[9] DISPOSABILITY
Maximize robustness with fast startup and graceful shutdown
The principle of Disposability asserts that applications should start and stop gracefully. This means doing all the required “housekeeping” before an application is made accessible to consumers. For example, a graceful startup will ensure that all database connections and access to other network resources are operational. Also, any other configuration work that needs to take place has taken place.
in terms of shutdown, disposability advocates ensuring that all database connections and other network resources are terminated properly and that all shutdown activity is logged, as shown in the code example shown above.

[10] Dev/Prod Parity
Keep development, staging, and production as similar as possible
The Dev/Prod Parity principle means all deployment paths are similar yet independent and that no deployment “leapfrogs” into another deployment target.

The figure above shows two versions of an application’s code. The V1 version is targeted for release to the Production environment. A new version, V2, is targeted for a Development environment. Both V1 and V2 follow a similar deployment path, from Build to Release and then Run. Should the V2 version of the code be deemed ready for Production, the artifacts and settings relevant to V2 will NOT be copied into the Production environment.

Rather, the CI/CD process will be adjusted to set the deployment target of V2 to Production. The CI/CD process will follow the expected Build, Release, and Run pattern towards that new target.

As you can see, Dev/Prod Parity is very similar to Build, Release, and Run. The important distinction is that Dev/Prod Parity ensures the same deployment process for Production as it does Development.

[11] LOGS
Treat logs as event streams
The Logs principle advocates sending log data in a stream that a variety of interested consumers can access. The process for routing log data needs to be separate from processing log data. For example, one consumer might only be interested in Error data, while another consumer might be interested in Request/Response data. Another consumer might be interested in storing all log data for event archiving. An added benefit is that even if an app dies, the log data lives on well afterward.

[12] ADMIN PROCESSES
Run admin/management tasks as one-off processes
The principle of Admin Processes states that admin processes are first-class citizens in the software development lifecycle and need to be treated as such. The illustration above shows a service named Orders that is deployed as a Docker container. Also, there is an admin service name dataSeeder, which can seed data into the Orders service. The service, dataSeeder, is an admin process that is intended to be used with Orders, as shown in the diagram below.
However, even though dataSeeder is an admin process, it is given a Build, Release, and Run deployment path similar to the Orders service. Also, it is released according to the principles of Codebase and Dev/Prod Parity. The admin process, dataSeeder, is not separate from the overall SDLC, but rather part of it.