
## How does Javascript code execute?
In brief, Javascript is a single-threaded language, meaning it must complete execution of it’s active snippet of code prior to moving on to the next snippet of code.  If that is the case, how is it possible that Javascript is able to delay execution of a snippet until a certain amount of time has passed (using the setTimeout function for example)?

The answer lies in Javascripts intimate connection with the Web API.

Stepping back a bit, what does it mean when we say Javascript is single threaded?  In computer science terms, a thread is the smallest sequence of programmed instructions which can be managed by a scheduler.  In layman’s terms a thread is a task which is given to the scheduler to execute.

Javascript, being single-threaded, means that it will execute tasks (in this instance, snippets of code) in the order the code is provided, reading through line by line until all code has been executed.  If you’re familiar with the concept of a call stack, you can think of every javascript file as a unit on that call stack to be executed.

So what happens when you include a setTimeout function within that executable code?  The answer lies in the intimate relationship between Javascript’s event queue, event loop, and the Browser API.

## Call Stack, Callback Queue, and Event Loop
### A Restaurant Analogy
I’m big into analogies, and this is one of the cleaner ones I can make.  Imagine Javascript is a restaurant with a kitchen, a waiter, and an individual named Frank  eating a large quantity of pancakes.

Each pancake represents a code snippet to execute.
The stack of pancakes delivered on each plate represents the Call Stack.
Frank represents the Javascript Engine executing the code snippets
The kitchen represents the Browser API (sometimes called the Web API)
The waiter communicates with the kitchen and Frank, representing the handoff of Browser API requests and the delivery of “cooked” pancakes, or new code to be executed.

In this world, Frank is particular in how he eats and carries four key traits in his eating habits.
He only eats pancakes
He will eat as many pancakes as he is served
Everytime he finds a blueberry pancake, he sends it back to the kitchen to have the blueberries removed
He will only eat one pancake at a time, pulling it off the top of the stack of pancakes, placing it on a separate dish, and eating it to completion.

Frank shows up to the restaurant and immediately begins consuming pancakes.  On his plate he has three pancakes, he carefully takes the first one off the stack, transfers it to a new plate, finds that it is a plain pancake and consumes it.  Once he finishes eating that pancake, he removes the second pancake, transfers it to a new plate, and finds that it is a blueberry pancake.  Frank is distraught, he calls over the waiter and says, “I get migraines when I eat blueberry pancakes, can you please have them remove the blue berries.”  The waiter dutifully takes the blueberry pancake back to the kitchen and says, “I promise we’ll make this into a plain pancake for you.”

Frank, an ever hungry man, goes to the stack of pancakes on his plate and finds the third and final pancake sitting there drenched in syrup.  He takes the pancake, puts it on a new plate, finds that it is a plain pancake, and consumes it.

He then looks at his plate, and finds no pancakes there.  He then asks the waiter, “was the kitchen able to fix that pancake?  Is there more for me to eat?”

The waiter rushes back to the kitchen and returns carrying a new plate of pancakes for Frank, “The kitchen apologizes for the blueberry mistake, here’s a stack of pancakes on the house.”

Frank looks at the stack, and begins his consumption ritual.  Pulling the top pancake off, checking to see if it has blueberries, eating it if it does not, and returning it to the kitchen if it does.


### Translating the Analogy
This rough analogy explains the general flow of execution and communication between the Javascript engine and the Browser API.  Javascript will execute all code snippets in the order they are received.  In this instance, Frank see’s the blueberry pancake and sends it back, but he continues eating the existing pancakes on his plate.  The Javascript engine performs the exact same process; whenever Javascript recognizes a function which should be executed in by the Browser API (like setTimeout) it will ‘hand off that snippet of code’ to the Browser API and will continue executing the code still on it’s plate (in the call stack).

If it runs out of code to execute in the call stack, Javascript will check the event queue for new code blocks to execute (just as Frank checked with the waiter to see if the pancakes were ready).  In the case of setTimeout, if the time has elapsed on the setTimeout function, the code within that setTimeout will be added to the Event Queue ready to be executed (or the waiter will come back with a plate of pancakes for Frank to eat).  Javascript will then add that code to the call stack and will begin executing it in order.

