“Your database, backend and the user are all beads on a string.”

Dax (thdxr)1

Basically:

But normally you’ll be hosting your backend very closely to your database, making this other piece of art a bit more accurate:

A more real case

Loading a typical web page requires different pieces of information — for example, you may be loading the logged-in user’s profile on the corner, the main content in the center, and other little details around the page. In a typical REST API design, this will often translate to several separate requests, looking like:

One of the main benefits of GraphQL is that easily enables the client to make a single request specifying all those pieces of data, and the backend stitches them together. The browser would make a single request asking for the user’s profile, the main content, and the rest — and the result looks way better:

Subscribe now

Which brings some simplicity to the client and potentially reduces load time, improving your users’ experience.

We can do the same thing anyway

While it’s true that, in the RESTful case, you can make those requests asynchronously, you would on the other hand add significant complexity to the client. That means dealing with independent request failures and all the dependencies between these separate calls.

You could also define a single REST endpoint that contains all the information to load the page and mimic the GraphQL behavior. But this would just shift the burden of dealing with complexity from the client to the backend. And while that may be viable for simple applications, it would not be in more complex ones.

In contrast, GraphQL’s design fits like a glove for this case. There is no need to design solutions to reduce latency, as it was designed specifically to address such cases.

If you’re curious, why not just try it?

This is just one of the many reasons I appreciate GraphQL. Some other advantages are the very, very easy use of GraphQL subscriptions, and how it makes the API contract between frontend and backend explicitly define (some people don’t like this one though, but I’m a huge fan).

Admittedly, GraphQL is quite different and feels weird at first. It may not seem worth spending the effort to “relearn” a new way to do core things. But one day I decided to just try it with Apollo and was surprised and how easy it was. So, if you ever feel a bit curious, just give it a shot.

Share

Subscribe now

However, that price can sneak up in other ways. I was recently in the market for a new bicycle. Like a normal person, I had my requirements and budget, and found myself in the lucky (or unlucky?) spot of having numerous candidates. Searching for the perfect match was taking me days — when I realized it could spiral into weeks and months. I immediately went to the store next to me, tested one that was comfortable, and completed my decision. Is it perfect? Who cares.

Subscribe now

SYSTEM 1 AND SYSTEM 2

Our brain has two systems of thinking, named by Daniel Kahneman and Amos Tversky as “System 1” and “System 2”. (Their creativity for naming system is as good as mine for naming variables. Or characters in The Sims.)

System 1 is the fast, automatic thinking. System 2 is the calm, rational type. 1 quickly answers easier queries, and occasionally gets them wrong. 2 takes its time with complex ones, wanting to be correct. Our muscle memory versus our deep focus.

System 1 is to blame for all our biases. If you ever caught yourself making an assumption or decision you never thought you would, you should blame your System 1. System 2 is less likely to do such a thing because it takes its steps consciously. As such, System 1 gets a bad rap. In Thinking, Fast and Slow, Kahneman goes through a long list of biases caused by System 1 and how to mitigate them. (As a rough summary: the solutions are not quite on improving System 1, but rather on noticing your biases, and using System 2 to consciously make the better judgement.)

There’s some nuance to it, however. In the very same book, Kahneman explains System 1 is the reason we’re alive at all. If there might be a tiger creeping on you for dinner, you don’t carefully look at the predator to assess danger — you run. Once your eyes sensor the animal, System 1 immediately makes the decision: “TIGER!!! RUN!!!!!!!!!!!!.” You’ll be perfectly fine if you ran away while there was no tiger. Being wrong in the other way, however, would be a life-ending mistake.

Hence, even with its flaws, we can thank System 1 for making critical decision fast. It is undoubtedly the hero that saves you from being run over when you’re crossing the street and a car runs a red light. But that doesn’t mean you want it making your investment decisions — you hit up your System 2 for that.

TCP AND UDP

TCP is the perfect communication protocol between two computers. Its ritualistic three-way handshake, sequence numbers, and congestion control ensure every message gets delivered, and they get delivered in the order they should. It is the System 2 of way of communicating. UDP is the more free-spirited version. Packets are sent and no time is wasted with guaranteeing they are delivered.

There’d be no email without TCP — messages needs to be perfect. And there’d be no Netflix without UDP — streaming needs to be fast.

Real-life applications are a bit more nuanced, because the choice is not binary between those two. An engineering team can decide to build their own. And in fact, it is typical to for companies to add logic on top of UDP in order to have some guarantees (Netflix might be fine with you fractions of a second of your show, but certainly not minutes of it).

