Applying the Event Sourcing Pattern at Scale with Andrew Elster from Earnnest

Eric Dodds  00:06

Welcome back to The Data Stack Show, Eric Dodds and Kostas Pardalis here. We have a part-two episode today. We talked with Dan Jeffords of Earnnest. And he told us all about how money moves in the US financial system. And today we get to talk with the CIO of Earnnest who is leading all of the technical efforts, and building some really interesting things including an internal event streaming system. So we’ll talk with Andrew Elster in a minute, but first Kostas, digging into more of the technical side of the consumer financial app, what questions do you want to ask Andrew?

Kostas Pardalis  00:44

First of all, I mean, I think we are going to have a couple of product-related questions. What’s like, for example, the difference and what’s the added complexity in their use case compared to other popular financial products like PayPal, for example, Venmo, and all these products that we use every day. So that would be very interesting to hear from him how these products are different from what they built and if there was any kind of complexity added. And of course, but something that I mean, it’s a conversation that we started on our on our previous episodes about how you can build financial products, which of course, as we know, they have technology products, financial technology products, that we know that they have very specific challenges and requirements in terms of security and consistency and all that stuff. And do that and at the same time, have the agility that the startup needs, right. And this is something that it’s also product related, but also technology related. I know that some of the technological choices that they have made are exactly for this reason, as we discussed in the previous episode. Like for example, the use of language like Elixir. So yeah, I think it will be super interesting to learn more about the technology and the product decisions that they have made so far. And, of course, what’s coming in the future.

Eric Dodds  02:08

Great. Well, let’s jump in and chat with Andrew. We have a part-two episode today from Earnnest, we talked with Dan Jeffords a couple weeks ago, and Andrew Elster is on the show today. Andrew, thank you so much for joining us,

Andrew Elster  02:23

Hi, glad to be here.

Eric Dodds  02:24

Well, we talked with Dan and really enjoyed learning in many ways, just about the way that money moves in the banking system in the United States. And, you know, Kostas had some really good questions being from Europe, and I learned things about the way that money moves here in the US that I’ve never known before, and many questions for you on the technical side. But before we dive in, I would love to know about your background, and then how you got involved with Earnnest.

Andrew Elster  02:57

Sure, well, my background actually starts in electrical engineering. That’s what I went to school for, but I had a much, well, I was much more interested in the software side of things. So I ended up focusing on embedded systems and digital signal processing and ended up moving down to Texas from Oregon to get involved in the oceanic oil exploration industry. That’s where all my fun stories like being shot at by pirates and having to bribe my way out of Nigeria come from.

Eric Dodds  03:35

That sounds like another podcast episode in the making.

Andrew Elster  03:38

Yeah, really. But you know, I’d be out on a boat for a month at a time helping to install equipment and support the exploration endeavors. And actually, that gets kind of tiresome, and I didn’t like being out there. So I focused more on getting up to speed with web development during one of the month-long stints. Came back and started working in the industry, and from there just did a wide range of stuff, working at agencies, working on different products and marketing technology. And then a few years ago, Dan and I were sharing an office space, we weren’t working together at the same company, but we were splitting a little co-working office space, became good friends, and then of course he started–I believe you already told how he got the idea to start Earnnest? So during that time, we were sharing this office, and then he, you know, proposed to me to help him build this thing? And I was like, Sure, I know. I’m a sucker for good ideas and fun new projects. And so I jumped at the opportunity to do it. And it was just the two of us for a while, just plugging away building this thing.

Eric Dodds  04:53

Yeah. Interested to know but before we dive into some of the technical questions, but Starting out in electrical engineering, and I’m not a software engineer, and I’m certainly not an electrical engineer working on, you know, electrical outlets in my house scares me. But I’m interested to know, do you feel like your background as an electrical engineer influenced your approach to software engineering?

Andrew Elster  05:21

Oh that’s an interesting question, maybe? I mean, probably, undoubtedly, it does. I don’t know that I’ve consciously actually thought about that. I think and, you know, coming from that background, I was probably more, you know, tinkering, driven, you know, play around with stuff, exploratory, and over the years have actually had to acquire different kind of engineering skills and software development principles and frameworks and concepts and things. So it’s been a, it’s been a shift.

Kostas Pardalis  06:04

