Reactive Architecture: Reactive Microservices Quiz Answers

All Modules Reactive Architecture: Reactive Microservices Quiz Answers

When we use the term Reactive, we are usually talking about Reactive Microservices. But what is a microservice? And how can we make it Reactive? This course will explore the difference between monoliths and microservices and show the journey to making a system Reactive.

WHAT WILL I GET AFTER PASSING THIS COURSE?

You will receive a completion certificate.
You will receive a completion badge.

Enroll on Cognitive Class

The Software Spectrum Review

Question: True or False: When building software you have to choose between building a monolith or building microservices. There is no in between.

True
False

Question: When deciding whether to build a system as a monolith or microservices we need to:

Remember that the size of the microservice is critical. All microservices should be less than 10 thousand lines of code.
Determine what kind of database will be backing our services. Relational is for Monoliths, NoSQL is for Microservices.
Realize that microservices are the future. Monoliths are archaic, and nobody is building them anymore.
Consider the benefits, and consequences of each, and try to find an appropriate balance between them.

Question: How big is a microservice?

Small enough run in 256 Mb of ram.
No bigger than a single function.
Less than 10 thousand lines of code.
All of the above.
None of the above.

Question: True or False: A single system can have some characteristics of a Monolith and other characteristics of Microservices.

False
True

Monoliths Review

Question: True or False: The term “ball of mud” is applicable to all monoliths. They are, by their very nature, a huge mess that is difficult to sort through and understand.

True
False

Question: Another name for a “Ball of Mud” is:

Bean Bag
Sludge Blossom
Lisp
Spaghetti Code

Question: True or False: The ball of mud style of architecture suffers from too much isolation between components. As a result, over time the system becomes more disconnected, and harder to modify.

True
False

Question: To clean up our monolith so that it looks less like a ball of mud, we could do which of the following:

Ensure that every method, and class, has appropriate descriptive comments.
Capture our business logic in a rules engine.
Leverage Data Driven Design to isolate our behaviour in configuration, instead of code.
Introduce domain boundaries in the form of libraries or packages.

Question: Which of the following are characteristics of a monolith?

Single Shared Database
Teams operate independently
Communicate using Asynchronous Method Calls
Deep Coupling
Deployed as a single unit

Question: A monolithic application is scaled using which of the following techniques?

Multiple copies of the monolith are deployed in a ring. These monoliths communicate with each other using a chatter protocol to ensure consistent state.
The monolith is broken into separate systems, each of which is deployed independently.
A single “master” instance is deployed along with several “slaves”. This allows the load to be distributed between the slaves.
Multiple copies of the monolith are deployed, relying on the database to maintain consistency between them.

Question: True or False: Communication between instances of a monolith typically happens through the database.

True
False

Question: What are some of the advantages of using a monolith?

Simple consistency model
Single deployment process
Nothing to monitor
Flexible scalability model
Strong coupling
Easy cross module refactoring

Question: True or False: Failures in a monolith are isolated only to that instance of the monolith. We don’t have to worry that the failure may affect other instances.

True
False

Question: What are some of the disadvantages of using a monolith?

Limited to Relational Databases
Weak consistency guarantees
Limited by the scalability of the database
Inflexibility due to deep coupling
Limited by the size of a single machine

The Monolithic BBQ

Question: If we were to make a change to the database table for Orders, which of the following models would we potentially need to edit? Note: Make sure you select all of the correct options—there may be more than one!

Delivery Model
Order Model
Customer Model

Question: Management periodically runs a report that aggregates information on different orders. These reports give them an idea which menu items are being ordered more often. They use this information for planning future menus and promotions.

Recently, it has become clear that while these reports are running, parts of the system seem to become unresponsive. Specifically, the delivery drivers seem to experience more problems with the mobile application.

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

The most likely cause of these issues is:

Coincidence.
Poor cellular reception.
The reports are flooding the network with too much data.
Resource contention on the Orders tables in the database.