In this analogy, Frank’s constant communication with the waiter, and the waiter sprinting back and forth from Frank to the kitchen to satiate Frank’s insatiable hunger represents the overall event loop executing at all moments within Javascript.

### Putting it into Practice
When I was doing a bit of research how to teach this concept, I stumbled on the following tool which neatly illustrates this concept.

[Executable Example](http://latentflip.com/loupe/?code=CgoKdmFyIHJlc3VsdCA9IDA7Cgpmb3IoaT0wOyBpPDM7IGkrKykgewogICAgc2V0VGltZW91dCgKICAgICAgICBmdW5jdGlvbigpeyAKICAgICAgICAgICAgcmVzdWx0ICs9IGk7IAogICAgICAgICAgICBjb25zb2xlLmxvZygiVmFyaWFibGUgJ2knIGluc2lkZSBTZXRUaW1lb3V0OiAiLCBpKQogICAgICAgICAgICBjb25zb2xlLmxvZygiVmFyaWFibGUgJ3Jlc3VsdCcgaW4gc2V0VGltZW91dDogIiwgcmVzdWx0KTsKICAgICAgICB9LCAzMDAwKTsKfQoKY29uc29sZS5sb2coIlZhcmlhYmxlICdpJyBvdXRzaWRlIFNldFRpbWVvdXQ6ICIsIGkpCmNvbnNvbGUubG9nKCJWYXJpYWJsZSAncmVzdWx0JyBvdXRzaWRlIG9mIFNldFRpbWVvdXQ6ICIsIHJlc3VsdCk7!!!PGJ1dHRvbj5DbGljayBtZSE8L2J1dHRvbj4%3D
)

If you open up the console in the Chrome Dev Tools, you'll see the order the console.logs are executed.




Analogy: The Javascript engine as understood from a server and consumer of pancakes. A beginners primer on asynchronous behavior wihthin Javascript

Aysnchronous Pancake Delivery in Javascript


## The Analogy

For the purposes of this article, your product manager and tech lead have taken the time to refine; they’ve added every edge case to the acceptance criteria (AC) of each ticket, and the team has agreed on appropriate story points for each ticket to accomplish those ACs.

Now that we have that hypothetical scenario (no matter how unachievable it is to have perfect tickets), how do we take those tickets and plan them out for a sprint? There are some common errors when it comes to sprint planning, and I think they parallel nicely with the errors a kayaker might make.

### TL;DR

If you are one of the few who blindly accept advice without reading the rationale, here’s your section. But the kayak + sprint planning analogy below is fun - so give it a read.

1. Assess the importance of specific tickets included in the sprint
   - Make sure the highly important tickets are distributed across all team members so they can work on them in parallel

   - Pair mission-critical tickets with your most experienced engineers to protect timelines.

   - Assign low-priority tickets to individuals who have less experience in the area

2. Focus on impact rather than achievement
   - Don’t aim to close out your sprints with 100 % completion on all tickets (This is the core concept I outline below)

3. Systematize getting rid of the chaff
   - Evaluate all overflow tickets (tickets which have carried over from the previous sprint) and remove unnecessary AC or execute on them with priority at the start of the next sprint.

### What is sprint planning?

###### (Skip if this is familiar to you)

Sprint planning is a core agile planning ceremony where teams commit to work for the next iteration. The sprint planning is the assignment of tickets to engineers to complete within the sprint window. It is a key component because it offers the product team insights into what might be completed at which time & it allows them to escalate those timelines to their constituents. It also is the key point where agile offers engineers the opportunity to expand their knowledge.

Assigning the same tickets (ie: salesforce tickets always go to Sally) to the same people allows for specialization, but that comes with its own risks.

