Reactive Architecture: Building Scalable Systems Quiz Answers

Get Reactive Architecture: Building Scalable Systems Quiz Answers

Building Reactive Systems requires a balance between Consistency and Availability. This course will explain why that balance exists. We will discuss the CAP theorem as well as the Laws of Scalability that dictate what is possible to achieve when we build distributed systems. We will also introduce some techniques we can use to strike the right balance. All of this will be grounded in a discussion which starts first in the real world.

Enroll on Cognitive Class

Consistency, Availability, and Scalability Review

Question: True or False: The world around us is a distributed system.

  • True
  • False

Question: True or False: Software problems, and real world problems, are distinct and different. You can’t use insight from the real world to help solve problems in the software world.

  • True
  • False

Question: Scalability can be defined by saying:

  • A scalable system will be able to use additional hardware in order to improve message throughput.
  • A scalable system will be able to meet an increase in demand, but it may have to sacrifice responsiveness.
  • A scalable system will be able to improve responsiveness by adding more resources.
  • A scalable system will be able to meet an increase in demand, without sacrificing responsiveness.

Question: Consistency can be defined by saying:

  • If you ask a member of the system for the state multiple times, it should give the same answer if it is consistent.
  • If all members of the system agree on the state, in the same moment of time, then the system is consistent.
  • As long as most members of the system agree on the state, it is consistent.
  • If all members of the system agree on the state, then the system is consistent.

Question: Availability can be defined by saying:

  • An available system will never fail.
  • An available system will isolate failures so that they affect only a subset of users, or a portion of the system.
  • An available system will failover to another node to ensure it remains responsive.
  • An available system will continue to respond, even in the presence of failures.

Performance vs Scalability Review

Question: Optimizing Performance means improving:

  • The number of requests we can handle in a given period of time (i.e. requests/second).
  • The number of requests we can handle at a time (i.e. the load).
  • The time it takes to complete a single request (i.e. the latency).
  • None of the above.

Question: Optimizing Scalability means improving:

  • The number of requests we can handle in a given period of time (i.e. requests/second).
  • The time it takes to complete a single request (i.e. the latency).
  • The number of requests we can handle at a time (i.e. the load).
  • None of the above.

Question: Requests/second is a way to measure:

  • Performance
  • Scalability
  • Performance and Scalability
  • Neither Performance nor Scalability

Question: True or False: Performance improvements have a linear growth pattern. We can continue to improve performance seeing equal benefit for equal effort forever.

  • True
  • False

Question: True or False: Scalability has no theoretical limit. We may be restricted by our implementation, but in a perfectly scalable system, we could scale forever.

  • True
  • False

Question: Reactive Microservices tend to focus on:

  • Improving Performance
  • Improving Scalability

Case Study: Reactive BBQ Metrics

Question: In order to ensure that staff is as efficient as possible, the restaurant tracks the time it takes to produce an order.

Once a server enters an order into the system, and sends it to the kitchen to be cooked, the time is recorded. Then, once the order is completed, and the server has been notified, we determine the total time it took to make the order.

These numbers are then averaged over time, in order to determine if certain staff, or certain restaurants, are failing to meet standards. In that case the restaurant may request additional training in that location to try to bring the numbers back in line.

In this case, the Reactive BBQ restaurant is measuring:

  • Performance
  • Scalability
  • Both
  • Neither

Question: In addition to measuring how long it takes for the kitchen to produce an order, they are also interested in how many staff they need to get it done.

One of the things that they have experimented with is testing out different numbers of cooks in the kitchen, and then watching how that impacts the production of an order.

They have learned that during peak periods, they need at least six cooks in the kitchen, or the orders begin to suffer. During quiet periods, they can get away with less. They can go as high as eight cooks for the really busy days, but at that point the kitchen starts to get crowded. Any more than eight and the cooks start getting in each other’s way.

In this case, the Reactive BBQ is most interested in:

  • Performance
  • Scalability
  • Both
  • Neither

Question: In the front of the restaurant, one of the key measurements they look at is how many customers (or more specifically, orders) go through the restaurant in an hour.

This is a critical measurement because it helps them determine when they need to open more restaurants. The front of the restaurant has a limited capacity, so when that capacity is being reached frequently, they have to open a new location, or expand the existing one, if they want to continue to grow.

In this case, the Reactive BBQ is measuring:

  • Performance
  • Scalability
  • Both
  • Neither

Question: Online orders are an important component in the Reactive BBQ. They are becoming more important as the restaurant continues to gain popularity, and as technology changes.

