Reading and drawing architecture diagrams

In the design step of the round (lesson 2), you draw. The interviewer often points at one box and asks: "What happens here?"

A weak drawing has boxes named "Frontend" and "Backend" and no numbers. A strong drawing is small. Each box has one job, and numbers show the load. In our guide, SDE-1 needs a correct drawing. SDE-2 and SDE-3 also need numbers that match the requirements.

Think about a road map. It shows which roads join which places, and how many vehicles each road carries. You read it to find the busiest road.

An architecture diagram is a drawing of the parts of a system and the calls between them. It needs two shapes.

• A box is one part: the client, the servers, or the database (lesson 1). One box has one job. If you cannot say the job in one short sentence, split it.
• An arrow is one call. It points from the part that asks to the part that answers. The answer comes back on the same arrow, so you do not draw it again. Some people point arrows the way data moves. Either is fine if you say your rule.

A label is the short text on a box or an arrow. It carries the numbers from lesson 2, with units.

• On an arrow: what is sent and the load, which is how many requests arrive each second. For example: "getResult, 667 requests per second".
• On a box: its name and its capacity, the most it can do each second. For example: "Server x 3, each 500 requests per second".

To read a diagram:

1. Follow one request along the arrows. This is the data flow from lesson 2. Number the arrows in order.
2. Divide the load going into a box by its capacity. This shows how full it is. Above 100% means it is too small.
3. Find the box that fills first. Use it for a deep dive.
4. Ask about each box: "If it breaks, does the system stop?" If there is only one of it, it does.

To draw a diagram: start with the smallest design that meets the requirements. Add a box only when a number needs it. Use 5 to 8 boxes. Put the client on the left.

We draw the results website of lesson 2. Assumptions (made up to teach with): 667 requests per second at the busiest time. One server answers 500 requests per second. The database answers 2,000 lookups per second. Each request makes one lookup.

Boxes: Phone, Servers x 3 (each 500 requests per second), Database (2,000 lookups per second).

Reading it.

1. One server: 667 / 500 = 1.33, so the load is 133% of capacity. This answers the predict box: it is too small by 667 - 500 = 167 requests per second.
2. Three servers, with the requests shared equally: 667 / 3 = 222 each, and 222 / 500 = 44% full.
3. Database: 667 / 2,000 = 33% full.
4. Room to grow: the servers hold 1,500 / 667 = 2.25 times today. The database holds 2,000 / 667 = 3 times today. The servers fill first.
5. If one server breaks, 667 / 2 = 333 each, 67% full. The site works. If the database breaks, the site stops.

• Labels solve a drawing that nobody can check. They cost drawing time, and you must defend every number. I would label only the busiest arrow when time is short.
• A small drawing solves confusion. It costs detail. I would add a box when a number needs it.

"More boxes show that I know more." Extra boxes hide the idea. The interviewer scores choices that fit.

"An arrow always shows where the data moves." Here it shows who asks. Arrow 2 points to the database, but the marks come back on the same arrow. Say which rule you use.

"I can keep the numbers in my head." The interviewer cannot see them. Without numbers, nobody can tell if three servers are enough.

1. What does a box mean? What does an arrow mean, and which way does it point?
2. An arrow into the servers says "900 requests per second". One server answers 500. Each request makes 2 lookups. The database answers 2,000 lookups. (a) With 2 servers, how full is each? (b) How many servers do you need, so that the site works when one breaks? (c) How full is the database?
3. A drawing has 12 boxes named "Service A" to "Service L", no numbers, and an arrow from the database to the phone. Name three problems.