In complex B2B systems, you often have to pick your poison when dealing with data accessibility.
I remember when Marketo was first developed and we asked how many leads/contacts a company would have. The answer we received was about 3k. Little did we know that the real answer would be closer 1 million leads and contacts for an average sized company and up to 100 million for larger B2B companies.
We thought we were being very clever by scaling up to 100k leads for quick access. Based on the scale being relatively low, I designed the system to be very flexible. You could have complex filters with and/or logic along with complex joins.
Unfortunately, like the magic triangle, you can’t have it all. There is no silver bullet to have infinite flexibility, speed, and large scale. Even 15 years later, database technology still takes significant time to quickly count and sort complex datasets at scale.
Of course, users want everything to be as fast as possible. The speed of light is the only speed users will stop asking for more. The key question is what to optimize for.
Speed & Flexibility
When you pick speed and flexibility, it means you need to limit the scale. Either your target data is naturally small and you can process the set quickly or you have to dynamically shrink the set. Think of it as sampling data. Using sampled data you can often find high confidence answers without actually polling the entire database.
Scale & Speed
With these two, you lose flexibility. You can hard code your UI to allow a limited set of filters that don’t get too complicated. You are basically hard coding the experience, but it will be fast. This is good when you have straight forward use cases and flexibility is not a priority. This also happens to be the choice of many systems that grew organically and didn’t think about future scale. To me, this is not the best strategy long term, but it can help you get some use cases to market quickly.
Flexibility & Scale
Speed as always good. Unfortunately, some questions are just not that easy to optimize on the fly. Whether you are adding many logic conditions or doing complex JOINS in the database, you can’t expect every question to be easy to retrieve. When you find yourself in this situation, you need to either manage expectations with progress meters, or you need to change your UI to be asynchronous. This means saying to user “Do you want me to let you know when I have your data?” Call this caching, or materialized views or asynchronous results. You can give the user what they want if the system has enough time to work on it.
My Suggested Optimization
I believe (for B2B software) you should design for flexibility and then work on scale and speed over time. It will probably be a never ending series of improvements, but the user will love you more because of the flexibility. That’s my take. Other hot takes out there?
Whatya think?