In order to ensure that their online operations are running smoothly, they deploy their system across several hardware nodes. On each of those nodes they track how many requests can be handled at a time, for each part of the system.

For example, they know that in the Reservations portion of the application, they are able to accept approximately 100 simultaneous requests. Any more than that and the system begins to suffer.

In this case they are measuring:

  • Performance
  • Scalability
  • Both
  • Neither

Question: While the Reservations part of the system can handle 100 simultaneous requests, they have learned that the orders seems to struggle a bit more.

In that case they have measured that the Orders system can only handle about 50 requests per second.

This metric is measuring:

  • Performance
  • Scalability
  • Both
  • Neither

Question: One critical metric that the restaurant pays attention to, both online, and for dine in orders, is how often a particular menu item is ordered.

Any time a menu item is ordered, a record is added in the database to indicate that item has been ordered. Periodically, they count the number of records for a particular item, and group them by some time period (eg. monthly) to determine the popularity of an item. If they see a particular menu item performing well, then they might decide to increase production on that item so they can offer a promotion on it. For menu items that show poor performance, they may decide to discontinue them.

In this case the Reactive BBQ is measuring:

  • Performance
  • Scalability
  • Both
  • Neither

Discussion: A Tree Falls Review

Question: Martin heard the pine tree fall, and then the spruce tree one second later.

Grace heard the spruce tree fall, and then the pine tree one second later.

If we look at what actually happened, who is correct?

  • Martin
  • Grace
  • Neither
  • Both

Question: What additional information would allow Martin to give a definitive answer by himself, assuming he knows the speed of sound (or can look it up)?

  • The distance between the two trees.
  • His own distance from each tree.
  • Grace’s distance from each tree.
  • The height of the trees.

Question: Imagine if we didn’t care about the “correct” answer, only that we recieve a “diffinitive” answer. In otherwords, as long as we can choose between Martin and Grace’s answers, that is sufficient.

We could achieve this by:

  • Adding a third observer and taking the best 2 out of 3
  • Always ignoring Grace’s answer
  • Always ignoring Martin’s answer
  • All of the above

Consistency in Distributed Systems Review

Question: A distributed system:

  • Must be built as microservices.
  • Must be deployed to different hardware.
  • Must be deployed to different data centers.
  • Must have information that is transferred between different parts of the system.

Question: The maximum possible speed of information transfer in a distributed system is determined by:

  • The size of the payload.
  • The speed of the network.
  • The speed of the hard drive.
  • The speed of light.

Question: True or False: Leveraging ACID transactions in a database allows us to guarantee we never have to deal with stale data.

  • True
  • False

Question: Which of the following are examples of distributed systems:

Note: Make sure you select all of the correct options—there may be more than one!

  • A set of microservices.
  • A monolithic system with multiple instances, backed by a common database.
  • A group of people having a face to face meeting.
  • A group of people having a remote meeting.

Eventual Consistency Review

Question: Eventual Consistency means:

  • Causally related updates will be processed in the order they occurred.
  • Different parts of the system will always give you different answers to the same question.
  • After a system stops receiving updates, you can guarantee that all parts of the system will eventually converge on the same state.
  • Your users will hate you because they won’t understand what is happening.

Question: True or False: An Eventually Consistent system that continues to receive updates can converge on a consistent state.

  • True
  • False

Question: Which of the following are types of Eventual Consistency:

  • Strong Consistency
  • Causal Consistency
  • Conditional Consistency
  • Sequential Consistency
  • Strict Consistency

Question: Traditionally, monolithic architectures are based around:

  • Coordinated Consistency
  • Eventual Consistency
  • Causal Consistency
  • Strong Consistency

Strong Consistency Review

Question: Strong Consistency means:

  • In the absence of new updates, all members of the system will eventually reach the same state.
  • A majority, or quorum of system members must agree on the state, before it becomes visible.
  • An update to a piece of data needs agreement from more than one node, before it becomes visible.
  • All members of a system must agree on the state, before it becomes available.

Question: True or False: A real world analog for strong consistency would be a jury. With a jury, a group of people discuss a question and come to an agreed response. It is then the responsibility of a foreperson or jury leader to convey the decision.

  • True
  • False

Question: Locks enable strong consistency by:

  • Ensuring that only authorized processes can read or write data.
  • Guaranteeing that only one request for data can happen at a time.
  • Allowing multiple writers, but only one reader.
  • Tying the distributed problem to a non-distributed resource.

