You’re invited to an AMA session with Jayesh, ask him anything across- what goes behind building a Tech architecture for a Digital Bank, his most fruitful projects so far, what drew him towards tech and why and for all engineering aspirants out there – how did he get here?
It’s happening all here, but if you still need a reminder - register right away
Some helpful tips before you start 
Please only ask one question by replying to this topic a single time, using the Reply button at the bottom. It’s also helpful to scroll to the bottom while 
reading the topic to make sure nobody else has asked the same question first, before you ask… right? ! 
Please do not reply to anyone else’s post. The only purpose of replies here in this topic is to ask the author one question. If you’d like to discuss a related topic in more detail, create a new topic.
Please ask all your questions in one post. We’ll surely take the first one (or all), so everyone gets a chance ! 
This topic was automatically opened after 2 hours.
Hi Jayesh, so good to see you doing this! What sparked your interest in FinTech?
Welcome everyone! And say “Hi” to @Jayesh_Sidhwani, Chief Architect at Jupiter! 
Jayesh is here between 6 and 7 p.m. to answers all your questions about the tech behind Jupiter, what we’re doing differently, and what it takes to build a fully digital bank from the ground up! Comment on this thread with your questions and we’ll answer it live, right here!
Hi Jayesh. What is the scale at your system operated. And what were some of your learning while scaling up?
Thanks you for doing this.
What is the coolest thing you’ve learned since you started working on ‘building a bank’?
Hi @Jayesh_Sidhwani , What are the challenges you faced here building a bank which you didn’t when you were at Hotstar?
Hi everyone! Jayesh here. It’s great to see your questions already rolling in! I’ll start answering in just a few minutes. Keep them coming!
Hey Jayesh & Team. The Jupiter iOS Application Snapshots put up on website looks quite intuitive.
@Jayesh, I am curious to know about:
Hi Jayesh, thanks for doing this.
An architectural question - in the case of customer onboarding and account opening, how much of the process orchestration complexity have you taken into your platform as opposed to leaving the orchestration with the partner bank? In asking this, I am assuming it would have been a nightmare for you to use the bank’s APIs, let alone orchestrate them 
Hello Jayesh. Greetings.
Interested in knowing how you are going to impact the people at large and how things will improve. Also, interested in knowing how tech is handled in general specially in terms of scaling, etc. It should have taken a much consideration at your end
Hey Ratika! Fintech has always been my favourite space.
It started off with trying to understand how the stock markets work, to losing some money, to being intrigued by its fundamentals. I am a big believer in budgeting my expenses and have been using YNAB for a few years.
While being a consumer of a bunch of fintech products, the lack of innovation in the banking sector always intrigued me. Around mid-2007, we got the iPhone and that triggered the whole smartphone revolution. Buying things online and chatting with friends suddenly became easier and more natural than ever. So while on one hand we had this whole bunch of new experiences, our banking experience somehow remained old-school.
The last decade however has been great – we now have products that let us do everything from making payments to investing online. While it revolutionised the old banking industry, imo, it also fragmented it. I strongly believe that there is a need for re-bundling. Something that combines the goodness of these products while still providing a coherent banking experience to the user.
That’s what I crave, and that’s what sparked my interest in fintech.
Hey Ishail, Hotstar and Jupiter are extremely unique experiences for me. Hotstar was all about scale.
Jupiter is a bank and so requires a very different mindset. While Jupiter might not achieve Hotstar’s scale (I wish it does), there is very very little margin for error. You just cannot afford to go wrong. That means you have to think very carefully and deep when you’re building the product – there’s no blitzscaling at Jupiter. You go slow, but you do it right.
At Hotstart, security was one of the problem statements. At Jupiter, it is at the centre of everything we do. Security is a fabric that impacts everything we build.
Hey Pratyush, trying to answer one part of your question as @Tushar_Maroo also asked me about Tech- stack
Building from scratch is always fun because you can pick exactly what you need from such a wide variety of technologies! However, I’d be a little conservative and choose battle-tested technologies for production.
Here’s the stack I’d pick if I had to build from scratch:
Language/Frameworks:
This really depends on the problem statement – if you’re building APIs then I have found the JVM stack to be really mature. In fact, Kotlin appears to be a good language – it’s got the right mix of functional aspects along with the robustness of JVM.
At Jupiter, we primarily use Java and Kotlin for our server-side programming. For web applications, we use the SpringBoot framework.
I have personally found Ruby and the RoR framework to be really handy for building admin dashboards. The framework lets you be really agile while developing.
When it comes to pulling off one-time scripts, I have moved from Python/Ruby to Go.
Monitoring Stack:
I have a lot of experience with Prometheus + Grafana. I’d pick that anyday! There was a great blog by the folks at Zerodha on this topic
CI / CD:
Github Actions is my new favourite. We use it extensively for builds and pre-build checks. It is my go-to CI tool these days.
For CD, I’d pick either GoCD and Spinnaker. We use Spinnaker at Jupiter and we love it!
Deployment:
I would choose Docker + Kubernetes. At Hotstar, our platform team built a massive cluster that would handle a load to the tune of a few million requests per second. The entire infrastructure scaled seamlessly!
We use Docker & Kuberenetes at Jupiter as well. The ecosystem has fine tooling as well, which makes it a stronger option.
Data Lake
I’d pick S3 as an option for Data Lake. My choice of a warehouse will really depend on the scale of the problem. I’d pick AWS Redshift if it is affordable. If not, I’d look out for other options.
@Kushan_Shah Also happened to ask “What is Jupiter’s engineering process like? How do you manage engg team? What is the engg culture like? What keeps you up at night?”
Interesting questions Kushan!
We are a fairly small engineering team at Jupiter and we’d like to keep it that way. We have a few engineering philosophies that we follow: one which is to ‘do-it-right-the-first-time’. This is ingrained in how we attempt to solve any problem.
Our engineering team is divided into pods. A pod is a logical group of backend and frontend engineering teams, a product manager, alongside business and operation managers. The pod then becomes a self-contained entity that works on a problem statement independently.
With that structure, we have set up a few processes that ensure that while the pods work independently, the entire team is aware of what everybody else is doing. We are also meticulous with documentation. Any new problem statement we work on is documented first. We have a set template for writing an engineering spec, which covers the problem space, various solutions, a high-level and a low-level design, the execution timelines, and also the cost of ownership, when the product goes to production.
The specs are then published on an internal wiki that the entire engineering team can read. Besides this, we have bi-weekly architecture councils – we call this a Jedi Council. No kidding. It is called a council (mainly because we wanted it to sound cool), but the entire engineering team participates. Anybody from the engineering team can nominate themselves and present their engineering spec/architecture to the wider team. It is a great forum to receive advice and be critiqued on the spec.
Apart from the architecture councils, we do bi-weekly Demo-Days. Attendance is mandatory at these Demos for the entire organisation. We use this time to present our engineering work to the wider organisation and receive feedback.
While documentation is always good, this process also creates a lot of transparency in how we operate as an engineering team. Specifically:
Our engineering team is self-managed. We do not have managers, but we have team-leads. The team-lead is also the developer on the team with an extra responsibility of mentoring the other team members and bringing consensus on various discussions. At Jupiter, everybody in the engineering team codes and is expected to manage their work. Team-members can reach out to anybody in the team for mentoring. Ceremonies like the arch-councils and demo days are great ice-breakers and make the team more comfortable in seeking help from one another.
What keeps me awake in the night is a really tough question, because it is different on different days. The problem statement is really fascinating (and tough), and the engineering team is really amazing. The regular nights are all about how we can meet our launch timelines. At times, I think a lot about the newer problem statements the team can solve. There is a constant itch to do better; to see the final pole sooner - that keeps me awake.
Thanks @Jayesh_Sidhwani. That covered more than what I could have thought of learning on a Friday eve. Fintech inspires me as well and your answer gives me deep insights on fintech technical ecosystem.
Working on iOS & being curious about backend, I will explore the server side stuffs that you have mentioned.
Akshita Agarwal asked What are the difficulties you are facing /have faced while building the tech team from scratch?
I’d say that building a tech team from scratch at Jupiter has been just as easy or difficult as building one for any other product. None of our engineering team members have built a bank before, so it is the first time for all of us. However, our business and operations teams have decades of experience building banks, and that has helped us a lot. In fact, some of them have played instrumental roles in building a few of the top-10 banks in India. The value is immense!
This creates the perfect blend between people who know this industry and people who can create the product. And we strive to nurture that blend every single day.
At all times, it is important to stick to our first principles, and we have a few. These first principles always align us to a common goal. A lot of the time, we deviate; but as leaders, our job is to create an echo-chamber to keep realigning the team back to the first principles.
