Impact and optionality
How to make impact and create optionality in your career. Plus how Netflix handles synchronization between different devices.
Hi Friends,
Welcome to the 13th issue of the Polymathic Engineer newsletter.
Today we will talk about:
How to make impact and create optionality in your career
How Netflix handles synchronisation between different devices
Coding challenge
Two interesting tweets
Make impact and create optionality
Two things helped me to progress in my career as a software engineer: creating optionality and making impact.
Optionality means creating choices for yourself in your career. The more options you can create, the more possibilities you have to get what you want. Creating options means being free to change jobs or do anything in particular.
Optionality gives you more possibilities. For example, you could not be happy with your management, work scope, or company direction. Optionality gives the choice of leaving to join another company or find another job.
These are few way to create options:
1. becoming a developer who always brings value
2. attracting recruiters with a solid inbound process (i.e., a well-set LinkedIn profile)
3. networking and making allies to get access to a job even before it is public
The last point is often very underrated, but this is how I got my current job. An ex-teammate referred me to the hiring manager even before opening the position. Always try to build trusty and worthwhile connections around you.
Making an impact means creating more value at your current company. The more value you create, the more leverage you have to: get promoted, work on exciting projects or increase your compensation and perks.
Many people I've seen moving up very quickly contributed disproportionately to their peers. They were bringing more value, and they received more value.
There are 2 ways to make more impact. First, acquiring new skills or leveraging your existing skills. Second, earning influence with the people around you.
This last point is crucial. You can have an outsized impact by only influencing others and getting them working with you.
Devices synchronisation at Netflix
Netflix has 220+ million of users and each user can access his/her account from multiple devices.
Users can start watching a movie on their mobile and switch to their laptops. After switching, users expect Netflix to continue playback exactly where they left off. Also, other information needs to be synced. For example, membership plans, profile updates, movie recommendations, diagnostic information, etc.
Syncing this information for all users and devices requires a lot of communication. At peak, 150 K+ events per second are exchanged between the Netflix backend and the devices.
Netflix's backend is based on Microservices and they have a specific service to handle all these events. The service is called Rapid Event Notification System (RENO).
RENO is triggered by events coming from other backend services handling profile changes, watching activities, etc.
These events go to the Event Management Engine. This layer of indirection is introduced to simplify things and have a single source of events. The Engine was built using a Netflix's internal distributed computation framework called Manhattan.
The events are then passed down to Amazon SQS queues sharded based on event priority. This allows for tuning system configuration and scaling policies for events based on their priority. For example, events related to a child’s profile maturity are highly prioritized.
AWS Instance Clusters subscribe to the queues and process the events. They generate actionable notifications for all devices sent to the outbound messaging system. This system handles delivery to all the various devices.
Notifications are also sent to a Cassandra database. This allows a hybrid communication model of push and pulls with the devices. Using only pull wouldn't work because it makes mobile apps too chatty and slow. Using only push wouldn't work when a device is turned off.
Various gate checks before sending an event are added to reduce the load on the system. For example:
- push events are sent only to online devices (tracked with Zulu)
- time-sensitive events too old are not sent
- duplicated events are removed
You can get more details reading this post in the Netflix engineering blog.
Coding challenge
The coding challenge of last week was Implement Queue using Stacks.
The problem asks to implement a queue using two stacks. A queue is a FIFO data structure, while a stack is a LIFO data structure.
So you can enqueue elements in a stack, but you can't dequeue them from the same stack. But if you move the elements from the first to the second stack, they are in the correct order for being dequeued according to a FIFO policy.
Of course, the elements need to be moved only once when the second stack is empty. Otherwise, newer elements would override older ones.
The time complexity of this solution is O(N) amortized because an element is moved to the second stack only once. The space complexity is O(N) because of the stacks,
Here is the code for the solution:
The coding challenge for the next week is 496. Next Greater Element I.
Interesting tweets
LinkedIn is a social network and a great source of inbound opportunities. I've always found LinkedIn a gold mine of job opportunities. The time spent setting up a good profile is well-invested.
There is nothing wrong with looking for a satisfying and successful professional life. But for me, the family will always come first. How can you even call success after losing everything that matters in life?