Question: Locks introduce a problem in the form of:

  • Consequences
  • Consistency
  • Coordination
  • Contention

Case Study: Reactive BBQ Consistency

Question: In the legacy Reactive BBQ Order System, when a server wants to edit an order, they do so by opening that order. Once the order is open on their screen, a lock is placed on that order. While that lock is in place, other servers are forbidden from working with that order. They will be unable to make changes, or view the order, until the lock is released. The lock is released once the server who owns that lock is finished making updates and has saved the order.

The case outlined here represents which of the following:

  • Eventual Consistency
  • Strong Consistency

In this situation, which of the following tasks will another staff member be able to complete while the lock is in place?

  • Add a drink to the order.
  • Check the contents of the order to determine what needs to be prepared.
  • Assist the customer in paying for the order.
  • All of the above
  • None of the above

Question: For the new Order system, the Reactive BBQ team has decided to take a different approach. Rather than locking an order, they will allow servers to edit orders simultaneously. Each server will be able to add, or remove items from an order whenever they want.

This will be handled by allowing each item to be added to an order, and then finalized. Until an item has been finalized, it won’t be sent to the kitchen to be cooked. This allows items to be added, or removed, without risk of them being cooked too early.

Each server will have their own view of the order. The system will periodically update that view with changes that have been made by other servers.

This scenario is an example of:

  • Strong Consistency
  • Eventual Consistency

This new setup contains some risks. They include which of the following:

  • A server has realized they forgot to add a discount to an item. The customer is now paying for the order. They quickly add the discount, but it doesn’t show up in time, and the customer ends up paying too much.
  • One server may attempt to remove an item, while another is finalizing it. The result of this will be highly dependent on timing. The item may get prepared, or it may get removed.
  • Two servers may each be requested to add an item to the menu by an impatient customer. They may not see each other’s updates so the item may be added and prepared twice.
  • All of the above
  • None of the above

Question: The legacy system used a similar technique for locking reservations. However, it was decided that in many cases, it would be acceptable to avoid the lock by performing a “dirty read”. In this case, when the host of a restaurant decided to access the list of reservations for their restaurant, the system could read from a database replica, instead of the primary. Because the system is reading from a replica, it is be possible that someone is in the process of changing the data on the primary, or they may have recently completed a change. Those changes would not show up in the “dirty read”. However, for the purpose of listing the reservations in the restaurant, that generally wouldn’t cause a problem.

This scenario is an example of:

  • Strong Consistency
  • Eventual Consistency

In the “dirty read” scenario, the lag on the replicas is generally less than five minutes.

Given that the lag is less than 5 minutes, which of the following situations could arise:

  • A customer created a reservation a few days before. An hour before the reservation they change the number of guests, reducing it from 6 to 4. Due to the “dirty read” the customer is assigned a table of 6 instead of the desired 4 which leaves two empty seats.
  • A customer created a reservation at home, then drove to the restaurant only to find their reservation is not found by the “dirty read”.
  • A customer cancelled a reservation moments before the scheduled time. Due to the “dirty read” that cancellation is not seen and a table remains empty when it could have been filled.
  • All of the above
  • None of the above

Discussion: Collaborating On Code Review

Question: If Martin has the code locked, and Grace edits her local copy of the code, are we still strongly consistent?

  • Yes
  • No

Question: If Martin has locked the code, and Grace decides to read her local copy of the code, are we maintaining strong consistency?

  • Yes
  • No

Question: If Martin has locked the code, and Grace decides to edit some other code that uses the function defined in the locked code, are we maintaining strong consistency?

  • Yes
  • No

Question: True or False: Common source control tools (Git, Subversion, etc) operate on an eventually consistent model.

  • True
  • False

Effect of Contention Review

Question: True or False: Assuming a single resource is in contention in a system, if multiple parts of the system try to access that resource simultaneously, then each of them will have full access to the resource.

  • True
  • False

Question: Suppose a software system relies on a database lock. The average time it takes to release that lock is 1 millisecond. 10 requests for the lock are made simultaneously.

How long between the start of the FIRST request, and the end of the FIRST request?

  • ~1 millisecond
  • ~10 millisecond
  • ~100 millisecond
  • ~1000 millisecond

How long between the start of the FIRST request, and the end of the LAST request?

  • ~1 millisecond
  • ~10 millisecond
  • ~100 millisecond
  • ~1000 millisecond

Question: Amdahls’ Law shows:

  • The effect of concurrency on a distributed system.
  • The effect of parallelization on a distributed system.
  • The effect of throughput on a distributed system.
  • The effect of contention on a distributed system.

