chapter Name:- Why Reactive?
Question 1. What is a software landscape problem that reactive architecture is addressing?
- Modern systems need a way to provide asynchronous streams of data with non-blocking backpressure.
- The scale of modern systems far exceeds that of legacy systems, consisting of hundreds or even thousands of nodes.
- Programming languages used to be more fundamental (C for instance) and required developers to spend long hours focused on writing long complex code. Today programming languages are abstract and declarative. Developers can write code easier and thus react to new reqs more nimbly.
Question 2. What do we mean by “data at rest”?
- The data is exposed through a REST api to be consumed be external services.
- The data is not consumed at the time it is injested. It is stored, and then consumed later in a batch process.
- The data is no longer needed for any analysis or access. Another name for this is “archived data”.
- It means that the data is not accessible all the time. Processes that need access to that data may have to schedule access.
Question 3.What do we mean by streaming data?
- Streaming data can be in two file formats: “rstone” or “driftw.”
- A firehose of data. Data can flow through the system at any time with no upper bound on the amount of data.
- Like water, it can flow through a system through predefined paths, but it can also “spill” unpredictably into other parts of the system.
- It always represents an audio or video stream and deals with topics such as buffering, bitrates etc.
Question 4.Users of modern web based software expect:
- That the software will be available when they need it. There is no downtime.
- To save their work frequently and locally because the system crashes a lot.
- All software is free except that they need to click on an ad at least once an hour.
- To have their personal data not tracked and discarded.
Question 5. True or False: Reactive Architecture is all about trying to solve technical problems (Eg. how to scale). It does not concern itself with how those solutions impact the end users.
Case Study: History of the Reactive BBQ
Question 1.This is a company that has had to deal with a change in user expectations?
Question 2.This company has not had to deal with changes to the technical landscape over the years.
Question 3. Can you tell us a bit about the system you are currently using?
- Sure. Our system started out fairly simple. Several years ago, as our business was growing, and we were expanding from a small chain in Texas, to a larger national chain, we introduced some software to help us manage inventory across all our restaurants.
- As our business grew, we realized that we wanted to centralize more than just inventory management. We added functionality to share menus, orders and eventually reservations. The system grew like that organically. Often one thing needed the other to operate. Orders need information from the menu. The menu relates to the supplies we order in inventory. That sort of thing. So we just put everything in the same place to make it easier to manage that stuff.
- Based on the description from the CEO do you think this system is based on a monolithic style (single deployed application covering all areas of the business), or microservices (independent applications for each area of the business)?
Question 4. Which of the following portions of the business are controlled by the central software.
- Customer Loyalty
- Inventory Management
Question 5. Can you tell us about your online presence?
- Online is definitely important, but it’s not the bulk of our business. We started out as a dine-in restaurant chain, and that is still the case today. But we do have a few menu items that are popular delivery options.
- Our Reactive Ribs and Wings are huge any time there is a major sporting event. People get together for their Super Bowl parties, or their World Series parties and they need munchies. So we see a pretty big uptick in our online orders around those events.
- It used to be that people called in for those orders. They would phone us up and order that way. Now though, we don’t see that as often. People seem to prefer to use our website. I guess because they can pay right there and not have to worry about giving cash or a credit card at the door. It’s easier for them that way.
- Of course, once we had the ability to place orders online, people started wanting to make reservations online as well. So naturally we had to add that in. I think people still tend to phone for reservations, but we do get a small amount of online traffic.
Question 6. Which of the following system components does the online customer interact with directly?
- Inventory Management
Case Study: The Unresponsive BBQ
Question 1.Which of the following problems is the host experiencing?
- The system is inconsistent, sometimes saying there is no reservation, when the Customer says there is.
- The system has incorrect information about a reservation (such as the wrong time, or location)
- The system is slow causing wait times for both the Host and the Customer.
- The system is crashing so the host can’t locate a Reservation.
Question 2.The host is experiencing delays, and crashes, in the system. These appear to occur:
- When the restaurant is busy.
- On certain days of the year (eg. Mother’s Day).
- When the restaurant is slow.
- Randomly. There is no observable pattern.
Question 3. What challenges do you you face with the current system?
- During peak times things can get a little hectic. Entering orders seems to take longer when we get busy. We have a limited number of computer terminals to enter the information into, so as things slow down the other servers start to line up to enter their orders. We have asked for more terminals, but apparently they are really expensive so they won’t give us more.
- It’s also tricky to keep track of the different parts of the order, when they are ready, where they need to go, that sort of thing. The kitchen makes the food, but the bar makes the drinks. When things get busy, we don’t always see right away when things are ready. Then the food gets cold, or the drinks get warm, and the customers get frustrated while they wait. We are basically just relying on people to tell us when things are ready, so if we aren’t nearby it can take time.
Question 4.Which of the following problems is the server experiencing?
- The system is losing orders so they don’t get picked up by the kitchen.
- The kitchen is getting incorrect order information, resulting in mistakes.
- Items on the menu are incorrect, creating confusion with the customers.
- The servers are not notified when an order is ready to be served.
- The system can be slow causing servers to line up.
Question 5. When problems occur, the servers sometimes try to work around the system by talking directly to the kitchen. This shows that the servers are:
- Frustrated by a system that doesn’t meet the requirements of their job.
- Confused about how to use the system effectively.
- Probably better off not using the system.
Question 6. What challenges have you faced with the Reactive BBQ website or app?
- Once in a while I have tried to order online, and the website has been down, or just really slow. Sometimes I wait a bit and try again, like if I am still at work and I just want to pick something up on the way home. In that case I might wait. But sometimes I am in a hurry, or just really hungry. In those cases I don’t bother waiting. There is another BBQ place on my way home. It’s a little more out of the way, and the food isn’t as good, but it will do in a pinch. So I just go there if I can’t order from Reactive BBQ.
- I don’t do online reservations anymore. Last time I tried, they lost my reservation. Apparently the system was “down for maintenance”. They still managed to get me a table, but I had to wait about ten minutes. I mean, what’s the point of a reservation if it doesn’t actually guarantee you a table?
Question 7. Which of the following problems is the customer experiencing?
- They are unable to pay for orders because the payment system is down.
- They are being charged an incorrect amount for an order.
- They are struggling to create orders because the website is too slow.
- They are unable to create orders because the website is unavailable.
- Their Reservations can’t be retrieved because the system is unavailable.
Question 8. When the customer experiences a problem with the online ordering system they will do the following:
- Call the restaurant instead.
- Visit the restaurant in person.
- Cook dinner at home.
- Order from a competitor.
- Wait for the system to come back online.
Reactive Architecture: Introduction to Reactive Systems final exam Answers:-
Question 1. Starting out, we expect a small user base of about 25 concurrent users. However, we expect our user base to grow significantly in the first year. True or False: In the beginning, we don’t need to design a system for our future user base.
Question 2. Our business has a typical load of 500 concurrent users throughout the year. However during the year end retail season this number spikes up dramatically, as high as 5000 concurrent users. Our goal is to:
- Allow the system to fail if it can’t handle the load.
- Build the system so we can deploy additional hardware for the peak season, and then release or repurpose that hardware after the peak is over.
- Worry about it when the next peak comes.
- Deploy enough hardware to handle peak load at all times of the year. Outside of the peak periods, that hardware will be idle or only partially utilized.
Question 3. Given user reliance and expectations of modern web based software what is a good objective when it comes to system failures?
- We will design a system that is bulletproof. We will cover all the failure cases and ensure that they can’t happen. The system will be built so that no failures ever occur.
- Failure in systems is inevitable. Our goal should be to design systems that handle those failures gracefully. We accept that failure is a fact of life, and we build a system that will lessen the impact of those failures on the users. The system should continue to provide some functionality despite failures.
- Failure in systems is inevitable. It may not be good for users, or the business, but it will happen no matter what we do to stop it. We should accept that failure is a fact of life and just deal with it when it happens.
- Do or do not. There is no try.
Question 4. It is unreasonable to assume that a system should be able to scale to hundreds or thousands of nodes.
Question 5. Designing my system to run across tens, hundreds or even thousands of machines can help minimize the impact of failures on my users.
Question 6. I need to sacrifice either system scalability or responsiveness to users in my software system. I can’t have both as goals.