The completion percentage of these assigned tickets will be used at the end of the sprint to assess the “Sprint Health,” and the story points completed will help the team figure out their relative velocity. These metrics anchor both agile planning forecasts and stakeholder confidence. If your team doesn’t use story points (they can be pretty hotly debated in their value) read my upcoming article on their value & failure points.

### Kayak Style Planning: Ride the Current

There is no better comparison (there may be, but I’m unaware of one at the point in time) than comparing the serenity of kayaking to sprint planning. Back in 2010, I went on this sea-kayaking trip in North Carolina’s Outer Banks. It was my first time kayaking for any long period of time and I didn’t realize how it would help me to understand sprint planning later on in life.

Don’t close out your sprints

Aim for 70–80% completion with your sprint tickets each sprint. When you’re kayaking across a river, you choose a single point on the opposite river bank and you mercilessly aim for it. If you aim directly at it, you’re not going to hit it. You have to take into account the current of the river.

But the river’s current is fluid; it’ll change season by season and even if you nail the current exactly, you still might miss the point because you forgot to take into account the wind.

Let’s say you’re an expert kayaker and you nail both wind and current estimates perfectly; in that situation you may hit the other bank exactly where you’re aiming… but was it worth it to spend the time calculating the exact speed of the wind and the exact change in the current in order to hit a specific point on the other side of the bank?

I doubt it. The same holds true with sprint planning.

With every ticket, you are going to come across situations, edge cases, pieces of the ticket which need to be rewritten, or CSS fluff that doesn’t necessarily lead to a better outcome. Don’t let the idea of hitting all of the AC’s be the overall goal of every individual ticket. If you do, you’re going to over-plan your sprint.

But engineers (myself included) are notoriously terrible at getting their heads out of the weeds when they start driving through acceptance criteria. In a ticket made of 10 small things, doing the next small things isn’t going to make a terrible difference, but a team of team folks doing one small thing that isn’t really necessary to make sure the kayak hits the other bank isn’t a good use of time.

So how do we force engineers to efficiently prioritize? How do we force them to question the value of AC’s and ensure that their goal is to generate the most impact possible in a ticket following the spirit of the ticket, rather than having a goal of completing each and every AC?

Deliberately over-commit so the team normalizes healthy, data-driven misses. Every single sprint, we are going to fail to meet our goal of closing out every ticket. We are going to talk about what we miss, and we are going to see which misses were justified and which need to be carried over into the next sprint. But you should never give them tickets that are expected to be 100% completed. That ensures that you are going to waste time doing things that are not necessarily worth the value.

If we set goals that are not achievable, we are still going to make it to the opposite bank, and then afterwards we can discuss if we can take into account the wind or the current a little more in the next sprint. Not with the goal of reaching 100%, paddling that last 30% is the most exhausting because no matter what you are going to be going against the current at some point. It’s the final-mile problem of delivery trucks manifesting in the sprint planning process.

So over-plan, under-deliver, intentionally.

On that kayaking trip, when we hit the other bank, we didn’t care if we landed at the exact point we aimed - we only cared that we landed in the general area we were hoping. And when we missed our that exact point, we certainly didn’t carry our kayaks up the bank to make sure we camped there.

Priorities change and should be re-evaluated, and the process of planning should change too. When you have 1 acceptance criteria absent out of 7 at the end of a sprint, that single acceptance criteria can now be evaluated against the value of the new tickets that can be prioritized. If you are running a quick and iterative agile process, new tickets can be (and should be) prioritized over that missing AC.

### But can project timelines be calculated?

Velocity. Even with this strategy, your velocity will not adjust negatively.

We have three driving forces that expedite velocity with this approach.

1. If an engineer completes tickets early, they know exactly what to work on next.

2. It fosters healthy conversation during active development about the cost/value of specific AC’s

3. It doesn’t impact impact planning if velocity used.

The key factor that all product managers should use when planning is velocity. How many story points can the team complete on average every sprint? That value would in no way be adjusted if you over-assign a sprint assuming 80% completion.

As long as the PMs use velocity as the key metric, and acknowledge all tickets planned will not be completed (outside of that velocity), planning is in no way negatively impact.