Question: A key part of Amdahl’s Law is to recognize that:

  • Contention limits parallelization.
  • Parallelization limits throughput.
  • Throughput limits contention.
  • Scalability is linear.

Question: If multiple parts of your system are contending for a resource, such as a database lock, you can resolve this problem by:

  • Scaling your application server across more machines.
  • Adding more threads to your application server
  • Adding more CPUs to your application server
  • All of the above
  • None of the above

Question: True or False: In a system that is experiencing contention, doubling the concurrency will double the throughput.

  • True
  • False

Discussion: Scheduling A Meeting Review

Question: For these questions, it may help to draw a diagram. Draw a circle for each person. Then draw lines between the circles so that each circle is connected to each other circle. Each line represents a communication channel, so you can simply count the lines.

When arranging a meeting between 2 people, how many communication channels are there?

  • 1
  • 2
  • 3
  • 4

When arranging a meeting between 3 people, how many communication channels are there?

  • 1
  • 2
  • 3
  • 6

When arranging a meeting between 4 people, how many communication channels are there?

  • 4
  • 6
  • 8
  • 12

Question: With 4 people needing to be in a meeting, what if we made one person responsible for communicating, and organizing the meeting? How many communication channels would we have?

  • 1
  • 3
  • 4
  • 6

Question: True or False: If we designate one person to coordinate the meeting, then we have introduced a single point of failure. If that person is unable to do their job for any reason, then the meeting won’t get scheduled.

  • True
  • False

Question: We could leverage an electronic calendar to help us schedule the meeting. That calendar would suffer from which of the following problems:

  • We will still require confirmation from each person so we know for sure that they can make the meeting.
  • The calender represents that person’s schedule at some point in the past, not necessarily the present.
  • Conflicting commitments may not be entered into the calendar.
  • All of the above
  • None of the above

Effect of Coherency Delay Review

Question: True or False: Systems are incoherent, that is they lack coherence, when they don’t agree on the current state of the system.

  • True
  • False

Question: A state of coherence can be achieved by:

  • Rejecting incoherent values by leveraging a check digit, or hash code.
  • Ensuring that only one member of a system manages the state.
  • Querying multiple members of the system and looking for a majority.
  • Having members of a system communicate with each other about any changes to state.

Question: Gunther’s Universal Scalability Law takes into account:

  • Contention and Coherency Delay
  • Coherency Delay
  • Contention
  • None of the Above

Question: Gunther’s Universal Scalability Law demonstrates that:

  • Increasing concurrency can cause diminishing returns due to coherency delay.
  • Increasing concurrency can cause diminishing returns due to contention and coherency delay.
  • Increasing concurrency can cause negative returns due to contention.
  • Increasing concurrency can cause negative returns due to contention and coherency delay.

Question: True or False: Gunther’s Universal Scalability Law shows that the increased cost of communication and coordination can exceed any benefits gained from scaling up.

  • True
  • False

Laws of Scalability Review

Question: True or False: According to the “Mythical Man Month”, adding more people to a late project will usually make the project slow down, rather than speed up.

  • True
  • False

Question: The slowdown experienced in the “Mythical Man Month” occurs due to:

  • Amdahl’s Law
  • Gunther’s Law
  • Both
  • Neither

Question: A stateless system is one where:

  • State is stored in the application, and in the database.
  • State is stored in the database, rather than in the application.
  • State is stored in the application, rather than the database.
  • No state is stored, either in the application, or the database.

Question: Building Reactive Systems requires that we:

  • Build a system that is completely stateless.
  • Ignore the Laws of Scalability.
  • Avoid the distributed system problem by building a monolith.
  • Minimize the impact of the Laws of Scalability.

Question: Which of the following represent sources of contention:

Note: Make sure you select all of the correct options—there may be more than one!

  • Blocking Operations
  • Non-blocking Operations
  • Eventual Consistency
  • Transactions
  • Locks

Question: The impact of Gunther’s Universal Scalability Law can be mitigated by:

  • Adding additional nodes to the system
  • Leveraging Strong Consistency
  • Building Autonomous Systems
  • None of the Above

Case Study: The Cost of Consistency

Question: The legacy system for the Reactive BBQ is backed by a Relational Database. This database is used for all queries that the system needs to perform. It provides the legacy system with strong consistency guarantees.

The system has been configured to allow 150 simultaneous connections. With this setup, the system is able to handle about 50 orders/second.

The database connections are a way to control:

  • Coherency Delay
  • Consistency
  • Contention
  • Parallelism