That’s very interesting, by the way, I also have a background in electrical engineering. My first degree’s officially called like, electrical engineering, computer engineering at the same time, so I have like, I didn’t start it like in the states I studied in Europe. So it’s probably something similar to what you have here as like the difference between a major and a minor. So I had spent quite a lot of time on like studying stuff around electrical engineering. But okay, my focus and my interest was from the beginning around computers, computer engineering and computer science. But I think, because I have thought about this quite a lot, to be honest, I think at the end, the engineering discipline, it’s like on its own, let’s say something, regardless of if you are going after electrical engineering, computer engineering, or mechanical engineering, I think there are some core principles that remain the same. And this has to do with how you apply certain methodologies on how you solve problems, how you’re using scientific knowledge to solve more efficiently these problems. And all that stuff. That’s, to be honest, I think they are common across all the different disciplines of engineering convenient. Yeah, that’s my opinion.

07:19

I would agree with that assessment. Well, there’s also just in the engineering program, you have to have a certain amount of familiarity with all the others. So you know, if you’re an electrical engineer, you’ll still take, you know, some data, you know, computer science classes and data structures and algorithms and things like that. And the CS guys have to take a circuit class. And so there’s still cross pollination even in undergrad.

Kostas Pardalis  07:44

Yeah, absolutely. And I think one of the best examples of that is PageRank, like PageRank, as an algorithm actually, it’s, let’s say, the result of cross pollination from electrical engineering and how circuit theory and how algorithms around circuit theory in solving the problems there actually was used to solve the problem that PageRank was doing for Google. So there is a reason that electrical engineering and computer engineering are quite similar. But they are like, for me, at least they are like close siblings, let’s say.

Andrew Elster  08:20

Yeah, yeah.

Eric Dodds  08:22

Yeah, it’s interesting, I, in a previous role, was very involved in education around software engineering. And one thing that was fascinating to see was that no matter what sort of specific technology that a student studied, or their background, it really came down to an approach to problem solving, you know, which is really common in all engineering disciplines. And if you understand problem solving principles, you can sort of apply that to different syntax, if you will, you know, within engineering disciplines, which is, which is really interesting. So an interesting tangent there, Kostas, I had no idea that you had a background in electrical engineering.

Kostas Pardalis  09:05

Yeah, but I would recommend you to not ask me to help you with any electrical circuitry in your home.

Eric Dodds  09:13

Well, the other thing is, that’s pretty unfair, because fixing an electrical outlet in your house, and, you know, electrical engineering as sort of a study and a profession, I think are two different, two pretty different categories. Well, I’d love to talk about Earnnest specifically in your role, Andrew, so just as a quick background for listeners who may have missed the past episode, and correct me if I get anything wrong here, but earnest is an app that facilitates financial transactions that happen as part of real estate transactions. And we talked with Dan a lot about sort of the the wires and ACH, but I’d be interested to know, thinking about the financial industry and your previous software experience, and it was interesting hearing you talk about, you know, Dan, bringing up the initial idea and starting it, how did you approach Earnnest differently, if at all, as sort of an architectural problem when building the product than you have previous software engineering projects?

Andrew Elster  10:24

Well, it’s a good question. I don’t know that the problem itself was very different. I mean, initially, we were building an app, a mobile experience for a real estate agent, to initiate requesting transactions, and then help their buyer pay this money. So a lot of it was, you know, very straightforward web experience type things. I would say that, you know, the scope of what we were looking at was much smaller initially. So, you know, it’s hard to anticipate what the data is going to look like, and how, how much you need to care about or what you need to care about, a lot of that stuff is just discovered and the evolutionary process of, you know, building something and getting people to use it and testing the market, exploring things in this constant feedback loop. It almost feels like you’re rewriting the program multiple times, before you get to that first launch because the feedback you’re getting during exploration opens up, exposes all the things that oh, you know, maybe we should structure it this way, or you’re just storing this kind of stuff. So I would say we learned a lot over the last couple years. And now we’re focusing on the underlying data structure being very, very, very much more flexible and less contextually tied to real estate specifically. So we’ve worked on, you know, broadening the terminology that we use in the system. So it’s not as laden with real estate meaning and context, because what we actually ended up doing was building a unique way of moving money and allowing multiple participants to participate in that transaction and observe what was happening in it. So it has applicability, well beyond just real estate, so that I would say the biggest change was going from a small focus building a tool for real estate agent, to building a more general purpose payments platform.