### Conclusion

Hitting an exact point on an opposite bank is a waste of time. Aim at a general area, get there, and evaluate if it’s a good enough spot to set up camp. If it’s not, move a bit, if it is… set up camp and don’t think about it again.


Sprint planning should feel like launching a kayak — calm on the surface, current roaring beneath.

Kayaking Through Sprint Planning


In 2009 Facebook’s rallying cry—“Move fast and break things”—echoed through the halls of every startup. It celebrates speed over caution, which is important in a startup, but does it apply to developed companies that have aging code bases?

For those companies, (and for startups for that matter) the future technical debt of moving fast creates major problems.

We see this in Facebook itself as in 2014 the company walked back the mantra, switching to “Move fast with stable infrastructure.” Not as catchy. Not really the thing that can be shouted on the rooftops of silicon valley justifying poor development in the name of “proving out an idea”. So… was it adopted by venture capital folks? Of course not— investors, to this day, are still quoting the original.

For them, and for the larger companies that want to mimic the environment of startups, I propose a new mantra: “Move fast and break things… deliberately.” Breaking deliberately means deciding what to break—and, just as crucially, what must stay intact.

The analogy I’ll be using in this article will compare tech debt to car maintenance. I was skeptical it would work at first, but I like of like it.

### TL;DR

- Mantra upgrade: Move fast and break deliberately—speed is good, aimlessness is not.

- Tech-debt flavors: deliberate, accidental, bit-rot, documentation, testing, architectural.

- Rule of one: tolerate exactly one debt bucket when moving fast and document the deliberate debt you’re accepting.

- Don’t accept more than one type of technical debt at a time

- Bottom line: plan the mess you’ll clean up later, or the mess will plan your roadmap for you.

### What Is Technical Debt?

(As always skip this section if you’re familiar with the general breakdown of technical debts)

Technical debt is the future cost of today’s shortcuts—refactoring time, bug fixes, lost velocity.

I believe technical debt comes in six flavors, and they’re each handy for a product manager to be familiar with as they are asking their development team to rapidly deploy things.

- Deliberate Debt – chosen shortcuts for speed with a cleanup plan.

- Accidental Debt – low-quality code from inexperience or unclear requirements.

- Bit-Rot (Outdated) Debt – aging frameworks, libraries, or stacks that lag behind standards.

- Documentation Debt – missing or stale docs that slow onboarding and maintenance.

- Testing Debt – sparse automation that raises bug risk and manual effort.

- Architectural Debt – structural compromises that strangle scalability and performance.

### How do these debt types map to cars?

- Deliberate Debt – “I can drive a few thousand more miles before an oil change.”

- Accidental Debt – A buddy promises they can paint your car a new color using oil paint. Occasionally, (hopefully not often) you drive through the wall of a grocery store and start a fire that needs some help from others (fire fighters or SRE’s).

- Bit-Rot Debt – after years on the road, newer cars boast better mileage and features.

- Documentation Debt – not registering your car on time, misplacing service records, or forgetting tire size at purchase time.

- Testing Debt – skipping regular tune-ups and safety checks.

- Architectural Debt – fitting diesel parts in a gas engine: everything goes brrr… broken.

### Which Debt Is Worth Accepting?

Rule of thumb: never incur architectural debt. Architectural debt is a sign of moving too fast and breaking too many things and is likely the key reason Facebook changed it’s mantra to the 2014 mantra of, “Move fast and code with good infrastructure”. Architectural debt can force heavy rewrites and will thwart all future efforts of moving fast in the future. Move fast… but don’t put nos in your engine when you have a 1992 Honda Civic.

Accidental debt happens, and will happen more if you go fast, but it there’s not much we can do about it, so ignore it in the calculus.

Otherwise, choose one other debt bucket to tolerate; guard the rest ruthlessly. This is important. It will feel like you can accept more than one of the debt types while you are coding, but doing so will stymie your ability to move fast in the future.

#### Option 1 – Documentation Debt

Skip docs only if code is future-proofed and well-tested.