Question: The legacy Reactive BBQ system has been measured at 50 orders/second. They have tried to increase that, but there appears to be a bottleneck somewhere that is preventing further improvement.

In order to alleviate this bottleneck, the database admin team has decided to increase the number of allowed connections from 150 up to 250. The hope is that by increasing the amount of connections we can have more simultaneous orders and that will hopefully allow us to improve our throughput further.

However, upon increasing the number of connections from 150 up to 250, we observed that our throughput has actually decreased. We have gone from 50 orders/second down to 45 orders/second.

The reason for the decrease in throughput may be due to:

  • Scalability
  • Contention
  • Coherency
  • Coherency Delay

Question: Because increasing the database connections didn’t provide any benefit (and in fact made it worse) the connections were reset back to 150. The team then started looking for other ways to improve the throughput of the application.

During the investigation it was observed that a particular database update was taking a fair chunk of the time. The code for the update was poorly designed and as a result it was locking the database for longer than it needed to. The resulting code was rewritten and the result was the throughput increasing from 50 orders/second to 75 orders/second.

In this case, the throughput was improved by reducing:

  • Parallelism
  • Consistency
  • Coherency Delay
  • Contention

CAP Theorem Review

Question: The CAP Theorem states that a distributed system can not provide more than two of which of the following:

Note: Make sure you select all of the correct options—there may be more than one!

  • Coherency
  • Consistency
  • Availability
  • Atomicity
  • Persistence
  • Partition Tolerance

Question: The implications of the CAP theorem are that you have to pick between which of the following combinations:

Note: Make sure you select all of the correct options—there may be more than one!

  • Consistent and Available
  • Consistent and Partition Tolerant
  • Available and Partition Tolerant
  • Consistent, Available, and Partition Tolerant

Question: Partitions can be caused by:

  • Routine Maintenance
  • System Failures
  • Problems in the network
  • All of the above
  • None of the above

Question: True or False: Certain types of networks have enough built in redundancy that they are safe from partitions.

  • True
  • False

Question: True or False: Network Partitions are short lived (less than 5 minutes). Anything longer is considered a Network Outage, and is handled differently by the CAP Theorem.

  • True
  • False

Question: During a partition, if we allow writes to both sides of the partition, and then merge back to a consistent state once the partition is resolved, we have build a system that is:

  • CA – Consistent and Available
  • CP – Consistent and Partition Tolerant
  • AP – Available and Partition Tolerant
  • CAP – Consistent, Available, and Partition Tolerant

Question: During a partition, if we disable, or terminate one side of the partition, we have built a system that is:

  • CA – Consistent and Available
  • AP – Available and Partition Tolerant
  • CP – Consistent and Partition Tolerant
  • CAP – Consistent, Available, and Partition Tolerant

Question: True or False: A system that is labeled as CP (Consistent and Partition Tolerant) will be Consistent in all cases.

  • True
  • False

Question: True or False: All systems can be classified as either CP or AP. Therefore, choosing a database that provides the appropriate guarantee is the best way to achieve this.

  • True
  • False

Case Study: Consistency or Availability

Question: The Reactive BBQ legacy system is backed by a Relational Database. This database has a single master node, as well as two replicas.

During normal operation, the system will do all reads and writes through the master node.

By doing all reads and writes through a single master node, we can guarantee:

  • Consistency
  • Availability

After a write occurs, the database will asynchronously copy the data for that write to the replicas. Each replica therefore has a “lag” associated with it. This lag indicates how close the replica is to being in sync with the master.

In the event of a failure, we can failover to one of the replicas. Typically, this failover happens very fast, with any queries being temporarily buffered or retried until the failover is complete.

When we failover to a replica, we are sacrificing:

  • Consistency
  • Availability

Question: In the new Reactive BBQ system, they plan to leverage a NoSQL database. This database operates with a multi-master setup. Reads and writes can be performed on any node in the cluster, rather than only on a single master. A “read/write concern” can be configured which determines how many nodes to read or write to before completing the operation. For simplicity, and speed, the team has decided to use a read/write concern of ONE which only reads or writes to a single node.

In the cluster of database nodes, each node will communicate the current state of the system with other nodes through a form of replication called gossip. Essentially each node will tell other nodes what they believe the state to be. In the event of a conflict, there are different strategies that could be applied. They might keep multiple versions of the data, or they might use some kind of timestamp, or vector clock to determine which record to keep. In any case, it will be important to resolve those conflicts to determine a final state.