Eric Dodds  12:55

Interesting. I’d love to dig into that just a little bit more. So you mentioned multiple participants in a transaction. So, when I think about transactions, I think lots of people probably think about Venmo, right? So you know, we go out to lunch, and I forget my wallet. And so I just Venmo you later, or you know, PayPal or Stripe where the relationship is between you and a particular vendor? Could you explain what’s different about multiple people participating in a transaction? Because that’s kind of an interesting, interesting paradigm.

Andrew Elster  13:33

Yeah, so all those solutions or those products and companies are examples of direct party-to-party type payment transactions. But it turns out, there’s quite a lot of money movement that is brokered. So you have a third-party facilitator, you could have someone helping to set up an agreement to transfer a large asset. So they’re drafting a contract, and there’s going to be, you know, some, you know, the asset that’s under transfer and someone’s going to be paying for it, someone’s going to be receiving it or someone is going to hold it in trust or an escrow and then eventually it goes to the person who’s ultimately going to be receiving the money. So there’s different parties involved in different accounts that have to hold it and the person kind of helping kick off the transaction itself may not be the sender or the receiver. And that was in fact, the scenario we were tackling diving right into solving the Earnnest money problem specifically. We were trying to solve having to write a paper check of the Earnnest money when you’re putting an offer in on a house. Turns out that trying to solve that digitally involves making sure a whole bunch of different parties were involved. You know, both the listing agent and the buyer’s agent. And their respective brokerages were interested in this, the escrow holder is of course interested in the payment, the mortgage lender is interested because payment … There were so many parties that needed to know that the transfer happened or what the state of the transfer was. And the person setting it up wasn’t the person actually paying the money. So building a platform that allows, you know, this kind of flexibility where it’s, you’re not constrained to just direct participant-to-participant payment works well, and any type of legal compliance situation anytime you’ve got a brokered transaction. So that’s kind of what’s unique about what we do.

Eric Dodds  15:49

Very interesting. And, you know, this is, again, I’m not the more technical host, and so Kostas may have some questions as a follow up to this. But how does that approach the way that you sort of think about designing, you know, databases that the product leverages? Are there any unique components there, when you think about all of those different parties being involved in sort of a single transaction, or a series of transactions?

Andrew Elster  16:21

Well, it means that we, you know, we have to facilitate multiple users linked to, to a payment. So we have to know a little bit about, you know, what their role is, we have to, we have concerns about, you know, what visibility they need to have, what notifications you receive. So, you know, we have to take some care around how we structure the data that way. But otherwise, it’s fairly straightforward. And you’ve got users, transactions, there’s ultimately a sender and receiver and you’re a sending funding source and the destination funding source. And we can keep track of all of those things that are kind of joined together. So anybody needs to see the whole picture we can, we can surface that.

Kostas Pardalis  17:10

Andrew, I have a question. I, you, you and Eric were chatting, like so far, and you were saying about the difference of having like the simple transactions that we have seen with like Venmo, or the rest of the vendors out there, where it’s like, you know, like a point-to-point transaction. And you usually have like, just two participating in the transaction. And here you have like the case where you have multiple entities participating in the transaction for it to complete. Is this something that as a process, I mean, is there a process on that? First of all, like, is there business logic that has to be built and enforced on top of that? And is this reflected on the database? Or it’s something that’s like more on the application layer? And what I’m trying to say here is that I mean, when you have like two persons, like two parties transacting, like, it’s straightforward, right? One, send something to the other person, and vice versa. When you have multiple people, then things might become more complicated. And you might have, let’s say, for an example, I have to pay you something. And you have to pay Eric, and you cannot pay Eric, before I pay you, right? Is this like the case here? Is this something that’s happening? And how do you represent this complexity both on an application level and data level?

Andrew Elster  18:33