Choose this when…

- Your domain logic is stable and unlikely to pivot next quarter.
- You have rock-solid unit/integration tests catching regressions.
- The team is small and tribal knowledge can spread over coffee.
- You can schedule “doc-catch-up day” before the next big hire.

Red flag: Multiple time-zones or imminent onboarding? Don’t trust on tribal memory—write the docs.

#### Option 2 – Bit-Rot Debt

Ship disposable experiments quickly; document them and keep tests green so you can revert safely.

Choose this when…

- You’re A/B-testing UI tweaks or feature toggles with a short half-life.
- Market fit is hazy and learning speed beats code longevity.
- Your rollback plan is tested and one-click.
- The experiment lives behind a feature flag you can yank at will.

Red flag: Core domain or revenue-critical path? Build it to last, otherwise you’ll be moving too fast and will be too highly depended on in order to go back and fix the… choices your team made.

#### Option 3 – Testing Debt

If tests are costly now, invest in rock-solid design and thorough documentation. Buy time today; plan automated coverage for tomorrow.

Choose this when…

- Setting up CI/CD or mocks would delay a funding-critical demo.
- The codebase is modular and manual QA can cover edges for a sprint or two.
- You have veteran engineers who write defensively and log obsessively.
- You’ve budgeted a “testing sprint” on the roadmap (and leadership signed off).

Red flag: Rapid-fire releases or multiple parallel feature branches? Skipping tests will bite—invest early.

### The Gamble of Stacking Debts

So what if you throw caution to the wind and accept two—or (you daredevil) three—debt types at once?

A table for those of you considering this… novel approach.

| Debt Combo        | Car Analogy                                                  | Short-Term Gain                         | Long-Term Pain                                              |
| ----------------- | ------------------------------------------------------------ | --------------------------------------- | ----------------------------------------------------------- |
| Docs + Testing    | Driving cross-country without a map or a safety inspection   | You hit the highway today               | Breakdown in the desert, nobody can even read your warranty |
| Bit-Rot + Testing | Slapping a turbo on a rust bucket, never checking the brakes | Feature spikes look great in demos      | Performance tanks, rollbacks break everything               |
| Docs + Bit-Rot    | Hoarding receipts in the glovebox while the tires bald       | You think you saved time                | New devs onboard slower than your CI build                  |
| Accept All Debt   | Ignoring every warning light and the squealing belt          | Velocity feels god-tier for one release | Release 2 turns into an all-hands fire drill                |
| Architectural     | Swapping the chassis mid-race                                | Maybe you cross the finish line         | Future sprints become gridlock; rewrite looms               |

Your debt stacks multiply. If you accept more than one of these technical debts in a project, cognitive load rises, bugs hide and won’t be found via testing, and every roadmap estimate secretly inflates. Stack too many and your “move fast” turns into drive through a lake and wish you had a boat.

### My Garage is Already Messy

The goal of this isn’t to remove tech debt entirely, but it is to document it and ensure that it falls into the “Deliberate” tech debt scenario. If you are about to touch a section of code that already has say, poor documentation, then as you move through it you will already have to take time to understand it… why not add that documentation as you go? Fix, or iterate, on the major sections of tech debt as you perform spikes for the next section of code where you want to move fast.

You won’t be able to break things deliberately if you don’t know the full scope of the code you’re about to break.

Documenting (from a technical perspective) the deliberate debt you want to incur during the move fast period is key. That way when you hop back in you know exactly where the deficiencies are and you can continue down the path of that single deficiency (if you absolutely have to) or you can perform micro improvements on that dataset as you figure out the next deliberate thing you want to ignore.

It’s important to note that when you move fast, you do make sacrifices. The ideal situation is that you can handle all aspects of these debts as you go, via “boom” and “bust” periods of development. Think of it like the seasons and code quickly in the sprint, and slowly in the winter.

That way your repos engine won’t shut down right as the warranty expires.


Speed is good, aimlessness is not. How to code fast while mind the dashboard lights.