By allowing reads and writes to go to any single database node, this system is favouring:

  • Consistency
  • Availability

As the system has continued to evolve, the team has realized that using a read/write concern of ONE has some drawbacks. They have decided to change it to use a read/write concern of MAJORITY. In this case it writes to a majority of nodes, before completing, and reads from a majority of nodes. This means in a 5 node cluster, it would write to 3 nodes and read from 3 nodes. It would then figure out how to resolve any conflicts between the results returned from those nodes.

By adjusting the read/write concern to MAJORITY instead of ONE this system has sacrificed

  • Consistency
  • Availability

Consistency And Scalability Review

Question: To provide scalability, while maintaining Consistency we look to:

  • Increase the hardware for our database master (more CPUs, more memory etc).
  • Leverage database locks with a broad scope (i.e. Table Locks) to ensure consistency.
  • Implement “dirty reads” to reduce the load on our database master.
  • Isolate sources of contention.

Question: True or False: In a Reactive System, “Sharding” is a technique that is applied in your database in order to allow the database to scale while maintaining consistency.

  • True
  • False

Sharding For Consistency Review

Question: Sharding is a technique that is used to provide:

  • Weak Availability
  • Eventual Consistency
  • High Availability
  • Strong Consistency

Question: True or False: Sharding is a technique that is limited to databases. Your application shouldn’t implement it’s own sharding.

  • True
  • False

Question: Sharding at the application level provides which of the following benefits:

  • Reduced communication between the application and the database
  • Strong Consistency
  • High Availability
  • Eventual Consistency
  • Improved Scalability

Question: We can describe Sharding by saying that:

  • Sharding leverages a message driven architecture to ensure that all messages are delivered to their recipients at least once.
  • Sharding guarantees that entities (or actors) who share a unique Id will be distributed across a cluster.
  • Sharding replicates entities (or actors) within a cluster to ensure the system is resilient.
  • Sharding partitions entities or actors in the domain according to their unique Id.

Question: Groups of Entities are called:

  • Entity Groups
  • Shard Regions
  • Nodes
  • Shards

Question: In a Sharded Reservation System, we would find the entity “Reservation A” on:

  • A majority of nodes in our cluster, distributed randomly.
  • Every node in our cluster
  • Only a single node, determined by the hash code of the entity Id.
  • Only a single node, determined by the Shard that Reservation A belongs to.

Question: Which of the following are suitable Sharding candidates:

  • Controllers
  • Value Objects
  • Entity Streams
  • Aggregate Roots

Question: The Shard Coordinator will:

  • Host the shards and entities in the cluster.
  • Determine how much thread time each entity is allowed to use.
  • Guarantee that traffic to the entities is evenly balanced across the cluster.
  • Ensure messages are routed to the appropriate entity.

Question: Good Shard Keys possess which of the following qualities:

  • Ordered Distribution
  • Low Cardinality
  • Randomized Distribution
  • Idempotence
  • Even Distribution

Question: True or False: A Unix Timestamp in milliseconds (eg: 946684799000) would make a good Shard Key.

  • True
  • False

Question: As a rule of thumb, how many shards should we have in our cluster?

  • One hundred shards per node in the cluster.
  • One shard per node in the cluster.
  • Ten
  • Ten shards per node in the cluster.

Effects of Sharding Review

Question: True or False: Sharding is a powerful tool because it eliminates contention in your system.

  • False
  • True

Question: Where can you find contention in a sharded system?

  • The shard key
  • The Coordinator
  • The messages
  • Within a single entity
  • Between entities

Question: True or False: Every message bound for a sharded entity must first pass through the Shard Coordinator.

  • True
  • False

Question: In a system sharded by User, which of the following will be more likely to experience contention?

  • Users who put moderate load on the system.
  • Users who are not currently using the system.
  • Users who are putting excessive load on the system.
  • All Users

Question: In a Sharded system, scalability is achieved by:

  • Redeploying the system to more powerful hardware (more CPU, more memory etc).
  • Duplicating entities on other machines to distribute the load.
  • Distributing inbound messages evenly across the cluster in a round robin fashion.
  • Distributing the shards over a larger number of machines.

Question: In a Sharded system, Strong Consistency is achieved by:

  • Setting the “strongConsistency” flag to true.
  • Leveraging a Strongly Consistent database such a typical Relational Database.
  • Locking an entity so that it becomes unavailable while a message is being processed.
  • Isolating operations to a specific entity, which processes one message at a time.