Question: Recently, the team working on Reservations added a new field to the Customer table. This field allows users to specify a preferred restaurant location for their reservations. The addition of this new field required the execution of a database script that locked the customer table. During this period, the delivery drivers were unable to use the mobile application to retrieve their orders.

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

Why were the delivery drivers impacted by a change in the reservation data?

The Delivery Model wasn’t built to support the new field so it was unable to query the Customer table.
The database script put pressure on the CPU which slowed down the delivery system.
The system experienced a long GC pause which prevented the mobile application from reaching the server.
The Delivery Model relies on the Customer table so it was affected by the table lock.

How could this have been prevented? Make sure you select all of the correct options—there may be more than one!

Inform the drivers about the potential downtime so they can print out their orders ahead of time.
Isolating the new field in an independent table (eg. PreferredLocation or ReservationLocation) not used by the Delivery Model.
Avoid locking the table.
Executing the script during a maintenance window.

Question: The database backing our application has proved to be unresponsive. The operations team has analyzed the server and discovered that there is a lot of contention for disk. It turns out that the Orders portion of our system does a lot of reads and writes to the database (sometimes multiple reads/writes for a single request), and optimizing it will take a significant investment of resources. In the meantime, the contention for disk is resulting in poor performance in other parts of the system (Deliveries, Customers etc).

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

We could mitigate this problem by:

Deploying the Order service to it’s own hardware.
Deploying more copies of our application.
Deploying another replica of our database.
Upgrading the hardware on the database server (more CPU, more memory, faster disk).

Question: In an effort to mitigate contention for the database, the development team has decided to introduce an in-memory cache in the application. Each copy of the application will maintain a list of all active orders in memory. They will be unloaded from memory once the order is closed. This will reduce the number of times we have to read from the database.

They have implemented and deployed the cache, but now they are finding that application no longer fits into available memory. It turns out that other parts of the application have also implemented caches in various places and the combination of all the caches is simply too much for the system to handle.

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

Possible solutions to the memory problem are:

Delete the other caches.
Deploy additional copies of the order service.
Move the orders service to it’s own hardware.
Increase the available memory on the machine.

Service Oriented Architecture Review

Question: True or False: A key principle of Service Oriented Architecture is that Services don’t share a database.

True
False

Question: In a Service Oriented Architecture, if one service needs access to the data from another service, it can:

Do nothing. SOA services don’t share data.
Read the data from the database table directly.
Read the data from the database indirectly via a database view.
Request the data by making an API call to the service that owns the data.

Question: Which of the following are true for Service Oriented Architecture?

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

Services must live on the same physical (or virtual) machine.
Services may be deployed as a single unit (Monolith).
Services may be deployed independently (Microservices).
Services may share a database, as long as they never write to each other’s tables (Read is okay).
Service endpoints must be implemented with HTTP protocols.

Question: We can characterize the relationship between Service Oriented Architecture and Microservices by saying:

Service Oriented Architecture is a subset of Microservices. Some microservice systems are built using SOA.
Microservices and Service Oriented Architecture are different names for the same concept.
Microservices and Service Oriented Architecture are unrelated to each other.
Microservices are a subset of Service Oriented Architecture. Some SOA systems are built using microservices.

Microservices Review

Question: True or False: Microservices should all be run in their own process (eg. JVM). As long as they are running in an independent process, a suitable way to deploy them would be to package them all into a single container so there is only one thing to deploy.

True
False

Question: Microservices share which of the following characteristics with Service Oriented Architecture.

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

Services own their data, and don’t share a database.
Services are independently deployed.
Services communicate with each other through a clear API.
Individual services are packaged into a container and deployed as a group.
Services are separated along logical domain boundaries.
Services are independent and self governing.

Question: Some of the characteristics of a microservice architecture include:

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

Loose Coupling
Multiple, independent databases
Tightly coordinated release process
Strictly asynchronous communication
Rapid Deployments
Services are deployed independently

Question: True or False: Systems built on Microservices never share code.