Move Fast and Break Deliberately

### The Analogy
When I think of rendering a webpage I liken it to creating a piece of art.  By happenstance, many of the metrics used to analyze the optimization of various websites happen to fit in nicely with this analogy.  Metrics like, First Paint, First Contentful Paint, First Meaningful Paint - all of those are measuring in various ways the speed at which your site and content load onto the page.

In this analogy, we have two key components: the server, the client, and the DOM.  In this analogy, the DOM represents the canvas of paint, the client represents the painter, and the server represents the commission request for painting.


### Server Side Rendering (SSR)
When the internet was first getting started, just about everything was rendered on the server side.  For the most part, this was done because of limitations around computer speed.  In these early days of computing, shipping large quantities of information over the web was highly taxing; communication, browsers, everything at that time (as you would expect) was significantly less sophisticated and slower than it is today.

In line with the analogy, all paintings requested from the server were prints and occasionally they were paint by numbers.  The server could adjust the painting, but for the most part the painting was already created in templates which are immediately shipped and sent out to the canvas of the DOM for the browser to render.

Some languages, like Pearl and PHP, would create templating libraries where you would inject variables into HTML templates.  The template would then render the final HTML with the variables you are using.

There are two key problem with this:
You have to wait for the server to render the page (fill in those variables)
The greater the burden on the server means you will have a greater challenge to scale and have information update dynamically.

### Client Side Rendering (CSR)
As computers and browsers became faster and more adaptable, there was a shift towards client side rendering.  Frameworks like React and Angular capitalize on this pretty heavily.

In client side rendering, the burden of dynamic rendering can happen on the front end.  Rather than creating a template which the server renders, you make API calls to the backend server which collects specific data and renders them inside your components (I like to think of components as the much more able and modular siblings of those old PHP templates).

This significantly improved the responsiveness of websites, enhancing the overall user experience as they navigate through organisms of modularized components.

In line with the analogy, commission requests were sent to the server and the server responded with a set of instructions (written in Javascript) for the painter to paint upon the DOM.  The painter then executes all of the instructions and dynamically paints the DOM with all of the components necessary to fully construct your website.

The downside to this is on the search engine side.  Search engines will look at your HTML file and derive the content of your side from that html - with client side rendering, you often will have an HTML file with only one div in in - entrusting the browser to dynamically inject the content off of that single div.  Search engines have been improving on this front - which we will discuss in another article.



### The Value of Next.JS
Next.js is an isomorphic combination of each of these rendering methods.  Next will enable engineers to partition out their sites so they can have all three rendering methods.  This allows engineers to optimize their websites for speed, responsiveness, and search engine querying without a tremendous deal of effort.

Using Next, an engineer can render static components which are optimal for search engine optimization, parts which are dynamic are server side rendered, and that everything else on the page is client side rendered.  Capturing the key value adds of each rendering method, while minimizing their potential downsides.

In this instance, we have a nice hybridized workflow between the commission requests, the painter, and the canvas.  Those aspects of the canvas which require quick viewing and which need to be read by machines (like search engines) will be sent directly from the server.  Meanwhile, those aspects of the canvas which are a bit more dynamic will be painted on the fly by the Javascript code executing.


Analogy:  Painting and its relation to  various server side and client side rendering advantages

Paint by Render

Product Article 3

## Overview
When thinking about system design and requests being submit and received by your server, I like to draw a parallel with car manufacturing.  I’ve heard analogies using a restaurant with various lines chefs used nicely, but I’ll save that analogy for discussion on the value of microservices within backend design.

## Background
A bit of background is required for those not familiar with Computer Science in how data is transferred between systems before I can fully dive into this analogy. In engineering, we use the term “traffic” or more formally, “Network Traffic”.  Again, I find myself in a situation where the analytics used to describe the efficacy of your network tie in nicely with the analogy I’ve chosen.  Network traffic represents the amount of data moving across a computer network at any given time.  What does that mean?

