I’m personally happy with where things are at the end of this year. We’re on a vacation to visit our family after three years. My kids met some of their cousins for the first time and they’re incredibly excited to get the attention from the extended family. Living in a country half a globe away from our origin means they hardly ever get to experience the warmth of the family and Covid made everything so much harder for the last few years.

My 2021 resolution was to be more mindful. But I made the rookie mistake of having a goal without metrics and a clear strategy. So, I can’t tell if I was indeed more mindful or not. In this post, I’m sharing some highlights from my 2021, in a random order. I personally find it fascinating to look at these at a later time. Family. Thanks to work from home for the entire year, we spent a lot of time together as a family.

I find open-source to be a rather loaded term; it means different things to different people. For this blog post, I’ll imagine there are two kinds of open-source products: Company-owned open-source Crowd-owned open-source I’m writing this blog post specifically about company-owned open-source products. In a typical company-owned open-source product, the company pays us to develop and maintain the product. I’ve been working on the Azure Communication Services UI Library that falls into this category.

At Microsoft, I’ve been working with my team on a multi-platform UI SDK for Azure Communication Services. We empower developers to build visually delightful communication experiences (chat, audio-video calling, etc.) for everyone. I’ve participated in numerous design discussions on this UI SDK and I realized many of the things I learned here apply to the domain of UI SDKs beyond just the one we are creating. So, this blog post is an attempt to make a list of design principles that developers of UI SDKs can follow to create a bigger impact out of their work.

“I promise to take care of you” - believe it or not, I spent hours to come up with this message to make a first impression as a newly hired manager at Microsoft. Everyone in my team had more context than me. I was a complete newbie, yet their manager. While I had been a manager for several years, I had never started a new job as a manager. I felt super vulnerable.

Most applications have a request-response based single-channel data-flow. In such systems, human or software triggered requests are served by software provided responses. For example, when you make your DuckDuckGo search, you initiate a request and their server produces a response back to you. Realtime multiplayer systems are quite different because the pattern of information flow is more complex, often being a two-way or many-to-many data flow, with strict latency constraints. For example, when you chat with a bunch of friends, or join them for a video call, the data-flow is quite different than when you watch a YouTube video.

Continuing on this architecture series of posts. Similar to the post on Redis, this time let’s focus on another hugely popular distributed database called MongoDB. If you aren’t familiar with MongoDB, it’s a distributed database that allows you to store and query humongous amounts of JSON-like data. To get an overview of MongoDB and its architecture, you can watch the following YouTube video: Of course, you can also download the official architecture guide to learn more.

Welcome back to the Software Architecture series. I know at least a few people from my team are following, and that’s a great encouragement. For today’s post, let’s focus on learning from a very popular and commonly used open-source project called Redis. To the developers, Redis is a dead simple key-value store with a super simple API as follows: $ set today 'Thursday' OK $ get today Thursday $ set temp 20 OK $ incr temp 21 $ incrby temp 3 24 $ get temp 24 Of course Redis has more advanced features, but not too many.

In my current role at Microsoft, I’m working on a UI SDK product. I hear this concern from some of my team members. More specifically, here’s a paraphrased version of what I hear: “I talked to my friends in software and they told me it’s better to work on the backend or full-stack to have a fast-tracked career.” First, I do agree that there are generally more full-stack or backend engineering jobs than purely frontend jobs.

An architect first needs to write for herself, and then for her team. Let me explain a bit. An architect takes the trio of requirements, people, and environment, and does her research to design the most delightful system. In her research process, she uses her past experience as well as the experience of others. Even a moderately complex system design involves a lot of trade-offs without clear winners. For example, given that there are tens of different databases one can choose, how can she recommend a specific one?