Okay, that’s the question. Well, first of all, so this gets set to one of the differences in the existing product that we have and the new approach that we’re starting to take. Because this initial problem is very laden both at the data level and the application level with what you were calling a business logic around, you know, who has a particular role, and what can they do in their participation in this transaction. And so we ended up making an opinionated workflow that people in the real estate industry needed to play with. So it works well for a lot of cases, but it makes it complicated to adapt that and make it work well, you know, across the board in all areas for everybody’s situation. And we really want to not be in the business of creating the workflow that everybody has to be a part of, but instead, power or support anybody’s workload they already have set up. So we’re moving away from already having those concepts and business logic imposed in the data layer and in the application layer and instead set up the ability for our customers to create configurations, which have the constraints in them, so they get to set up the constraints. And so really, what we want to do is, is to have the underlying payment primitives that can be used to build the actual payment scenarios that any of our clients need if they’re in the real estate, industry or otherwise. And so there’s different sets of complexities that go with that. I think if you’re solving, if you’re just trying to make one particular workflow, that’s easier, that’s more straightforward to do. If you’re trying to build a toolbox, then things are a little bit more complicated, because you have to separate the data out and try and think about what are the general use cases that someone can make more specific use cases, but you’re not artificially constraining or limiting that. So that’s, I think, the biggest source of complexity with the new direction we’re going, you know, trying to provide that flexible, flexible toolbox.

Kostas Pardalis  21:10

Yeah, that’s, that’s very interesting. I mean, I know, business workflows in general, and like trying to model these kind of transactions can become like, super, super complex. And as you said, like, it’s one of the things that they’re like, you know, each one of your customers might fall into like a slightly different variation of that. It’s very interesting from a product perspective, like how you can scale this up. And I think, one of the, like, an important reason why you see that all these big companies that we are talking about, they’re mainly focusing on like their one-to-one transactions, because it’s like, as a problem, it’s much easier to solve. And, of course, like the scale, it’s because of the app, that’s what is important for a business.

Andrew Elster  21:54

Yeah, that’s very true. And the other thing is what, what we’re realizing is, really what our customers want is not a new app for their employees to use, or their contractors use if they’re real estate agents, they’re not really looking for another tool or another workflow, they want something that’s built in to the interfaces and tools and workflows that they’re already utilizing. So our shift with our enterprise focus is on interoperability on having an API, facilitating single sign-on to our platforms, being an easy integration. So the focus is, you know, we can’t solve all the use cases, we can’t imagine all the use cases. But we have uncovered, you know, the need for there to be more than simply two parties in the transaction. And we can kind of provide the general primitives, the ability to supply your own logic and constraints. And you know, with an API, you can then plug that into a software tool that you’re already using. So we don’t have to solve the use case, per se, we just have to provide the tool that you bring the use case, we bring you the API and the tool that will let you solve it.

Kostas Pardalis  23:26

Yeah, it makes total sense in terms of like, trying to create and build the product around these complex problems. You mentioned earlier, when you were talking with Eric, that there has been like an evolution on your database schema, like how you represent data, and you’re trying to like to represent things in a more general way, having like on the more, let’s say tied to the real estate problem that you’re solving. I have my theory of like, how I try to approach and what do I believe about data in general. But my belief is that the way that we designed the database reflects in a way how we understand our world in and of course, in our case, because we do not try to model everything but a very specific problem. The way that we represent the data, it also reflects our understanding of the problem that we are solving. And that’s why we’re iterating also, right, and we cannot get this like right from day one. Because as we build the product, as we interact with our customers, we learn more; we decide that the way to solve the problem might be different. And then we have to iterate and change the way we represent the data. So I think from my, for me, at least, it would be super interesting to hear from you how this evolution happened. From day one, like how you designed your database and how it is today. And if it’s possible for you to try to give us some clues of how this evolution also reflects the business, the evolution of the business and the understanding of the problem that you have?

Andrew Elster  25:01