Anytime you go to a website, data is being transferred between a sending device and a receiving device.  In most cases, the sending device will be the server serving up the resources to power the site and the receiving device will be the browser which is assembling and executing the data from that server.  There are other steps including communication with a Domain Name System (DNS) a Content Delivery Network (CDN) and a handful of other things which enable and speed up the efficiency of receiving the data, but for the purposes of this article, we are focusing on the communication between the server and the browser.

### Now, how exactly is that data transferred?
It’s reasonable to assume that all data in a single burst.  The browser says, “Hey, I need an HTML file to paint on this DOM” and the Server says, “Here’s your HTML file.”  For small data items, this is indeed how it works.  But what happens when you have a larger sum of data to transmit?

It’s much more efficient and robust to break up large data transactions into smaller packets and submit each of those smaller packets across the internet.  Why?  Because what if the receiver is not ready to receive the information - what if there is an error and communication somehow stalls or is broken during receipt?

Breaking this data into smaller packets enables a recipient to acknowledge they are receiving data, and gives the recipient a clue on how many data packets they are going to receive.  They can then let the sender know when a packages was successfully received, and (more importantly) can let the sender know when an error occurred and a package needs to be resent.

The requester can then combine each received package into the larger data file as each successful package is received.

## The Analogy
With that background, let’s think of each of these packages as cars which the server builds and then sends out along on a single lane road.  Between the browser and the server, that’s largely exactly what is occurring.  The browser will request packages that it needs, and the server will compose those packages to be sent along the treacherous road that is an HTTP request.

If we imagine a single user on a website requesting that information from the server, the process is simple - but what if we imagine a million users all hitting the same site at the same time?  That’s a lot of cars, a lot of packages, which the server has to build and send out to a lot of different browsers all at once.  So, how does the server handle that?

## Scaling
There are two options to discuss.  First, you can make a bigger car factory.  If pay to decrease the time that it takes to build those cars by building a super car manufacturing facility, you can quickly process requests and get those cars (or packages) out to every browser that is requesting them.  Second, you can duplicate your existing car manufacturing facility and distribute the load of creating those cars across each facility.

These two options are called Vertical and Horizontal scaling methods respectively.  With vertical scaling you pay to have a computer with greater processing speeds - something that can really quickly turn out those packages and send them along the road of the internet.  With horizontal scaling, you duplicate your existing manufacturing facility a hundred times over (something which is significantly cheaper to do when discussing software rather than actual manufacturing facilities) and you distribute the load of creating those packages across many different computers with smaller computing power.

With tools like Docker and the advent of virtual machines (think of each machine as its own manufacturing facility) the ability to duplicate existing environments and horizontally scale is often a cheap and reliable solution to scale lots of network traffic all at once.  But what do those data highways look like?

### Intro to System Design with Horizontal Scaling
Moving away from the single lane road of an HTTP request, and diving deeper into the package construction when horizontally scaling - let’s imagine that a Server is a massive city with thousands of requests being made for new cars every millisecond, and thousands of new cars being made every moment.

What’s the first thing you anticipate you might need is… directions to each of the manufacturing plants.  A hundred requests for cars come in at roughly the same time - you have 50 manufacturing plants ready to make the cars and send deliver them - step one.  How do you ensure you use all of your manufacturing plants efficiently?

### Load Balancing
You don’t want to send all of these requests to the same manufacturing facility, as it can’t create two cars at once and it will have to add new requests to the queue.  The answer lies in the term “Load Balancing”.  A load balancer’s key goal is to receive all of these requests for data and redirect the request to a virtual computer which is currently not making a data package.

Popular load balancers like Nginx, Azure Load Balancer, and AWS Load Balancing and each of those can distribute the load to a manufactucturing facility that is not currently in service.

Now we’ve solved the problem of getting requests to the right manufacturing facility - but we have a new problem.  Right now (and I haven’t mentioned this) every car manufacturing facility needs to request the blueprint from the Auto Designer on how to make the car every single time a request is made.

As you can image that might create a potential bottleneck on the Automobile Designer or (in this analogy) the database.  So how can we circumvent the need to request the blueprint every single time?