You design your own protocol because you can’t have perfection and speed. But you can give up some of the former to get more of the latter. When faced with the limited resource (the acceptable latency), you realize many guarantees don’t matter that much. So you let go of them — and your service becomes fast and good enough.

TRADE-OFFS, OBVIOUSLY

Evolution led our brains to develop these two decision-making systems. The two imperative communication protocols also represent a similar duality of perfection versus speed. And it seems like a counter-flow to not at least try to mimic that in other situations.

As with all other things, there’s no black and white answer and we need to look at the trade-offs of each situation. But I wouldn’t have spent the time writing this just to state the obvious. My point is even though we may know that, we often forget we know it and overcomplicate things for no reason. Especially in mundane situations — completely apart from tigers.

We shouldn’t agonize over which phone to buy or where to have dinner — being wrong about that hardly matters. For such decisions, just pick something good enough and move ahead. And when trying to decide something seemingly important at work, just ask yourself what’s the worst that could happen if you pick an “incorrect” option. Getting things done and moving to the next step is worth ten times more than doing the current decision “optimally.” (And remember that always relies on the strong assumption that you even know what it truly is the “optimal.”)

More importantly, we shouldn’t agonize trying to perfectly satisfy requirements to handle every worst case. Doing so will probably be a regretful decision 99% of the time. You may be stoked on the other 1% of cases, but how much of a premium are you paying for those?

WHY I AM NOT BUYING A CAR

I live in San Francisco, a city roughly shaped like a 7 miles by 7 miles square. It’s compact.

A 20-minute walk radius from home takes me where I usually need to be. My office, grocery stores, most of my friends, park, and some shops and restaurants. Excluding the time I’m at home, I spend about 80% of my time within that 20-minute walk radius. A 20-minute bike radius takes me everywhere I usually want to be. My favourite restaurant and shops, plenty of parks, and even more friends. 98% of my time away from home is spent within that bike radius.

And I’ve thought about buying a car, because that’s the natural thing to do. Buying a car would get me everywhere I need to be, without dealing with Lyfts or transit schedules. It is the perfect solution for my target of reaching places faster (being generous to cars in the latter).

But cars are also the shittiest perfect solution. Moreso in SF. They are ridiculously expensive to acquire, maintain, and to park (both in dollars and, more importantly, time spend to find parking). To put these metrics into perspective:

• a fantastic e-bike that truly suits most of your needs will cost considerably less than the annual prices of maintaining a car. Even if you get the car for free!

• parking often takes 10+ minutes to find in SF, and that time can grow like Bitcoin in 2021. If you’re driving into a busy area, you’re likely to spend the same amount of time parking than it’d take to bike.

If 98% of my time away from home is in a 20-minute bike radius, the chance of me wanting a car would be at most 2%.1 And for those 2% of cases that cars the only option, solutions come naturally: Do I need to get somewhere while tired at night? Uber; road trip to Yosemite? Lyft rentals; wind in my hair while flooring a fast car in an empty highway? Turo and beg someone.

In one of those rare days, the cost of owning a car would, in that specific day, be less than the cost of dealing with the problem — Uber’s surge prices at night can be steep.2 But, those occasions are so infrequent. And on the long run, the not buying a car comes out much, much cheaper.

Solving for the 98% and improvising the 2% is much faster and cheaper than tackling all 100% at once.

Share

Subscribe now

The writing in Succession is superb. Not just because it’s uniquely hilarious, and emotional when it needs to be, but also because every character arc just… makes sense. All the moves seem to follow logical trajectories set up episodes before. One main move that starts at the end of season 1 and goes throughout season 2 is Stewy and Sandy’s bear hug on Waystar Royco. Now, buckle up and beware of season 1 and 2 spoilers, as we explain a bit more deeply one of the major arcs in the show.

Subscribe now

What is a Bear Hug?

Stewy and Sandy planned an acquisition of Waystar Royco without Logan and the board’s consent. They are planning to acquire a company that doesn’t want to be taken over, making this a hostile takeover. A bear hug is just one way to do that. With this simple, four-step recipe, you can also bear hug any company you want. (You might need a few billion dollars, though.)

Step one: Set a purchase value

The bear hug is one of the “nicest” forms of hostile takeovers because it requires the takers to pay more than the stock is worth. Usually, significantly more to make it a tempting offer. In the show, the most they reveal is that the stock price of Waystar Royco dipped below $130, and the price Kendall mentions in the bear hug is of $140, or about 8% higher than its fair price.

