Skip to main content

Posts

Finishing what you started

A quality of a good Startup engineer is "Finishing what you started". I value finishers more than people who talk good theory and start many things but don’t finish most of them. Most of the time people get excited and start many things concurrently but leave them in limbo or they finish 95% of the thing.  Over 7 years at my current Startup I have observed that in many projects doing first 95% may take you X units of time but its the remaining 5% that demands 10x cognitive effort and time from you. Its this last 5% where people either burnout or give up. Its the finishers who keep the compass pointing to North star, never give up and do what ever it takes to Finish( in indian mythology saam, daam, dand, bhed). Recently One of my respected colleague "Sachin" left for a sabbatical. He was one of the Finishers whom I would hire any day on my team or would choose as a buddy to watch your back.  "Sachin" has a zeal like a Rhino or Triceratops to Finish what h...

What a rocky start to labor day weekend

Woke up by earthquake at 7:00 AM in morning and then couldn't get to sleep. I took a bath, made my tea and started checking emails and saw that after last night deployment three storage node out of 100s of nodes were running into Full GC. What was special about the 3 nodes was that each one was in a different Data centre but it was named same app02.  This got me curious I asked the node to be taken out of rotation and take a heap dump.  Yesterday night a new release has happened and I had upgraded spymemcached library version as new relic now natively supports instrumentation on it so it was a suspect. And the hunch was a bullseye, the heap dump clearly showed it taking 1.3G and full GCs were taking 6 sec but not claiming anything.   I have a quartz job in each jvm that takes a thread dump every 5 minutes and saves last 300 of them, checking few of them quickly showed a common thread among all 3 data centres. It seems there was a long running job that was trying ...

Hanging on to old things

I have seen my Kid grow from 0 to 6 year and one startup growing from 20 to 150 employees and another growing from 5 to 300+ employees.  A common trend I seen is hanging on to old things.  Not sure if its due to sentimental value attached to things or inability to make hard choices.  My Kid still has his toys that he used to play when he was 1 year old. He wouldn’t let us throw them or give it to someone, I am recently working with him to let go of old things.  Problem with old things is that they are a drag, they just sit around the house and are a clutter. Its the same with old books, I have many of them and one day I need to go and clean them once I read a book,  I rarely read them again so why not donate them to library. A common observation with Startups I have worked is feature bloat due to holding on to old features. Features that are not maintained but are in use by a handful of customers causes drag. Recently I wanted to refactor folder listing code t...

Little things and frustrations

Small shitty things frustrates me, like someone came up with an idea to put epic on each Jira task.  Well its suited for big Tasks that has lot of subtasks but 50% + of my cases don’t require an Epic. I am lazy and dont like to waste my time. I am creating an issue and filled all things and now this process requires me an Epic, total BS.  Yes this is total BS so either the process requires fixing where epic is first required field so I wont invest filling so many fields or this needs to be removed/made optional.

Data motivates you to do more

I always believed in "Trusting data" over human gut but lately I have been observing a simple fact that being data driven has a side effect, "it motivates you and  keeps you on track". Some recent examples are: Fitbit: Last year I started the afternoon walk because by 2:00PM after doing calls and replying to a lot of emails the brain would be fried and I wont have energy left to code or think.  Doing these 30 min walk daily recharges the brain. I  had an Omron pedometer sitting around for almost an year and I seldom took it with me on walks. The problem with it was that it used to store last 30 days data of my steps and other things but it didn’t had a good way to graphically see the data. When it comes to data "less is more" but also one more important aspect is that you need to present your data in graphs so it doesn’t take a huge amount of cognitive effort to make sense of it.  Recently my employer gave a fitbit to everyone who participated in summe...

Have I started hating mysql and falling in love with distributed databases

It seems Mysql is rock solid if you want: Transactions ACID support So I would still recommend mysql for any thing that is mission critical data and it should be the primary datastore for your transactions. But what about derived data, immutable data or analytical data? In past I have built large scale cluster of mysql server storing metadata about billions of files and folders used by tens of thousands of customers daily and its scaling fine and working good, its still growing at a healthy rate and holding up.  But this requires a lot of baby sitting if you have 100s of nodes and you need to do replication add more nodes rebalancing data monitoring entire cluster Sharding Backup/restore You have to write a lot of tooling and lot of monitoring/babysitting to scale the cluster. Plain stock Mysql will scale up to a limit but vertically scaling has its own issues. So +1 for Mysql but not everything should be stuffed there. Recently me and my team built ...

Rate limiting APIs and Java services when operating at Scale to solve Thundering herd problem

When you are operating at scale and handling peak traffic of 1K+ request per sec on a jvm then no matter what you do you would get hit by a Thundering herd problem. There would be operations that happens once in a while but take more than 10 sec and if there are too many of them happening then you could choke backend services or worse cause a downtime. So you need to Rate limit these long running operations that only X can run at a time, this way you are leaving room for running lots of short lived transactions. When you have millions of users then not all users are doing these long running operations and not all traffic is coming from online users. We are a cloud storage company and we give sync client to users so 80%+ traffic at a given time is coming from these clients that are trying to sync changes between cloud and local system behind the scenes.  Our application is written using REST apis and these clients  are using the same REST apis that our web ui is using.  ...