True
False

Question: A DevOps approach means:

Teams are split into Dev, Ops, and DevOps. Dev creates the application. Ops deploys the application. DevOps maintains it in production.
Teams are split into Dev and Ops. Dev creates the application. Ops deploys it and maintains it in production.
One DevOps team is responsible for creating the application, deploying it, and maintaining it in production.
Teams are split into Dev and Ops. Dev creates the application and packages it into a docker container. Ops deploys the docker container. The Dev team is then laid off as they are no longer needed.

Question: Which of the following techniques are used to scale a system of microservices?

Microservices are divided into frontend and backend services. Frontend is scaled separately from backend.
Microservices are bundled together and then scaled as a group.
Microservices are small and lightweight and therefore don’t need to be scaled.
Each Microservice is scaled independently.

Question: True or False: In a microservice system, each physical (or virtual) machine will host at least one copy of every microservice.

True
False

Question: Which of the following are advantages to a microservice based system?

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

Individual services can be scaled as needed.
Easy cross module refactoring.
Fits well with existing organizational behaviors.
Failures are isolated to a single service.
Increases cross team coordination.

Question: True or False: Microservices approaches often require organizational change to be successful.

True
False

Question: Which of the following are disadvantages to a microservice based system?

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

May require multiple deployment processes.
Increased coupling reduces flexibility.
Cross module refactoring is challenging.
Requires supporting older API versions.
The organization may not be ready (or willing) to change.

Question: True or False: When introducing microservices to your organization, the best way to overcome the shock is to introduce everything at the same time. That way the organization views it as a single change, rather than a bunch of changes, and they will be more likely to adopt it.

True
False

Responsibilities of Microservices Review

Question: The original Single Responsibility Principle, from Robert C. Martin states:

A microservice should have only one reason to change.
A microservice is responsible for it’s own behaviour, not the behaviour of other services.
A microservice should be responsible for it’s own failures, rather than forcing them on the client.
A class should have only one reason to change.

Question: Part of following the Single Responsibility Principle for microservices means:

Your microservice responds to only a single request at a time.
Ensuring that your microservice API maintains backwards compatibility.
Your microservice should be able to operate in isolation.
A change to the internals of your microservice, shouldn’t force a change on other services.

Question: Determining where our microservice boundaries lie is a function of which aspect of Domain Driven Design:

Anti-Corruption Layers (ACLs)
Entities
Value Objects
Bounded Contexts

Question: True or False: A microservice should never be smaller than a Bounded Context.

True
False

Decomposing the Monolith

Question: With this new approach, we are hoping to improve the isolation of our application. Recall that in the monolith, if we made a change to the Orders tables, then we had to edit not just the Orders Model, but also the Delivery Model.

Has this improved with the new structure?

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

If we alter the Orders Database, which portions of the system will need to change?

The Client Application
The Customer Microservice
The Loyalty Microservice
The Order Microservice

Question: In our old monolith, our database was experiencing contention when management was running reports. This contention was resulting in issues in other parts of the application.

Our hope is that the new design will alleviate this problem.

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

If management runs a complicated report on the Orders database, which other parts of the system could potentially be affected?

Client Application
Customer Microservice
Loyalty Microservice
Order Microservice

Question: By isolating our microservices so that they each have their own database, we are hoping that we will be free to evolve those databases without affecting other parts of the system.

In the old system, when we ran a database script on the Customer database, it ended up locking the delivery model as well. Have we improved this in the new system?

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

If we run a script that locks the customer tables, which areas of the system will be affected?

Client Application
Customer Microservice
Loyalty Microservice
Order Microservice

Question: In our monolithic application we were experiencing a lot of contention for disk in our database.

By moving to microservices, we are hoping to alleviate some of that contention. However, there are two possible ways this could be implemented.

– Multiple microservices may share a database instance but have their data isolated within that instance (separate schemas, keyspaces etc).

– Each microservice may have it’s own independent database instance running on independent hardware.

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