What is also interesting is that, if traders were to hear of the secret plan, they’d go ahead and buy Waystar shares, hoping for a profit, and increase its price all the way up to $140. (At least in theory, which often differs from reality.) This would either make the offer less impressive, because the 8% premium would no longer be there, or require the baddies to find more money. That’s why when Stewy hears of possible leaks because Kendall spilled the beans in the wedding, he pressures him to execute the plan right away, rather than waiting a few days.

Step two: Make an offer to the board

This is the dramatic moment in which Kendall makes the offer to his father and foolishly tries to pitch how it is better for investors. The board has a fiduciary duty with the shareholders of the company, meaning they have the legal (and ethical, if anyone cares) obligation to do what is best for them. It’s hard to argue against an offer that is 8% above the stock price of a company that is going downhill.

Unsurprisingly, Logan says no.

Step three: Make the offer public

As we know, Kendall abandons the plan because of… uhh… personal reasons. Nonetheless, Logan’s refusal doesn’t shock Stewy and Sandy, who decide to make the offer public. If the board won’t budge, the shareholders — the ones who actually get to elect the board — can pressure them.

This is pretty standard in bear hugs. When Microsoft attempted to bear hug Yahoo, they made their offer public less than 24 hours later. Clearly, the offer wasn’t quite for the board, but for the people.

Step four: ????

At this point, anything could happen.

Maybe the board yields. Maybe the shareholders put the needed pressure and vote for the acquisition. Maybe management gets to put a good enough fight to survive the attempt. In Succession, as of the end of season 2, we don’t know what happens yet. The Roys have been resisting and stalling, but we don’t know how much longer they can stand.

If the company’s management really doesn’t want to be taken over, as the Roys don’t, they can come up with plans to resist the takeover. One famous one used by Netflix and hinted is the show is called “swallowing the poison pill.”

The Poison Pill

They don’t get into detail about this on the show, only mentioning it passing, and I don’t think it will become a major plot point. I’d love to be wrong. Nonetheless, when Netflix was suffering a bear hug in 2012, it employed this tactic as a defense.

The official name for Netflix’s poison pill was the “shareholder rights plan,” which is a cute euphemism. However, calling it a poison pill is reasonable because it could potentially damage the company’s shares just for the sake of avoiding acquisition. It might not be the best idea, but it can definitely be effective.

TLDR: Issuing new shares

For the takeover to succeed, the acquirer must buy more than 50% of the company’s shares. If the company adds more shares to the market, then reaching that percentage becomes more difficult. However, who gets to buy the new shares?

For the company to resist acquisition, they’d want anyone except the acquirer to buy those shares. Luckily for them, they can enforce that. Usually, the rule also restricts the new shares only to existing shareholders. In order to make that purchase attractive, the new shares are issued at a discount, say, 10% cheaper than the current market rate. The new shares dilute the value of the old shares, hurting literally all the other investors in the company — making it a tough poison pill to swallow.

And should those shares be issued? That also depends. In Netflix’s case, they set their shareholder rights plan to automatically issue new shares the second Carl Icahn (the attempted acquirer) held a single share past his existing 10% stake at the company.

After the Survival

The poison pill doesn’t even need to be executed, it just needs to become a real enough threat to make the acquirer give up. And indeed, Carl Icahn gave up on Netflix, which proved to be great for the company. Similarly, Yahoo managed to put a good enough fight to make Microsoft give up on its $45B offer on the company, which successfully lived its downhill trajectory and was sold years later for $4.5B.

In Succession, Logan mentions that Waystar Royco could end up like Kodak, almost worthless. The $140 price was a good offer, and the family would walk away with a lot. So would the shareholders, of course, but they don’t care.

We’ll see what happens in season 3.

By the way, I love trying to understand better the arcs in the shows and films I enjoy. It’s very refreshing to see writers actually research well into making the plot realistic. We in tech are normally not so lucky. That said, I’m always open to many suggestions of shows and things to look into.

Leave a comment

Outside of that context, I actually find the problem itself very interesting. So let’s explore it.

Task

The task definition is straightforward. We have to design a data structure that supports two operations:

1. Add a new [integer] number, and

2. Return the median of all numbers added so far.

In other words, the task can be summarized to implementing the following:

class MedianStream {
 public:
  // Constructor
  MedianStream();
  
  // Adds integer value to the stream
  void addNumber(int x);
  
  // Returns median of all numbers seen so far
  double getMedian();
};

[Github gist link]

For fun’s sake, let’s assume that every call to addNumber is immediately followed by a call to getMedian. This makes the problem get closer to its worst-case, and also makes our runtime analysis a bit cleaner.