What if we stored the blueprint at the manufacturer?  If we had a blueprint of the most commonly selected cars, we could limit the number of calls heading out to our Automobile Designer and we could limit the impact of that bottleneck.

### Caching
The general concept of storing commonly requested data in a layer away from the database is called caching your data.  Caching occurs to optimize fetches across the entirely of the web, whether that is in commonly requested IP addresses, images when you visit the same website multiple times, or (in this case) commonly requested data items feeding back to a browser.

There’s a limit (or there should be) to the number of blueprints you want to store in a cache.  I say there should be, because maintaining full duplications of the database would be highly resource intensive and there is a tradeoff between the number of blueprints stored and the efficiency gains of a cache.

So, how do we decide what to and what not to include in a cache?
If you again take the scenario where you have 100 blueprints for different cars (or data packages), your goal is to find the data that will reduce the requests on your Auto Designer database the most.

One manner of doing this is to store the data that was requested soonest. Say you have a cache with the ability to only store three blueprints and requests come in, in the following order.

Camry
F-150
Camry
Model S
Model S
F-150
Camry
SmartCar

Visually, you can tell storing in a cache the data for a Camry and an F-150 would reduce the blueprint requests to the Designer fairly substantially.   If you requested the data that was last fetched, the blueprints stored in your cache would be:
SmartCar
Camry
F-150

There is a greater likelihood that the cars most commonly requested will ensure their presence in your cache, because… they are most commonly requested.

But, what is that SmartCar doing in there?  Is it doing any good?
The short answer is, it might be.  In situations where you have more varietal fetching and where you aren’t able to always predict the most common fetches, doing a time based caching store will capture those trends.

The perfect example of this might be someone searching umbrellas on a rainy day.  Searches for umbrellas go up as people realize they need an umbrella.  While it may not be the most common request after a sunny week, storing the last requested data in the cache would ensure that after the first request for an umbrella, every individual who realizes they need an umbrella that rainy day will have a better, more timely fetch experience.

The other common way to create a cache is to find the most commonly requested data.  In some situations, you know the data that is going to be most commonly fetched (you know, for example, that your logo is going to be loaded every time the page loads).  In the above fetches, your cached data would be blueprints for:
Camry
F-150
Model S

This method ensures that necessary data is always going to be present and will not require a request to the database in order to construct the data package.

There are a handful of other optimizations with caching which will be covered in future articles - but one related topic is the extreme optimizations you can make with static resources which you know will always be fetched every time a page loads (think of that logo again).

### Content Delivery Networks (CDN’s) as Car Warehouses
As you can imagine, no matter how quickly you churn out those cars - the further they have to travel on the internet to the end browser, the longer it will take to receive the data.  In the US, most highways have a maximum speed limit of 80 mph, imagine the same is true with sending and receiving data across the internet.  There’s a (relatively) static time speed of transmission and the further they have to travel, the longer it will take for the browser to receive each package sent by the server.  If you open up a website in rural Estonia, if the server your Browser is receiving information from is located all the way in North East Canada, you can expect that website to load substantially slower than if you open up the same site from North East Canada.

The birth of CDN’s came when a savvy group of engineers realized that it is possible to improve the delivery time of those cars by pre-making them and storing them at locations closer to their common requestors.   Companies use CDN’s like Cloudflare, Sucuri, Amazon CloudFront to pre-load their large data packages and store them at locations that are geographically closer to their end users.

This means that the not only is the distance the data has to travel along that road substantially shorter but also that the data packages are less liable to be accosted by pirates (you’re less likely to have errors on receipt).  You increase efficacy and reduce transmission time.

CDN’s can therefore be thought of as data warehouses spread across the globe to improve data transmission.

Analogy: Managing automobile manufacturing relative to basic system design principles

Writing on engineering, product, and how good decisions get made.

Aysnchronous Pancake Delivery in Javascript

Kayaking Through Sprint Planning

Move Fast and Break Deliberately

Paint by Render

System Design and Cars