If our microservices shared a database instance, would we solve the contention problem?

Contention would be isolated to the Order Microservice.
Contention would still exist across all Microservices.

If our microservices had completely independent databases, would we solve the contention problem?

Contention would be isolated to the Order Microservice.
Contention would still exist across all Microservices.

Question: In order to reduce contention in the monolithic application, the development team introduced a cache layer. This cache layer would reduce the number of reads on the database and therefore improve performance. However, because there were other parts of the monolith that also used caching, this increase in the amount of cached data pushed the system beyond it’s current memory limits.

In our microservices application, we are hoping to have mitigated that issue.

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

Which of the following are valid approaches to alleviate the memory pressure in the microservices design?

Increase the available memory on the machine.
Deploy additional copies of the order service.
Move the orders service to it’s own hardware.
Delete the other caches.

Question: In our monolithic application, in order to display the delivery receipt, the client application would contact the delivery portion of the monolith and the appropriate information would be returned. This included the Customer address, and the Order details. This required one request and one response.

In the new microservices system, we have the additional burden of exposing the customers Loyalty information on top of the other pieces of information that were previously provided.

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

In our microservices system, how many requests are required to display the delivery information?

One request to the Delivery microservice.
Two requests, one to the Order microservice, and one to the Customer microservice.
Three requests, one to the Order microservice, one to the Customer microservice, and one to the Loyalty microservice.
Four requests, one to the Order microservice, one to the Customer microservice, one to the Loyalty microservice, and one to the Delivery microservice.

Principles of Isolation Review

Question: How big should a microservice be?

It should encapsulate a bounded context, no more, no less.
The size of a single function.
It should include a single aggregate root.
Small enough that it can remain properly isolated from other services, but large enough that it can do it’s job.

Question: Improving isolation provides benefits in:

Reduced code size and increased scalability.
Increased consistency and scalability.
Reduced coupling and increased coherency.
Reduced coupling and increased scalability.

Question: The Principles of Isolation include isolation of:

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

Time
Durability
State
Failure
Consistency
Atomicity
Space
Database

Question: Isolation of state means:

Access to a microservice’s data should be wrapped in a Repository.
Updates to a microservice’s state must meet the ACID properties.
Access to another service’s data must go through a database view.
All access to a microservice’s data must go through it’s API.

Question: Isolation of Space provides us with what benefits?

Rapid iteration
Automatic failure recovery
Reduced disk usage
Support for auto-scaling

Question: True or False: Latency should not be a factor in where a microservice is deployed.

True
False

Question: If we send a request, and then block resources while we wait for a response, we are NOT isolated in:

Failure
Space
State
Time

Question: True or False: Strong Consistency (Total Consistency) limits scalability?

True
False

Question: Isolation of Failure means:

A failure in a microservice should only affect services that depend on it.
Microservices should never fail.
Failures should not exceed acceptable time limits (eg. 5 minutes).
A failure in one service should not cause a failure in another.

Monolithic Violations

Question: The monolithic system violates the Principle of Isolation of State.

In what way is the state of this system poorly isolated?

The Delivery portion of the system has direct access to the data for the Orders and the Customers, without going through an exposed API.
It is impossible to separate the deployment of the Order Service and the Customer Service.
The Order model has a direct, synchronous dependency on the Customer data.
Evolving the database for Orders, or Customers, may require an update to Deliveries as well.

Question: The monolithic system violates the Principle of Isolation of Space.

In what way is this system poorly isolated in space?

Client applications must be made aware of the shape of the deployed application (eg. delivery client application knows about controllers for customers, orders, and deliveries, not just deliveries).
Components of the system must be deployed to the same location, regardless of whether they have a dependency on each other or not (eg. Customers and Orders are deployed to the same hardware, but have no direct dependency).
Client applications must be made aware of the location of all instances of the application.
The structure of the application limits the number of copies of the application that we are able to deploy

Question: The monolithic system violates the Principle of Isolation of Time.