Question: True or False: In the event of an unexpected shutdown or failure, messages being sent to a sharded entity may be lost.

  • True
  • False

Question: Messages can be buffered, and delivered later when:

  • A network partition has occurred.
  • An unexpected shutdown has occurred.
  • A graceful shutdown has occurred.
  • All of the above
  • None of the above

Question: The safest, and fasted way to recover from a failure in a sharded system is to:

  • Build a custom recovery strategy.
  • Have someone login and correct the problem manually.
  • Automatically restart the entire system.
  • Leverage the Lightbend Split Brain Resolver.

Question: Sharding enables consistent caching in a distributed system by:

  • Updating the cache, and database, within a single distributed transaction.
  • Ensuring that the cached data is synchronously replicated to all nodes.
  • Moving the cache into a separate piece of infrastructure (eg. Redis).
  • Ensuring that the cached data exists in only one place in the application, and is in-sync with the database.

Question: A Sharded system can improve application efficiency by:

  • Compressing data transferred between the application and the database.
  • Eliminating database writes.
  • Buffering writes in memory before flushing to the database.
  • Eliminating database reads.

Question: True or False: Most applications are write heavy.

  • True
  • False

Case Study: Sharding the Orders

Question: True or False: By sharding the Orders, we limit contention to within each Order.

  • True
  • False

Question: Which of the following would make a good shard key for the Order

  • OrderId: Long – A Long number that is incremented each time a new order is created.
  • OrderIdHash: Integer – An Integer Hash Code generated from the OrderId.
  • OrderTime: DateTime – The Date and Time when the order was created.
  • CustomerName: String – The First and Last name of the customer.

Question: Given that our Orders system will be deployed on 5 nodes in our cluster, what is an appropriate number of Shards for this system?

  • 5
  • 10
  • 50
  • 500

Question: Our Sharding algorithm separates our Orders into a number of different shards. These shards are numbered 1 through 30.

An AddItemToOrder message is sent to our system. We use our Sharding Algorithm and determine that the entity would live in Shard 12.

Based on this, we can deliver the message to the appropriate Order by:

  • Always determining the node hosting shard 12 by communicating with the Shard Coordinator, and then sending to that node.
  • Sending to any node. Our shards will be replicated automatically to every node by the Shard Coordinator so it doesn’t matter where we send it.
  • Sending it directly to the node that hosts shard 12. This is always known, and always consistent.
  • Sending directly to the node that hosts shard 12 when it is known. When it is not known we will leverage the Shard Coordinator to determine the correct node.

Question: When accessing the Order Entity, some requests will have to go through the database, while others will be served using the Entity’s in-memory state (cache) of the data.

Assuming the entity has already been loaded into memory, which of the following operations will have to go to the database?

  • Create a new Order.
  • Add an item to an order.
  • Remove an item from an Order.
  • Get all items on an order.
  • Set the server for an order.
  • Get the server assigned to an order.

Question: True or False: By Sharding our Orders, we are improving Availability in the Orders System.

  • True
  • False

Availability And Scalability Review

Question: CRDT is short for:

  • Consistent Resilient Data Types
  • Conflict-free Resilient Data Trees
  • Consistent Replicated Data Types
  • Conflict-free Replicated Data Types

Question: CRDTs are a way to achieve which of the following:

  • Strong Consistency
  • High Availability

CRDTs For Availability Review

Question: CRDTs display which of the following characteristics:

Note: Make sure you select all of the correct options—there may be more than one!

  • Atomic Transactions
  • Strong Consistency
  • Eventual Consistency
  • High Availability
  • Linearizability

Question: With CRDTs data is:

  • Stored in a shared database that is accessible between multiple microservices.
  • Written to a single primary node, and then asynchronously copied to replicas.
  • Written to all nodes in a single transaction to ensure availability.
  • Copied asynchronously across multiple equal replicas.

Question: Which of the following are types of CRDTs:

Note: Make sure you select all of the correct options—there may be more than one!

  • CaRDTs – Cached Replicated Data Types
  • CmRDTs – Commutative Replicated Data Types
  • CoRDTs – Consistent Replicated Data Types
  • CvRDTs – Converted Replicated Data Types
  • CvRDTs – Convergent Replicated Data Types

Question: The merge operation for CRDTs must be:

Note: Make sure you select all of the correct options—there may be more than one!

  • Additive
  • Commutative
  • Associative
  • Distributive
  • Idempotent

Question: Akka Distributed Data supports which of the following:

  • CaRDTs
  • CmRDTs
  • CoRDTs
  • CvRDTs

