Learn How to Scale Your Startup with this Educational Series
January 13, 2021
As a startup, you're probably interested in spending more time on shipping features than managing your database.
Upskill in the new year with Scaling Your Startup with MongoDB Atlas: A Series.
Join us for a three-part educational monthly webinar series kicking off January 26, completely focused on how to do less with more.
The last Tuesday of every month, January through March, at 9 am PT/noon ET
Our technical experts will take you through NoSQL, the MongoDB Query Language, MongoDB Atlas (our global cloud database service), and show you how to take the heavy lifting out of database management.
- Why NoSQL for Startups | Lauren Schaefer | January 26
- Scale Your Startup with MongoDB Atlas | Mike Lynn | February 23
- Reaching Scalability with MongoDB Atlas | Adrienne Tacke | March 30
Who should attend?
Attend if you are a MongoDB beginner, in need of a technical refresher, building a product or service, or part of a startup.
Will it be recorded?
Of course. Each webinar will be recorded and posted to the website for you to watch anytime, at your convenience.
Just check out the takeaways below. Plus at the end of each presentation, you’ll have time to submit queries for Q&A with the technical expert.
Key takeaways will include:
- Mapping terms & concepts from tables to documents
- Discovering the 4 major advantages of documents for your startup
- Changing your mindset in 3 key ways
- Deploying a free tier cluster
- Adding users & managing user access
- Connecting to MongoDB Compass, the GUI for MongoDB
- What's Realm?
- Third-party integration
- What is and why Multi-Cloud?
- How to set-up Multi-Cloud Cluster
And much more!
Meet Kaitlin Mahar: How MongoDB’s Database Experience Team Makes It Easier for Developers to Innovate
MongoDB is committed to helping both our customers and the tech community innovate quickly. I recently sat down with Kaitlin Mahar, Lead Engineer, to learn more about the Database Experience team, how she grew her career at MongoDB, and what her team does to positively impact the open source community. Ashley Perez: What is the Database Experience team, and how does it help MongoDB customers? Kaitlin Mahar: The Database Experience team, or DBX for short, builds the programming language-specific client libraries — which we refer to as “drivers” — for MongoDB. Drivers are just as essential to using MongoDB as the database itself. Without a driver, you can't actually connect to the database from your application. Our team prioritizes building drivers that we call “idiomatic” for the programming language and ecosystem in which they’re used. A MongoDB driver should follow language best practices, “feel” like other libraries you’ve used in the same language, and integrate easily with popular frameworks in that language. This makes it easy for our customers and community to get started and ramped up on our drivers. Given that anyone using MongoDB has to use a driver too, our team works with just about every type of customer and use case. Our drivers are fully open source and completely free to use, so many of our users are language community members and not customers at all. In fact, my first introduction to MongoDB was using the community version along with the Node.js driver to build a web application for a college class. In addition to drivers, we also develop libraries to integrate MongoDB with popular frameworks and developer tools, and make contributions to the open source libraries our libraries depend upon. What’s interesting about this team is that we’re constantly innovating. We develop drivers for new and upcoming programming languages. For example, we just released new drivers for Swift and Rust last year. And we have to keep up to date on the latest trends, technologies, and best practices in our respective programming languages to incorporate into our work. We’re always learning. AP: What’s your role on the team? KM: I’m one of four Lead Engineers on the team. Each of us oversees two or three drivers; I manage the Node.js, Swift, and Rust drivers . My day-to-day is a mix of technical work and managerial work. On the technical side, I work on my own technical projects, which includes coding, writing designs, and so on. I also review the technical work of people I manage. On the management side, I work with our Product Manager and Director to decide which work our team should prioritize and decide which team member(s) should take on what work. Depending on the scope of work, I also coordinate with other departments if needed. However, I think my most important job as a manager is supporting my direct reports by enabling them to do their best work and providing them with opportunities to accomplish both short- and long-term goals so they can grow as engineers. AP: You joined MongoDB as an intern and participated in the rotation program. When selecting a full-time role, why did you choose the Database Experience team? KM: I started at MongoDB as a summer intern, and then came back as a new grad and went through the new grad rotation program, which is sort of like three more mini-internships for six weeks each. This program allowed me to learn about the range of technical problems people work on at MongoDB while trying out a variety of team cultures and work styles to see what I liked best. One of my rotations was on the DBX team. When I rotated, I worked on a major revamp of the Node.js driver’s BSON library. This was a high-impact, user-facing project that I was surprised to be entrusted with as a new grad, and I found I really enjoyed the experience. The chance to have a high level of ownership over what I worked on was motivating. Due to the structure of the department, where small teams of two to four engineers work on each language project, there is a lot of opportunity for ownership on the team, even as a new grad. At the time of the rotation program, I had discussed returning to the team with my mentor, Matt — who later became my manager — and learned there was an opportunity for me to work with him on a brand-new driver written in Swift. I was excited about the prospect of seeing how a new driver is built and learning a new language, so DBX seemed like a natural choice. The DBX team gets to think about a wide range of technical problems, ranging from API design to networking to distributed systems. The variety of areas I’d get to work in and learn about on the team was a huge factor in why I decided to pursue this. I also knew there was a lot of opportunity on the team to get involved with open source communities by attending and speaking at conferences, engaging with users, and contributing to open source libraries, all of which I was interested in doing. AP: It turns out you took the chance to work with the community and are doing interesting work. Can you share more about that? KM: I’m a member of the Swift Server Work Group (SSWG), a steering team that promotes the use of Swift for developing and deploying server applications. This is a committee composed of representatives from a few different companies, such as Amazon, Apple, and MongoDB, as well as representatives from a popular open source Swift web framework, Vapor. Our focus is guiding the development of a healthy and robust server-side Swift ecosystem. Since Swift is a fairly new language and the use of Swift on the server is even newer, it’s really exciting to be a part of. There are a lot of important foundational open source libraries being developed and conversations happening about what we want the ecosystem to look like. One set of those foundational server-side Swift libraries being developed is database drivers, such as our Swift driver for MongoDB. I originally got involved with the SSWG by pitching our driver to go through the SSWG’s incubation process. It’s an honor to be a part of the group, and so far it has been a great way to connect with people outside the company, contribute to open source, and keep up to date on the latest developments in the ecosystem. AP: That sounds like a great group that not only helps impact the community, but also allows you to grow as an engineer. How else have you grown professionally and personally at MongoDB? KM: Once I joined the DBX team full time, I started working on the Swift driver. Over the next few years, I got promoted and eventually became a Senior Engineer. My manager, Matt, gradually handed me more responsibility for the project, such as making big technical decisions, providing input on what we should work on next, presenting what work we plan to do to the CTO and VPs at quarterly planning meetings, and representing the company at Swift conferences. I also had a lot of opportunities to mentor new grads and interns, overseeing their work and developing management skills that are now very important to me as a Lead Engineer. Once I had gotten experience in both technical leadership and leading people, I was promoted to be a Lead Engineer, responsible for both the Swift and Rust drivers and the engineers who work on them. I recently took on managing the Node.js driver as well, which is one of our most popular drivers and is much older than the Rust and Swift Drivers, so it has been an interesting new challenge for me. In terms of personal growth, one of the biggest ways I’ve changed is in my willingness to admit what I don’t know and proactively ask questions, even if they seem simple. I’ve realized that being a good engineer is less about what you know exactly, and more about how you approach solving problems and finding the answers. AP: Well said. How does your team collaborate? KM: Our team was quite distributed even before the pandemic began. Whereas about half of us usually work out of the New York office, my manager is in the San Francisco Bay Area, and two of the other Lead Engineers are located in Boston and Munich. Our Product Manager is in North Carolina, and we have team members scattered around the United States and other countries as well. Effective digital collaboration is essential for getting things done, since we don’t physically sit in the same location or work the same hours. In our day-to-day, we use a number of tools to accomplish this, including Slack, GitHub, Zoom, and Google Docs. Because we’re all solving the same problems, just in different programming languages, it’s beneficial for us to share knowledge with each other, both within our individual language teams and also across the department as a whole. For language-specific projects, we use a collaborative design process, where one individual writes up a proposed design and the rest of the team reviews it and provides feedback to improve the design. In regards to cross-driver projects, the DBX team writes shared specifications for how MongoDB drivers in all languages should work. These cover everything from high-level driver APIs (e.g., CRUD) down to low-level behavior such as connection pooling. These are collaborations between individuals who work on different language teams so we can ensure the specifications will work for drivers written in any programming language. We also often need to work with the Server team. For example, if the server adds a new feature such as transactions, the drivers also need to add APIs to support using that feature. Therefore, we frequently review server scope and design documents, and vice versa. What’s cool is that many of the other MongoDB teams use our drivers. For instance, the Cloud team uses both the Go and Java drivers, Atlas Data Lake uses the Go driver, MongoDB Compass and the new MongoDB shell (mongosh) use the Node.js driver, and Realm uses the Node.js BSON library. We coordinate with those teams to add new features, make changes, and act as necessary support for their use cases. They often make contributions directly to our drivers too. AP: What skills are important for someone to be successful on this team? KM: We are highly collaborative and do a lot of technical writing for our design and specification process, so team members should be strong written and verbal communicators. Since our team’s first and foremost purpose is making it easy to use MongoDB from any programming language, it’s also important that our team members have the ability to empathize with our users. They should have the ability to make pragmatic technical decisions too. As library developers, we have to make a lot of difficult choices — such as what features to include in our APIs — and balance trade-offs such as usability and maintainability. I also mentioned ownership as being a key component of working on our team, and something that attracted me to it: engineers on our team need to be ready to own the driver and projects they work on and live out MongoDB’s core value “own what you do.” AP: After working at MongoDB for four years, why do you stay? And why would someone be excited to join the team? KM: The strong mentorship and the established new grad program was a great way to launch my career, and I’ve seen many others experience the same thing. About three-quarters of the people in my new grad class are still at the company! In general, there are so many growth opportunities here that there’s no shortage of places where you can take your career at MongoDB, and we have both individual-contributor and people-management tracks, depending on your interests. The company has a wide variety of technical topics to work on, ranging from UI design all the way down to low-level C code, so it’s hard to get bored here. Even for more seasoned technologists, the opportunity to engage with the open source community through your work allows you to become an expert or deepen your expertise in your primary language, while learning more about other programming languages. You get to understand how a distributed database and database driver operates by working on a range of problems involving API design, concurrency and parallelism, distributed systems, and performance. You’ll constantly be learning new things here. From a general perspective, I personally love the company size. It’s big enough to have a good amount of structure and rigorous technical processes, but it’s still small enough that you can make an impact and get recognized as an individual. The flexible working arrangements are great too. Even before the COVID-19 pandemic, we had flexible hours, work-from-home options, and flexible time off. The people here are great — very smart, but down to earth and open to collaboration. It makes working at MongoDB really enjoyable. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe, and would love for you to build your career with us!
How Edenlab Built a High-Load, Low-Code FHIR Server to Deliver Healthcare for 40 Million Plus Patients
The Kodjin FHIR server has speed and scale in its DNA. Edenlab, the Ukrainian company behind Kodjin , built our original FHIR solution to digitize and service the entire Ukrainian national health system. The learnings and technologies from that project informed our development of the Kodjin FHIR server. At Edenlab, we have always been driven by our passion for building solutions that excel in speed and scale. With Kodjin, we have embraced a modern tech stack to deliver unparalleled performance that can handle the demands of large-scale healthcare systems, providing efficient data management and seamless interoperability. Eugene Yesakov, Solution Architect, Author of Kodjin Built for speed and scale While most healthcare projects involve handling large volumes of data, including patient records, medical images, and sensor data, the Kodjin FHIR server is based on a system developed to handle tens of millions of patient records and thousands of requests per second, to ensure timely access and efficient decision-making for a population of over 40 million people. And all of this information had to be processed and exchanged in real-time or near real-time, without delays or bottlenecks. This article will explore some of the architectural decisions the Edenlab team took when building Kodjin, specifically the role MongoDB played in enhancing performance and ensuring scalability. We will examine the benefits of leveraging MongoDB's scalability, flexibility, and robust querying capabilities, as well as its ability to handle the increasing velocity and volume of healthcare data without compromising performance. About Kodjin FHIR server Kodjin is an ONC-certified and HIPAA-compliant FHIR Server that offers hassle-free healthcare data management. It has been designed to meet the growing demands of healthcare projects, allowing for the efficient handling of increasing data volumes and concurrent requests. Its architecture, built on a horizontally scalable microservices approach, utilizes cutting-edge technologies such as the Rust programming language, MongoDB, ElasticSearch, Kafka, and Kubernetes. These technologies enable Kodjin to provide users with a low-code approach while harnessing the full potential of the FHIR specification. A deeper dive into the architecture approach - the role of MongoDB in Kodjin When deciding on the technology stack for the Kodjin FHIR Server, the Edenlab team knew that a document database would be required to serve as a transactional data store. In an FHIR Server, a transactional data store ensures that data operations occur in an atomic and consistent manner, allowing for the integrity and reliability of the data. Document databases are well-suited for this purpose as they provide a flexible schema and allow for storing complex data structures, such as those found in FHIR data. FHIR resources are represented in a hierarchical structure and can be quite intricate, with nested elements and relationships. Document databases, like MongoDB, excel at handling such complex and hierarchical data structures, making them an ideal choice for storing FHIR data. In addition to supporting document storage, the Edenlab team needed the chosen database to provide transactional capabilities for FHIR data operations. FHIR transactions, which encompass a set of related data operations that should either succeed or fail as a whole, are essential for maintaining data consistency and integrity. They can also be used to roll back changes if any part of the transaction fails. MongoDB provides support for multi-document transactions , enabling atomic operations across multiple documents within a single transaction. This aligns well with the transactional requirements of FHIR data and ensures data consistency in Kodjin. Implementation of GridFS as a storage for the terminologies in Terminology service Terminology service plays a vital role in FHIR projects, requiring a reliable and efficient storage solution for terminologies used. Kodjin employs GridFS , a file system within MongoDB designed for storing large files, which makes it ideal to handle terminologies. GridFS offers a convenient way to store and manage terminology files, ensuring easy accessibility and seamless integration within the FHIR ecosystem. By utilizing MongoDB's GridFS, Kodjin ensures efficient storage and retrieval of terminologies, enhancing the overall functionality of the terminology service. Kodjin FHIR server performance To evaluate the efficiency and responsiveness of the Kodjin FHIR server in various scenarios we conducted multiple performance tests using Locust, an open-source load testing tool. One of the performance metrics measured was the retrieval of resources by their unique ids using the GET by ID operation. Kodjin with MongoDB achieved a performance of 1721.8 requests per second (RPS) for this operation. This indicates that the server can efficiently retrieve specific resources, enabling quick access to desired data. The search operation, which involves querying ElasticSearch to obtain the ids of the searched resources and retrieving them from MongoDB, exhibited a performance of 1896.4 RPS. This highlights the effectiveness of polyglot persistence in Kodjin, leveraging ElasticSearch for fast and efficient search queries and MongoDB for resource retrieval. The system demonstrated its ability to process search queries and retrieve relevant results promptly. In terms of resource creation, Kodjin with MongoDB showed a performance of 1405.6 RPS for POST resource operations. This signifies that the system can effectively handle numerous resource-creation requests. The efficient processing and insertion of new resources into the MongoDB database ensure seamless data persistence and scalability. Overall, the performance tests confirm that Kodjin with MongoDB delivers efficient and responsive performance across various FHIR operations. The high RPS values obtained demonstrate the system's capability to handle significant workloads and provide timely access to resources through GET by ID, search, and POST operations. Conclusion Kodjin leverages a modern tech stack including Rust, Kafka, and Kubernetes to deliver the highest levels of performance. At the heart of Kodjin is MongoDB, which serves as a transactional data store. MongoDB's capabilities, such as multi-document transactions and flexible schema, ensure the integrity and consistency of FHIR data operations. The utilization of GridFS within MongoDB ensures efficient storage and retrieval of terminologies, optimizing the functionality of the Terminology service. To experience the power and potential of the Kodjin FHIR server firsthand, we invite you to contact the Edenlab team for a demo. For more information On MongoDB’s work in healthcare, and to understand why the world’s largest healthcare companies trust MongoDB, read our whitepaper on radical interoperability .