In what way is this system poorly isolated in time?

The caching layer pictured in the diagram demonstrates that we are using eventual consistency.
The system is deployed across multiple pieces of hardware and synchronizing the clocks will be difficult.
All calls are synchronous and blocking.
The system seeks strong consistency between different components using the database.

Question: The monolithic system violates the Principle of Isolation of Failure.

In what way is this system poorly isolated in failure?

Retries due to timeouts will put additional load on an already failing system.
Serious failure (eg. out of memory) will bring down an entire instance of the monolith.
Redistribution of load due to failure, could cause cascading failures, and take down the entire system.
A serious database failure will cause the loss of the entire system.

Question: We moved to a microservice system in order to improve Isolation of State.

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

In what way has it improved?

A failure in the customer service will not impact the order service.
We have eliminated the synchronous requests.
We are free to evolve the database representation of each microservice without impacting other services.
Isolation has not improved.

It what way could it still be improved?

We should be able to deploy each service to a separate data center.
Ideally, a failure of the Orders database should not affect the Customers.
Running with only one instance of each microservice is dangerous.
The system is well isolated. No further improvement is necessary.

Question: We moved to a microservice system in order to improve Isolation of Space.

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

In what way has it improved?

Individual services can be deployed to different locations, regardless of whether they have a dependency on each other (eg. Customers and Orders can be deployed to different hardware).
Client applications are now aware of the shape of the deployed application (i.e. which microservices are present). This allows them flexibility to recover from failure.
We can now deploy multiple copies in order to improve resiliency.
Isolation has not improved.

It what way could it still be improved?

Client applications need to be aware of the shape of the deployed application. It would be better if this was not the case.
Client applications should not need to know the location of all instances of the microservices.
We should be able to deploy multiple copies of each application.
The system is well isolated. No further improvement is necessary.

Question: We moved to a microservice system in order to improve Isolation of Time.

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

In what way has it improved?

Leveraging vector clocks in our database allows us to ensure that events are ordered across services.
The move to asynchronous, non-blocking messages gives us isolation of time.
Because we have independent databases, we now guarantee eventual consistency.
Isolation has not improved.

It what way could it still be improved?

Where there is a need for strong consistency, we could have services share a database.
We could leverage a distributed database that uses atomic clocks to guarantee consistency across services.
Using asynchronous, non-blocking messages, and avoiding the use of two phase commit would improve isolation of time.
The system is well isolated. No further improvement is necessary.

Question: We moved to a microservice system in order to improve Isolation of Failure.

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

In what way has it improved?

Serious failures (eg. out of memory, cascading failures, database failures) have been isolated to a single microservice.
Moving to a microservices system means that we can now tolerate additional load created by retries.
Creating individual microservices reduces the memory consumed by each service and guarantees that we will never see an Out of Memory error again.
Isolation has not improved.

It what way could it still be improved?

We need to find a way to prevent any kind of serious failure (such as out of memory).
All of our services should use Cassandra because of it’s availability features.
We need to improve the handling of retries to avoid putting additional load on the system.
The system is well isolated. No further improvement is necessary.

Bulkheading Review

Question: A bulkhead on a ship is used to:

Ensure that the people with the largest cranial capacity are kept safe if the ship is damaged.
Isolate the bulky parts of a ship, such as the engine, to the front of the ship.
Insulate the engine room to prevent a fire from spreading.
Create water-tight compartments that prevent a damaged ship from sinking.

Question: In software, bulkheading is used to:

Partition memory for different areas of the application.
Ensure that a failed call is retried until it succeeds.
Provide a single thread per request.
Isolate failures to a specific area of the system.

Question: True or False: If an application is operating in a degraded state, then it has not been properly bulkheaded.

True
False

Question: True or False: A properly bulkheaded system will prevent scenarios where a failure of one microservice cascades into other services.

True
False

Circuit Breakers Review

Question: True or False: Circuit Breaker is originally a plumbing term.

True
False

Question: Retries are problematic in an overloaded system because:

