Bulky, Chatty Protocols: Minimalism in Protocol Design
– Sujith Nair (CEO & Co-Founder, FIDE)
“We should add all the elements to the protocol. And add them as new independent elements, the fastest way to do this.”
Solving large-scale, complex and continuously evolving problems requires an approach that doesn’t look at “scale” as an afterthought. This applies to problem-solving in all spheres, and tech protocols are no exception.
Discussions on such topics are exciting and challenging at the same time, as they should be. The mental models at play are fascinating. To identify them and for everyone to become collectively aware of them is what makes the endeavour so exciting. Here are a few thoughts as we learn to translate our best intentions with open protocols into outcomes we want to achieve.
Design is often counterintuitive. Exercising restraint from tinkering is an elusive virtue. It’s a very thin line that separates it from complete avoidance or being overly conservative. Right questions, more than a fetish for answers, define that line. As inconvenient as it may appear.
‘Minimalism’ is often a need felt when designing and evolving protocols. Protocols are expected to withstand the test of time and enable the exponential evolution of applications built on top of them. TCP/IP, and HTTP, even after several years, remain lean as compared to the pace of growth of feature sets of applications built on top of them. Protocol design hence carries a different mindset.
The critical difference is the pursuit of “finding what works at scale” instead of “scaling what works”. The former introduces a different playbook to the approach and is vital for protocols.
Bulky, chatty protocols can introduce challenges to interoperability at scale, defeating the very purpose. Exclusion creeps in, and the correction could become too costly with the significant investments they attract. That’s a tech debt we must avoid.
“We need X, Y and Z to be added”. A new need (e.g. a new use case, policy compliance) felt on the surface may not always translate into a new feature in the protocol. Layered abstraction of design and ascertaining the suitable operating layer at which the need should be resolved is a way to mitigate (not entirely avoid) the risk of a short-sighted design. That way, design suffers from the outcomes we chase. Outcomes justify the means, so long as we know what outcomes we are serious about.
“Less is more.”
It doesn’t mean we ask lesser questions. We will not always have the right answers, and we don’t have to wait for them endlessly. But we should not avoid asking questions that matter, even when running at speed, lest we run in circles.
This approach, as mentioned earlier, applies to things beyond tech protocols.
- To explore the Beckn protocol and be part of our community