Question: A G-Set is one that you can:

  • Add to, and remove from, but never re-add to.
  • Add or remove from.
  • Add to, but never remove from.
  • All of the above.
  • None of the above.

Question: Which of the following data types would you typically find in CRDTs like those in Akka Distributed Data:

Note: Make sure you select all of the correct options—there may be more than one!

  • Queues
  • Sets
  • Maps
  • Counters
  • Lists

Question: True or False: You can create custom CRDTs as long as you can define a merge operation.

  • True
  • False

Effects Of CRDTs Review

Question: True or False: Portions of a CRDT can be stored on disk, allowing it to be pulled into memory only when needed.

  • True
  • False

Question: Copying CRDTs to disk allows you to:

  • Speed up replication between nodes.
  • Share state between replicas.
  • Page data to disk in order to reduce memory usage.
  • Speed up recovery in the event of a failure.

Question: True or False: Some data types can not be turned into a CRDT.

  • True
  • False

Question: In CRDTs, a tombstone is:

  • An error you receive when your CRDT exceeds available memory.
  • An action that deletes an item, and removes it from the CRDT.
  • A marker to indicate something has been deleted.
  • What you receive when your boss finds out your application ran out of memory.

Question: Distributed Data is a solution for:

  • Strong Consistency
  • High Availability

Question: Read/Write Consistency in Distributed Data allows you to:

  • Update all nodes in your cluster in a transactional fashion.
  • Build systems that are both Consistent and Available at the same time.
  • Write your data to the database for consistency, but read it from memory for availability.
  • Tune your solution towards Consistency, but away from Availability.

Case Study: Distributing the Menu

Question: True or False: Our Menu will be replicated across many nodes and available in memory at all times. This allows it to have high availability.

  • True
  • False

Question: The Menu represents a good candidate for Distributed Data because:

  • The data size is relatively small.
  • Entries are uniquely identified by a Menu Item Id.
  • It receives infrequent updates (The Menu is updated once per month).
  • It is critical to the operation of the system, and needs to be available.
  • Strong Consistency is required (we wouldn’t want an incorrect price).

Question: When leveraging Akka Distributed Data, if the Menu service needs access to the Menu data, it will:

  • Read it from the local node. With Distributed Data, all data is written to all nodes simultaneously.
  • Read it out of the database.
  • Read it from the node where the data was written. The data exists only on that node.
  • Read it from the local node. Distributed Data will ensure that the data is asynchronously replicated to all nodes.

Question: A LWWMap in Distributed Data merges updates using a “Last Write Wins” scenario. It relies on clocks being synchronized. If two updates occur within the clock skew (difference between clocks) then the winner is indeterminate.

The team is considering using a LWWMap for the menu. They should avoid using an LWWMap because:

  • Menu Items won’t be uniquely identifiable, and won’t be appropriate for a Map structure.
  • The latest write doesn’t necessarily overwrite the previous data. We need a more complicated merge algorithm.
  • Concurrent updates to the menu are common and could easily happen within the clock skew.
  • All of the Above
  • None of the Above. The LWWMap could be appropriate in this case.

Question: True or False: Because the menu is asynchronously replicated to each node, providing multiple, in-memory copies of the data, we reduce the amount of contention in the system around that data.

  • True
  • False

Consistency Or Availability Review

Question: The choice between Consistency and Availability should be:

  • Unimportant in a well designed system.
  • Decided by the developers, based on the ease of implementation.
  • Determined by the choice of database.
  • Decided by the business, based on the requirements for a specific feature or portion of the system.

Question: True or False: Within the same application or system, we sometimes need consistency, and other times need availability, depending on the use case.

  • True
  • False

Question: True or False: The impact on revenue should not be considered when deciding between Consistency and Availability.

  • True
  • False
Conclusion:

We hope you know the correct answers to Reactive Architecture: Building Scalable Systems If Why Quiz helped you to find out the correct answers then make sure to bookmark our site for more Course Quiz Answers.

If the options are not the same then make sure to let us know by leaving it in the comments below.

Course Review:

In our experience, we suggest you enroll in this and gain some new skills from Professionals completely free and we assure you will be worth it.

This course is available on Cognitive Class for free, if you are stuck anywhere between quiz or graded assessment quiz, just visit Queslers to get all Quiz Answers and Coding Solutions.

More Courses Quiz Answers >>

Building Cloud Native and Multicloud Applications Quiz Answers

Accelerating Deep Learning with GPUs Quiz Answers

Leave a Reply

Your email address will not be published.