Okay. Well, you know, initially the database was fairly small, and we were focusing on a smaller problem but over time, you end up thinking, well, we need a new support this feature, so we start adding columns, and then this can no longer be represented in one single table, this is a separate entity and, and then, so the tables start to proliferate and join tables start to proliferate. And it just just kind of naturally grows as you learn about new entities and things that have to be stored in the system. And this kind of gets to the heart of why we are approaching a different persistence pattern for parts of our system. For the payments part, the core part of our system, we’re looking at leveraging what’s called event sourcing. And the basic idea behind event sourcing is that any interaction in your system that is going to mutate the state of data, you capture that as an event, and you just have this log of events that you’re constantly just constantly appending events onto this log. And then what you do is you create handlers that react to the events on the log and project the data into a tabular structure that’s suitable for querying or into a different data store, maybe it’s a cache or some other way of storing the data. But what you’re not doing is starting with just a standard, you know, relational SQL database. And, and it only represents whatever the current state of the world is. I said, you’ve recorded everything that’s meaningful. And you can go back, reprocess those events, project it into a different data structure, and so as you discover things that need to be tweaked or changed or you know, this would be a more advantageous way to query or we want to ask a different question about data, well, you just add another handler, or tweak the handler and rerun the events, and then your data gets transformed into the new structure that is more suitable for the interface, the application or the experience that you’re trying to deliver.

Kostas Pardalis  27:36

That’s super interesting. And how do you implement event sourcing today? Like how have you, how do you do that, like, what kind of technologies you’re using, what kind of infrastructure and how you’re dealing with maintaining, like this immutable log of events that represent the mutations of your data?

Andrew Elster  27:57

Sure, so we are, we’re just getting started implementing it, actually. And we’re gonna try and do it as simply and nimbly as possible. So we’re going to use … I mean, our infrastructure is already leveraging Elixir. So we’re looking at different Elixir frameworks that already exist for facilitating event sourcing, things like Commanded or Incident, is one we’re currently evaluating. We’ll store the events in Postgres, our database, there are specific specialized data stores for event sourcing, but I don’t think we even necessarily need to adopt it at the moment. So we’ll set up an event store in Postgres, and then we’ll also have our standard querying side of the equation in Postgres as well.

Kostas Pardalis  28:55

That’s interesting. So how is this going to work on Postgres, you have like, okay, like, the typical, like relational model, right? Usually the way that you model your data, so you always keep, like, the last state of your data there. Are you going to replace this with a different data model, or you’re going to have like, the main entities that you are using to model your problem, and then have also some kind of like, log like, structures inside your database to keep the changes?

Andrew Elster  29:28

Right. So there’s two separate databases. One is the event store and the other one is the read model. So the event store is, you know, very simple, you know, it’s one simple data structure, the, the event stream ID and the actual event and then the data and metadata of the event, and you’re just constantly appending and adding more rows to that. And then I said, we build handlers that subscribe to the events as they come in, take the event data and write it to the other Postgres database in the table structure that we currently have designed. And by building things in this way we can change your mind, you can, we can rerun those handlers and project the data into a different table structure, or into a different data store. You know, maybe we want to leverage something else besides Postgres for some future, way of querying the data. We have the flexibility of knowing we don’t have to, we’re not overwriting the current state of the world, we can go back and reprocess it, re-project it.

Kostas Pardalis  30:42

That’s very interesting. And how does Elixir… is there like some kind of synergy there? Do you think Elixir is like a language that helps more like implement on a model with event sourcing?

Andrew Elster  30:54

I think so. There’s there’s a couple ways that it ties in. So first of all, it’s Elixir. You know, it runs on the BEAM, which is the Erlang virtual machine.

Kostas Pardalis  31:04

Yeah, that’s exactly what I wanted to say and I forgot, like, I wanted to talk about that.

Andrew Elster  31:09

It’s a fascinating piece of 30-year old technology built to run these concurrent asynchronous telecom use cases. And then, you know, José Valim came along and he took things that he learned from working on Ruby and Rails, and made a language, Elixir, that runs on top of this Erlang runtime. So what you get is a technology that was built specifically for concurrency and asynchronous use cases. And you get it with a very nice to work with language syntax. And you also get … it’s a functional language versus object oriented language, which, frankly, it makes the code a little bit easier to reason about, little easier to understand what’s going on. But you know, event sourcing, in principle, is a functional pattern. You think you’re just doing a, you know, a left fold over all your event stream and running that through a function. And that’s, that’s your transformation into the current state.

Kostas Pardalis  32:27