Example

MedianStream* medianStream = new MedianStream();
// List is empty

medianStream->addNumber(10);
// Sorted list is now [10]

medianStream->getMedian();
// Returns 10

medianStream->addNumber(20);
// Sorted list is now [10, 20]

medianStream->getMedian()
// Returns 15

medianStream->addNumber(0);
// Sorted list is now [0, 10, 20];

medianStream->getMedian()
// Returns 10

I’ll talk about four different approaches to this problem here. The first two are unequally bad. The last two are “equally” good. If you face this problem in an interview (as I have multiple times before), I strongly advise to go with the better ones.

Lazy brute force

I don’t like calling approaches lazy, but this one actually deserves it. It is a lazy brute force because it consists of the laziest (in terms of brain-power) implementations of both functions that interest the problem.

• void addNumber(int x): Simply append the value x to some list values.

• double getMedian(): Find and return the median of values. How? Sort the whole list and get the median!

class MedianStream {
 public:
  // Constructor
  MedianStream() {
    numValues = 0;
  }
  
  // Adds integer value to the stream
  void addNumber(int x) {
    numValues++;
    values.push_back(x);
  }
  
  // Returns median of all numbers seen so far
  // Assuming this function is not called on empty lists
  double getMedian() {
    // Sort values
    sort(values.begin(), values.end());
    
    // Calculate and return the median
    if (numValues % 2 == 0) {
      return (values[(numValues-1)/2] +
              values[numValues/2])/2.0;
    } else {
      return values[(numValues-1)/2];
    }
  }

 private:
  int numValues;
  vector<int> values;
};

[Github gist link]

Runtime

The runtime of addNumber is great. We’re just adding a number to the end of a list, so it’s O(1).

The runtime of getMedian sucks. That little call to the sort function is the bottleneck. Remember that sorting a list of N numbers costs O(N log N). And that’s per call of getMedian!

Hence, calling addNumber followed by getMedian N times will lead to a combined runtime of O(N * 1 + N * N log N), totaling at an unfortunate O(N^2 log N).

Not a good way to pass an interview.

Brute force (but not lazy)

The great Yogi Berra said “you can observe a lot by just watching.” Indeed, if you look into what the current implementation of getMedian is doing, you’ll observe that we only care about one or two values of the list.

With that in mind, sorting the entire list before accessing one or two positions is not only overkill, but it’s also costly. If all we want to do is find the k-th smallest element of a list, the Quickselect algorithm will give you that answer in linear time. In C++, you could call the function nth_element.

I’ll not go into detail for the idea and implementation of those algorithms since they are not the main part of this note. However, I really recommend checking them out. They might come in handy (and they certainly have to me.)

Runtime

Nothing changed in addNumber from the previous implementation. It still sits at a wonderful O(1).

But now the runtime o getMedian sucks less! The one or two runs of the Quickselect algorithm will take linear time (O(N)), which is an improvement from the previous O(N log N). Again, that’s O(N) per call of getMedian.

In the end, N calls of each function (alternating) will total O(N*1 + N*N), or simply O(N^2).

We can do better.

This is a picture of my dog, Fox, to serve as break before heading to the next ideas.

Subscribe now

The actual solution

Let’s make Yogi Berra proud and watch a little more.

Every time we query for the one or two elements needed to find the median, we always query for the “same” position in the list. That is, we are always trying to figure out the middle of the list (we are interested in the median, after all.)

Also, first or second-year CS students learn about basic data structures that let us do insertions while preserving some type of order. The most popular ones are ordered sets and heaps. Those structures can only efficiently give you the smallest/largest element in a list. If you try to find out the middle element of a set, you’re gonna have a bad [run]time. Let’s assume then we can only know the smallest or largest element of a list, and solve the problem with that tool.

Finding the middle

Forget about the problem setup for a second.

Say we have a list S. Let’s split the list in two halves, and put the smaller elements on a list L and the largest at R. If S originally had N elements and N is even, L and R each have N/2. If N is odd, let’s say L has the smallest (N+1)/2 and R has the largest (N-1)/2 elements.

How do we find the median of S?

If N is odd, the median of S is the smallest (N+1)/2-th element (1-indexed). This is the largest element of L!

If N is even, the median will be the average of the smallest N/2-th and (N+2)/2-th elements (1-indexed again). In other words, this will be the average of the largest element of L and the smallest element of R.

Thus, what we need to efficiently find a median is for L to provide us with its largest element quickly, and for R to give us its smallest element. We can simply make L be a max-heap and R be a min-heap.