They are too slow to respond.
The system couldn’t respond to the first attempt, so it won’t respond to the retries either.
Too many concurrent calls could corrupt the system’s data.
They put additional load on the system which may lead to a failure.

Question: True or False: If a call does not include retries, then a circuit breaker is unnecessary.

True
False

Question: Which state is a circuit breaker in during normal operation?

Half Open
Open
Closed
None of the Above

Question: When a circuit breaker is in the Open state, it’s behaviour is:

A single call is attempted. If it succeeds the circuit breaker is closed.
All calls are retried a limited number of times until they succeed.
Calls are throttled at a lower rate and buffered until they can be completed.
All calls are immediately failed without contacting the external service.

Question: A circuit breaker in a Half Open state will:

Allow no requests through.
Allow half of the requests through.
Allow all requests through.
Allow a single request through.

Question: In the Half Open state, if another failure is encountered the circuit breaker will go to which state?

Remain in Half Open
Closed
Open
None of the above

Question: When a circuit breaker is Half Open, if a request is successful it will transition to which state?

Half Open
Half Closed
Open
None of the Above

Question: True or False: Akka and Lagom feature support for circuit breakers.

True
False

Message Driven Architecture Review

Question: A Reactive System is built on a foundation of:

Actors to maximize resource usage
Events published to a message bus
HTTP calls to link services
Asynchronous, non-blocking messages

Question: True or False: In a Reactive, message driven system, services will send messages between each other. It is critical in that case that the receiving service reply back to the sending service immediately so that we can ensure all messages have been received.

True
False

Question: Synchronous, blocking messages reduce productivity by:

Expecting a response when a message is sent.
Tying up a CPU core processing “wait” messages.
Allowing messages to fail silently.
Forcing the system to consume resources, even when it’s not doing anything useful.

Question: When a response to a message is expected to come synchronously, if the receiver is unavailable we must:

Buffer the message and deliver it when the receiver is available.
Continue to retry the message until it succeeds.
Try alternative paths to the receiver.
Fail the sender.

Question: Which of the following benefits do we gain by using Asynchronous, Non-Blocking Messages

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

Responses are guaranteed to be delivered.
Resources can be freed immediately.
Other messages can be processed while we wait for a request to complete.
Consistency of the system increases, eliminating user surprises.
Responses are allowed to take time, resulting in a less brittle system.

Autonomy Review

Question: Autonomy in a Reactive System means:

Services can automatically restart/recover in the event of a problem.
Services depend on each other in a way that is clear and predictable.
Services understand the ways that their dependencies can fail, and will react accordingly.
Services can operate independently from each other.

Question: Which of the following things can a microservice guarantee?

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

The behaviour of their client services.
Their own behaviour through their API.
The behaviour of their dependencies.
The types of failures they will experience.

Question: True or False: Isolation increases dependencies.

True
False

Question: True or False: Fewer dependencies means more autonomy.

True
False

Question: To make a service autonomous we need to ensure:

It responds in a consistent fashion, regardless how much load it is under.
It’s dependencies automatically recover in the event of a failure.
It is replicated to enough places so that we can tolerate a failure.
It has enough information to repair failures or resolve conflicts.

Question: When a dependency exists on data from an external service, we can add autonomy by:

Creating multiple copies of the external service so that we don’t have to worry about it failing.
Retrying calls to the service in the event of failure.
Reading from the service’s database directly if the service is unavailable.
Creating a local copy of the data from that service.

Question: True or False: A fully autonomous system could be scaled indefinitely (assuming enough resources were available).

True
False

Question: True or False: A fully autonomous service can continue to operate, even if it is the only part of the system still running.

True
False

Question: Synchronous Messages

Enable Autonomy by reducing back and forth traffic.
Enable Autonomy by ensuring consistency.
Prevent Autonomy by requiring knowledge of where the receiver is deployed.
Prevent Autonomy by introducing dependencies.

Gateway Services Review