Yeah, that’s actually my next question. If you think that because functional languages in general, they promote a concept of immutability in general. And that works very well with event sourcing. And it makes sense like event sourcing comes from functional programming. So that was my question. If you think of the fact that you have a functional language, and you have a model that it’s immutable, in terms of how you work with the data, if this is something that worked very well together, which you answered already. So it makes total sense. Cool. That’s super interesting. I mean, I have to be honest, zero experience with Erlang and Elixir, right now. I know very little about it. I mean, I have never used it, I know what you said about the purpose of Erlang itself in terms of giving extreme fault tolerance and reliability in software because exactly software had to run on telecommunication systems. So we had on the previous episode, like we were discussing about this, the importance of having these characteristics when you’re dealing with financial software, right? So what is the value from your more technical perspective of using something like Elixir and Erlang, to drive an application that at the end, when someone wants to make a payment, if it fails, or something goes wrong? I guess they can easily get frustrated, right? Like no one wants to mess with their money? Did this affect your decision to use this language and these platforms? And what’s your experience so far with it in terms of solving the problem that you have?

Andrew Elster  34:11

Yeah, so what really drew me to select Elixir and Phoenix had a lot to do with the joy of programming in it, its performance characteristics and the ability to reason and understand what was happening in the system. Part of managing the software development is very much read oriented. You write all this code, but you spend a lot more time reading code than you do writing it, and if a system is more easily understood, if you can introduce someone to how it works, and they can be productive building on it, and you can easily understand what’s going on. It’s easier to troubleshoot and solve problems as they come up. Sure, but what was what was interesting to me because I, over the years have worked with every web language and platform out there, you know, PHP frameworks and CMS to, you know, no JS frameworks, to Rails, to, you know, you name it, I’ve booked a little bit of this, and that just about everything. Elixir and Phoenix just really stand out as being the right culmination of different principles and ideas, being introduced in a compelling package that is great for that layer of the web stack. It’s really resource efficient. And it does such a good job of taking in requests, starting a very lightweight process, not blocking anything else that’s going on in the system. So as far as the request response layer of the system, you just, it’s really, really hard to beat Phoenix when it comes to that.

Eric Dodds  36:07

Did you consider any other languages? Or did you know you were going to leverage Elixir and Phoenix from the get-go?

Andrew Elster  36:19

I was pretty much going to leverage Elixir Phoenix from the get-go. But I did delay making that decision for a while. So we, we built the app as a front end app, the initial prototype in Ember and just kind of mocked out what the back end would be like. So we kind of push that off for a while, you know, so I could kind of play around with Phoenix and see if it really was going to be something we wanted to do. But it was very quickly something that I realized, like, Oh, this is like the perfect little spot in the web stack. You know, that’s the go to i would i would adopt.

Eric Dodds  36:57

Very interesting. Well, we’re getting close to time here, but interested in the scale of the business and how that impacts sort of your approach to programming or any challenges you have. So I know you started out small with an app for real estate agents. But how many, you know, how many transactions Do you process, you know, daily, or weekly? And what’s your current scale? And then it sounds like you’re working on sort of increasing that, you know, perhaps even beyond the real estate transaction paradigm. So what do you see as far as scale in the future?

Andrew Elster  37:33

Sure. Yeah. You know, initially, and currently, we’re hosting things on Heroku, just because the nice thing about Heroku is, it’s your DevOps and your infrastructure team, you know, you pay for it, but it solves a lot of problems for you. But there’s also a little less flexibility when it comes to some architectural things and performance things. So we’re actually looking at possibly, you know, launching this new thing on AWS directly and using Terraform to automate all of the infrastructure setup. So our infrastructure will be in code and you know, Terraform and set that all up. And we’ll probably leverage other tools in the AWS ecosystem on like their hosted Kubernetes service. There’s things that we can do by just moving directly to AWS that’ll help us anticipate larger scale. Currently, we move about 10 million a month in money. And with the enterprise contracts, plus the consumer stuff that is coming up, you know, we’re  anticipating next year, you know, moving 450,000,000 in 2021, which, you know …

Eric Dodds  38:58

Wow!

Andrew Elster  38:58