Updating L and R

Since L and R were defined as the left and right halves of the original list, there are two properties in them we actually care about:

1. No element in L is greater than an element in R, and

2. 0 <= size(L) - size(R) <= 1. This is equivalent of the previous definition we used of allocating the elements as a function of N. However, this doesn’t make us depend on N, which is nice.

Assume those two properties are currently being respected. When a new element X arrives, we want to add it to either L or R, and make sure those properties continue being respected. This is an overview of the algorithm:

• If X > max(L), add it to R. Otherwise, add it to L.

  • There’s a corner case to watch out here: if L is empty (as it will be in the beginning of the algorithm), max(L) would be undefined. We handle this case by simply adding X to L when it is empty.

• If size(R) > size(L), add min(R) to L, and then remove it from R.

• If size(L) > size(R) + 1, add max(L) to R and remove it from L.

The first bullet point guarantees property 1 is respected. The second and third bullet points are updating the lists in order to enforce property 2 (without breaking 1).

Note that, just as we expected, we only need to interact with the largest element in L and the smallest element in R. This makes our use of min and max-heaps appropriate.

Ok, where’s the code?

Here:

class MedianStream {
 public:
  // Constructor
  MedianStream() {
    numValues = 0;
  }
  
  // Adds integer value to the stream
  void addNumber(int x) {
    numValues++;
    
    // The algorithm described above
    if (!leftHalf.empty() && x > leftHalf.top()) {
      rightHalf.push(x);
    } else {
      leftHalf.push(x);
    }
    
    if (rightHalf.size() > leftHalf.size()) {
      leftHalf.push(rightHalf.top());
      rightHalf.pop();
    }
    
    if (leftHalf.size() > rightHalf.size() + 1) {
      rightHalf.push(leftHalf.top());
      leftHalf.pop();
    }
  }
  
  // Returns median of all numbers seen so far
  // Assuming this function is not called on empty lists
  double getMedian() {
    // Handling cases for odd and even numValues
    if (numValues % 2 == 0) {
      return (leftHalf.top() + rightHalf.top())/2.0;
    } else {
      return leftHalf.top();
    }
  }

 private:
  int numValues;
  // This is a max-heap in C++:
  priority_queue<int> leftHalf;
  // This is a min-heap in C++:
  priority_queue<int, vector<int>, greater<int>> rightHalf;
};

[Github gist link]

I heavily used the priority_queue structure from C++. Most languages have some default min/max-heap. Coding your own heap is not hard, but why would you do that?

Runtime

It may feel like we took a step backwards with addNumber. Before, without any thinking whatsoever, we had an O(1) implementation for it. Now, we have these [constant number] of heap pushes and pops. Remember that each of those operations takes O(log N) time. Thus, our new version of addNumber costs us O(log N).

We improved getMedian by as much as we possibly could. Its very short implementation is not deceiving. All we do is query for one or two roots of priority queues. Those happen in constant time. Then, this amazing version of getMedian costs… O(1).

After N operations of each of them, we’ll settle at O(N log N + N * 1), or simply O(N log N).

This is how you pass an interview.

Less code and less elegance

Don’t get me wrong, I love elegant solutions like the one above. It’s nice solving “complex” problems using only basic tools. Any introductory course to data structures will teach heaps, and that is literally all you need to solve this “hard” problem.

But I’m also a competitive programmer. When push comes to shove, I’d gladly throw away all my finesse if can save some lines or thinking time. Especially if the runtime is unaffected in the process.

Basically, what I’m saying is that this problem could be solved by importing a data structure. Yup. Take a look at the Wikipedia page on the Ordered Statistic Tree. It supports:

• Insertions of numbers in O(log N).

• Finding the k-th smallest number in O(log N) time.

It even feels like it was tailor-made for this problem. In fact, the ordered statistic tree supports even more operations than those two.

Another data structure that would immediately solve this problem (by supporting the two previous operations in O(log N) time) is the Treap. In my previous experience, it is much easier to understand a Treap than to actually implement one. Be my guest and have fun coding one.

Overall

This problem can be solved in O(N log N) time for N operations of each kind (alternating). There is a solution I find beautiful, and one that is less so. There are also brute-force solutions, but they are for losers. You’re not one.

I believe beauty in problem-solving has a time and a place. This blog is the place for it. I love the fact that this problem can be solved with primitive tools, rather than using complicated ones. When it’s your turn to solve this problem, feel free to choose the solution you want. I’m not your dad.

Just make sure it is fast.