Question: True or False: Microservice based systems are inherently less complex than monolithic systems.

True
False

Question: Monolithic applications typically aggregate data by:

Leveraging a separate component or service that will make all the appropriate calls and aggregate the results.
Making separate API calls to different areas of the application and then aggregating the data in the monolith.
Requiring multiple API calls from the client which will then aggregate the data.
Collecting the data from the database using techniques such as “joins” or “views” where necessary.

Question: In the absence of a gateway service, when data needs to be aggregated from multiple microservices, a client will typically:

Be unable to complete the request.
Request the data from a single microservice. That microservice will make the individual requests, and aggregate the results.
Perform a “join” on the data in the database.
Perform each request in the client, and then aggregate the results.

Question: Increasing the complexity of a client (eg. Android app, iPhone app) is problematic because:

It becomes harder to deprecate old microservices or APIs.
Clients are not guaranteed to ever update.
Updates are controlled by a third party (Google, Apple etc.).
All of the above
None of the above

Question: A gateway service is:

A microservice that is responsible for managing security and ensuring that only authorized users access the system.
A wrapper around an external service to prevent domain concerns from leaking between bounded contexts.
A microservice that knows how to aggregate data from other services in order to fulfill a request.
All of the above
None of the above

Question: True or False: A Gateway Service is always tied to a particular area (eg. bounded context) of the domain.

True
False

Question: True or False: Gateway Services increase isolation in the system.

True
False

Reactive Microservices

Question: True or false: Introducing microservices has given us a form of bulkheading since each microservice can act as a potential failure zone.

True
False

Question: By moving to microservices, we have introduced complexity into the client application. The client application now has to know about the Order, Customer, and Loyalty Services. It has to send requests to each, and aggregate the results. It also has to deal with possible failures in each service.

We could mitigate this by introducing:

A gateway service between the client, and the individual services.
An asynchronous message between the client, and the individual services.
A bulkhead between the client, and the individual services.
A circuit breaker between the client, and the individual services.

Question: Our client application handles timeouts by sending a retry. Even in the absence of retries, if users experience slow response times, they have a tendency to try refreshing a page or application. This results in additional load on an already overloaded application.

We can mitigate this by introducing:

A circuit breaker in the client application.
An fully independent database for each microservice.
Autonomy between the microservices.
An asynchronous message between the client and the microservices.

Question: True or False: A circuit breaker is only valuable between the client and the microservices. It would not be helpful to add one between the microservice and it’s database.

True
False

Question: Having an eventually consistent cache of the delivery data in the driver’s app would be unacceptable because:

Stale data could result in incorrect loyalty information.
Stale data could result in missing, or incorrect order items.
Stale data could result in delivering to the wrong address.
The cache is acceptable. Most changes would not be allowed after the order has left the restaurant.

Question: A delivery driver has arrived at the customers door, and the customer has presented a loyalty card. The driver attempts to enter the loyalty information into the system with their mobile device, but the system is unresponsive.

To mitigate this problem we could:

Record the loyalty information on the driver’s device, and upload it when the system is back online.
Reject the loyalty card.
Wait at the door until the system is back online.
Ask the customer to call in their loyalty information in an hour or two.

Reactive Architecture: Reactive Microservices Course Review:

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

Reactive Architecture: Reactive Microservices course is available on Cognitive Class for free, if you are stuck anywhere between a quiz or a graded assessment quiz, just visit Queslers to get Reactive Architecture: Reactive Microservices Quiz Answers.

Conclusion:

I hope this Reactive Architecture: Reactive Microservices Quiz Answers would be useful for you to learn something new from this Course. If it helped you then don’t forget to bookmark our site for more Quiz Answers.

This course is intended for audiences of all experiences who are interested in learning about new skills in a business context; there are no prerequisite courses.

Keep Learning!

Explore More Solutions on Queslers >>

Leetcode Solution

Hacker Rank Solution

CodeChef Solution

Coursera Assignment Solution

Cognitive Class Answers