There’s a whole lot, but you know, there’s a lot of API calls and events and things pinging around in the system to support that. And if things got really crazy, you had proposed the question, you know, what would our wildest dream be? I’m trying to think if we escaped the real estate industry and expanded into every conceivable payment scenario, maybe we’d be looking in, you know, the order of hundreds of transactions a second. And this is what’s interesting is unlike a data stream intensive process, like if you were doing video processing or something like that, where you’re just really dealing with an enormous amount of data continuously. We’re really just looking at lots of web requests, lots of web hooks and things and so our current setup is actually already positioned pretty well to handle that. That’s what’s nice about Elixir and Phoenix, we can support, you know, a great deal of, you know, request load coming in pretty handily, it scales very well vertically as it scales very well horizontally. And so our biggest concern is actually not the performance at scale, really, what we’re putting our focus into, is trading off a little bit of that performance, and providing more high availability. And the issues that we really have to take into account are all the different failure scenarios. So in payments, I gotta tell you, there are so many sad pads, there’s just so many ways it can break down. And so the biggest challenge is not so much the raw data because the raw data itself is actually fairly small. And it doesn’t really come in quantities that would, you know, scare anybody. But the amount of interaction with third-party systems and the different ways things can break down or degrade, that’s really where our focus has to be is on building a system that’s highly available, and very fault tolerant and robust. So that’s really where the challenge lies.

Eric Dodds  41:26

Fascinating. Yeah, I mean, just thinking about, you know, sort of 3-4x growth next year. A, congratulations, that’s, that’s incredible, you know, for your company, but to have a system that you’re already confident can process that scale. You know, of course, with some, you know, sort of infrastructural changes as far as hosting and everything. That’s really neat. And that’s pretty cool and a neat position to have confidence in the system that it can handle through that order of magnitude and growth.

Andrew Elster  42:04

Yeah, I’m really excited. It’s going to be a fun trip.

Eric Dodds  42:08

Yeah, very cool. Well, we want to be respectful of your time, we really appreciate you taking the time to chat with us and we really enjoyed learning about the way that the product has evolved and then the way that you’re responding to that. Very interesting stuff, and we wish you the best of luck.

Andrew Elster  42:26

Thank you so much. Thanks for having me on.

Eric Dodds  42:28

Absolutely.

Kostas Pardalis  42:30

Thank you, Andrew, it was a great pleasure chatting with you today.

Andrew Elster  42:33

Likewise.

Eric Dodds  42:35

Another really interesting conversation, one of my biggest takeaways was that I learned that you have a background in electrical engineering Kostas, which is fascinating to me. And amazing that Andrew had the same thing. And I think the other thing … we talked about a lot of interesting things, but I think the other reminder, for me, that isn’t even necessarily related to the tech stack or data but that’s just such a good reminder for anyone working on products is that the complexities and things they’re building now really emerged out of sort of a process of iteration and meeting different needs for their customers. They started really small with a small use case, and learned along the way. And it’s just such a good reminder that, from a technical standpoint, we could think of all these things that we need to build or could build or that might be cool. But ultimately, following feedback from our users in the market on solving real problems is really the point of building a product. What stuck out to you?

Kostas Pardalis  43:36

Well, first of all, I think Andrew has a much more interesting experience with electrical engineering to be honest. He also, I mean, exercised the profession. My background is electrical and computer engineering. So, I went through standard electrical engineering, but I never practiced it, because I was always more interested in computer engineering. But anyway, probably we should have another episode with you discussing more in depth about his experiences in electrical engineering and computer engineering in general. I think it would be an interesting episode. And there’s also a bit of interesting relations around history and technology. But anyway, what I found super, super interesting is the way that they perceive and they work with data. So as you remember, I said that I would like to know how they can implement this kind of agility that the startup needs. And this whole model of capturing the changes of data and maintaining an immutable stream of all the changes on the data model, and then being able to build on top of whatever data structures they want by replaying the whole history. It’s something that it’s quite similar also to what CDC is, I mean, CDC can also be used in a way to support this kind of use cases. So for me, it was very again, surprising in a good way, where actually we are talking about patterns around data engineering that are so common and we see like the beauty of also the abstraction that computer science and computer engineering provides like the same kind of patterns, they can be used on a different scale of problems and still be beneficial as long as you implement them the right way for each use case. So that was very, very interesting for me. And I’m looking forward to chatting with Andrew and the rest of the team in the future and see what they will come up with. They are iterating really fast. They know the financial market very well and I think we have more to learn from them.

Eric Dodds  45:32

I agree. And we’ll catch up with them in a couple months once they get the event streaming engine live and see how it’s working. Until next time. Thanks for joining us on The Data Stack Show.