Employee Profile: Brendan Coleman

MongoDB
October 31, 2013 | Updated: May 22, 2015
#Company

We’re excited to introduce members of our fantastic MongoDB team in a new series featuring an employee of the week on our blog. Structured in a Q&A format, the employees will share how they came to MongoDB, their role at the company and a few light-hearted questions about what they do when they’re not in our offices.

Our first featured employee is Brendan Coleman, Director of Business Development.

Brendan with his son Harvey

What is your role at MongoDB? What department do you work in?

I’ve been part of the Business Development team for over two years, specifically working with various types of partners that are integrating MongoDB into their value proposition.

**Where were you before MongoDB? **

I worked at Alfresco, which is an Open Source Enterprise Content Management Company.

What’s your hometown?

I currently live in Atlanta, GA but Pittsburgh, PA [The Burgh] will always be my home.

Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? If not, how did you learn MongoDB and how was the education process

MongoDB started coming up in conversations here [at Alfresco] and there before I jumped ship, but I mostly started from scratch. There was a lot of self-education, a few patient colleagues and a week of technical training. At that time, the education was at a stage where you learned as you went and picked up things by communicating with customers. On-boarding has improved significantly over the past couple years but you still have all departments pitching in, which is great.

Have you had any personal projects where you’ve used MongoDB?

Does elevating my monitor with various MongoDB books count?

Bike or public transportation to work?

Neither. I work from home when I’m not on the road. My daily commute consists of walking to the next room or roller blading to the local coffee shop.

What’s a typical day (or week) for you?

I start each day with an episode of Sit and Be Fit; helps me maintain my figure.

Since Business Development allows me to work with all parts of the organization, things are interesting and every day brings something new.

Why did you choose to come to MongoDB? What do you love most about MongoDB?

With the risk of sounding cliché, I chose MongoDB because of the opportunity to disrupt the database market. It made no sense to me (at the time and now) why people continued to use and accept a tool that didn’t address the evolving requirements of the business.

One thing that still excites me about MongoDB is the quality of people I work with and whom we continue to hire as we expand our team. It’s challenging to stay disciplined when it comes to hiring at scale and it’s very cool to be on the positive side of it all.

And the swag’s not too bad either.

What’s the most challenging project here at MongoDB that you’ve worked on, and how did you succeed?

Explaining what I do and what MongoDB is to my Dad. He has the basic concept down and rocks the t-shirt so I’d call that a victory.

What’s the most rewarding experience you’ve had working here so far?

Working with the various people across MongoDB has been a very interesting and rewarding process over the past couple years. Taking a step back and seeing what we’ve accomplished in a short amount of time is very cool.

What’s your favorite Seamless lunch order?

I always miss the deadline to order.

Name one secret skill you have, unrelated to work.

I can juggle.

Kindle or book? What’s your favorite book?

Book: I like to keep them scattered throughout my apartment to break awkward silences at social gatherings. My favorite is Islands in the Stream, by Hemingway.

If you were a Major League baseball player what song would they play when you step up to bat?

Old School: Beastie Boys – sure shot
New School: Lorde – Royals

Describe your perfect weekend.

A perfect weekend would include zero obligations and time outdoors with the people that make me happy. Oh - and some time to work on the base tan.

← Previous

Schema Design for Social Inboxes in MongoDB

Designing a schema is a critical part of any application. Like most databases, there are many options for modeling data in MongoDB, and it is important to incorporate the functional requirements and performance goals for your application when determining the best design. In this post, we’ll explore three approaches for using MongoDB when creating social inboxes or message timelines. If you’re building a social network, like Twitter for example, you need to design a schema that is efficient for users viewing their inbox, as well as users sending messages to all their followers. The whole point of social media, after all, is that you can connect in real time. There are several design considerations for this kind of application: The application needs to support a potentially large volume of reads and writes. Reads and writes are not uniformly distributed across users. Some users post much more frequently than others, and some users have many, many more followers than others. The application must provide a user experience that is instantaneous. Edit 11/6: The application will have little to no user deletions of data (a follow up blog post will include information about user deletions and historical data) Because we are designing an application that needs to support a large volume of reads and writes we will be using a sharded collection for the messages. All three designs include the concept of “fan out,” which refers to distributing the work across the shards in parallel: Fan out on Read Fan out on Write Fan out on Write with Buckets Each approach presents trade-offs, and you should use the design that is best for your application’s requirements. The first design you might consider is called Fan Out on Read. When a user sends a message, it is simply saved to the inbox collection. When any user views their own inbox, the application queries for all messages that include the user as a recipient. The messages are returned in descending date order so that users can see the most recent messages. //Shard on "from" db.shardCollection( "mongodbdays.inbox", {from: 1}) //Make sure we have an inbox to handle inbox reads db.inbox.ensureIndex( {to: 1, sent: 1}) msg = { from: "Joe" to: ["Bob", "Jane"], sent: new Date(), message: "Hi!", } //Send a message db.inbox.save (msg) //Read Bob's inbox db.inbox.find ({ to: "Bob"}).sort({sent:-1}) To implement this design, create a sharded collection called inbox , specifying the from field as the shard key, which represents the address sending the message. You can then add a compound index on the to field and the sent field. Once the document is saved into the inbox, the message is effectively sent to all the recipients. With this approach sending messages is very efficient. Viewing an inbox, on the other hand, is less efficient. When a user views their inbox the application issues a find command based on the to field, sorted by sent. Because the inbox collection uses from as its shard key, messages are grouped by sender across the shards. In MongoDB queries that are not based on the shard key will be routed to all shards. Therefore, each inbox view will be routed to all shards in the system. As the system scales and many users go to view their inbox, all queries will be routed to all shards. This design does not scale as well as each query being routed to a single shard. With the “Fan Out on Read” method, sending a message is very efficient, but viewing the inbox is less efficient. Fan out on Read is very efficient for sending messages, but less efficient for reading messages. If the majority of your application consists of users sending messages, but very few go to read what anyone sends them – let’s call it an anti-social app – then this design might work well. However, for most social apps there are more requests by users to view their inbox than there are to send messages. The Fan out on Write takes a different approach that is more optimized for viewing inboxes. This time, instead of sharding our inbox collection on the sender, we shard on the message recipient. In this way, when we go to view an inbox the queries can be routed to a single shard, which will scale very well. Our message document is the same, but now save a copy of the message for every recipient. //Shard on "recipient" and "sent" db.shardCollection("mongodbdays.inbox", {"recipient": 1, "sent":1}) msg = { from: "Joe", to: ["Bob", "Jane"] sent: new Date() message: "Hi!", } //Send a message for (recipient in msg.to){ msg.recipient = msg.to[recipient] db.inbox.insert(msg); } //Read Bob's inbox db.inbox.find ({recipient: "Bob"}).sort({ sent:-1}) With the “Fan Out on Write” method, viewing the inbox is efficient, but sending messages consumes more resources. In practice we might implement the saving of messages asynchronously. Imagine two celebrities quickly exchange messages at a high-profile event - the system could quickly be saturated with millions of writes. By saving a first copy of their message, then using a pool of background workers to write copies to all followers, we can ensure the two celebrities can exchange messages quickly, and that followers will soon have their own copies. Furthermore, we could maintain a last-viewed date on the user document to ensure they have accessed the system recently - zombie accounts probably shouldn’t get a copy of the message, and for users that haven’t accessed their account recently we could always resort to our first design - Fan out on Read - to repopulate their inbox. Subsequent requests would then be fast again. At this point we have improved the design for viewing inboxes by routing each inbox view to a single shard. However, each message in the user’s inbox will produce a random read operation. If each inbox view produces 50 random reads, then it only takes a relatively modest number of concurrent users to potentially saturate the disks. Fortunately we can take advantage of the document data model to further optimize this design to be even more efficient. Fan out on Write with Buckets refines the Fan Out on Write design by “bucketing” messages together into documents of 50 messages ordered by time. When a user views their inbox the request can be fulfilled by reading just a few documents of 50 messages each instead of performing many random reads. Because read time is dominated by seek time, reducing the number of seeks can provide a major performance improvement to the application. Another advantage to this approach is that there are fewer index entries. To implement this design we create two collections, an inbox collection and a user collection. The inbox collection uses two fields for the shard key, owner and sequence , which holds the owner’s user id and sequence number (i.e. the id of 50-message “bucket” documents in their inbox). The user collection contains simple user documents for tracking the total number of messages in their inbox. Since we will probably need to show the total number of messages for a user in a variety of places in our application, this is a nice place to maintain the count instead of calculating for each request. Our message document is the same as in the prior examples. //Shard on "owner/sequence" db.shardCollection("mongodbdays.inbox", {owner: 1, sequence: 1}) db.shardCollection("mongodbdays.users", {user_name: 1}) msg={ from: "Joe", to: ["Bob", "Jane"], sent: new Date () message: "Hi!", } //Send a message for(recipient in msg.to) { count = db.users.findAndModify({ query: {user_name: msg.to[recipient]}, update:{"$inc":{"msg_count":1}}, upsert: true, new: true}).msg_count; sequence = Math.floor(count/50); db.inbox.update({ owner: msg.to[recipient], sequence: sequence}, {$push:{"messages":msg}}, {upsert: true}); } //Read Bob's inbox db.inbox.find ({owner: "Bob"}) .sort({sequence:-1}).limit(2) To send a message we iterate through the list of recipients as we did in the Fan out on Write example, but we also take another step to increment the count of total messages in the inbox of the recipient, which is maintained on the user document. Once we know the count of messages, we know the “bucket” in which to add the latest message. As these messages reach the 50 item threshold, the sequence number increments and we begin to add messages to the next “bucket” document. The most recent messages will always be in the “bucket” document with the highest sequence number. Viewing the most recent 50 messages for a user’s inbox is at most two reads; viewing the most recent 100 messages is at most three reads. Normally a user’s entire inbox will exist on a single shard. However, it is possible that a few user inboxes could be spread across two shards. Because our application will probably page through a user’s inbox, it is still likely that every query for these few users will be routed to a single shard. Fan out on Write with Buckets is generally the most scalable approach of the these three designs for social inbox applications. Every design presents different trade-offs. In this case viewing a user’s inbox is very efficient, but writes are somewhat more complex, and more disk space is consumed. For many applications these are the right trade-offs to make. Schema design is one of the most important optimizations you can make for your application. We have a number of additional resources available on schema design if you are interested in learning more: Fan out on Read Fan out on Write Fan out on Write with Buckets Send Message Performance Best Single write Good Shard per recipient Multiple writes Worst Shard per recipient Appends (grows) Read Inbox Performance Worst Broadcast all shards Random reads Good Single shard Random reads Best Single shard Single read Data Size Best Message stored once Worst Copy per recipient Worst Copy per recipient Schema design is one of the most important optimizations you can make for your application. We have a number of additional resources available on schema design if you are interested in learning more: Check out the recording of our recent Schema Design webinar on this topic. Schema Design in general in the MongoDB Manual You can also view our schema design resources on the MongoDB docs page If you have any schema design questions, please view the archived questions on our user forum or ask a question yourself on the MongoDB User Forum.

October 31, 2013

Next →

Women Leaders at MongoDB: Lena Smart Discusses Clarity and Goal Setting

March is Women’s History Month. Our women leaders series highlights MongoDB women who are leading teams and empowering others to own their career development and build together. Lena Smart, Chief Information Security Officer, explains why words matter, shares her thoughts on leadership, and discusses MongoDB’s internal mentorship program “MentorHER”. Tell me a bit about your team. My team is responsible for all aspects of security of MongoDB’s global offices and employees. Within my organization I have Governance, Risk and Compliance (GRC) and InfoSec (security engineering, physical security, etc.) under me. We are dedicated to making every effort to protect customer data, including continually improving security processes and controls. On top of that, we are committed to delivering the highest levels of standards conformance and regulatory compliance as part of our ongoing mission to address the most demanding security and privacy requirements of our customers. My goal is to build the best security and GRC team in the world. What characteristics make a good leader? In my opinion, good leaders are decisive and leave little room for ambiguity. They are understanding and know that people are depending on them for their careers, dreams, and aspirations. They make their work matter every day, are focused on continuous learning, and do not “rest on their laurels.” What has your experience been like as a woman growing your career in leadership? My experience as a woman leader has depended on the environment. It was very difficult as a CIO and CISO in the power industry. Every day I felt like I was being undermined by my peers, who (because they were all “power industry engineers”) felt they were the experts in everything to do with security (they were not). It was exhausting. I finally left and joined a FinTech company. That was better, but I still felt I could find an environment where women were actively encouraged to lead. Hence my move to MongoDB. I could not be happier here and love working with all our teams. Tell us about the biggest lesson you’ve learned throughout your career. The biggest lesson I’ve learned is that words matter. As a leader, people can interpret your words in many ways. Be clear in your message. I have a mantra on our team: “one voice, one message”. I encourage my team members to have all the internal discussion they want, but we do not ever air our dirty laundry in public. We stand with “one voice, one message”. People in general like clarity, and we try hard to enforce that idea within my team by encouraging each person to own what they do. What’s your advice for building and developing a team? I believe cultivating a supportive and positive team culture stems from the top down. I really embrace and follow MongoDB’s company values . Build Together is the main value I follow because, to me, people are everything. You need the right people in the right places owning what they do. I am also a huge advocate for people taking the initiative and building upon their own careers. I make sure to set aside a budget for training and certification programs for my team. This allows them to enhance their knowledge and helps them grow and develop into even stronger security and GRC professionals. I also started the Security Champions Program at MongoDB almost four years ago, a volunteer-based program that allows anyone who has an interest in security to join monthly meetings to learn more. Can you tell us a bit about the MentorHER program at MongoDB? I am honored to be the Executive Sponsor for a very important internal program called MentorHER. MentorHER aims to create diverse teams, develop female leaders, drive organizational changes, and enhance MongoDB’s reputation as an employer of choice. I’ve had a couple of mentors who made a positive impact on my career. I cherished our time together and made sure to have a clear understanding of the mentoring program I signed up for. There were goals, regular meetings, and a lot of positivity generated by mentoring. I hope we can replicate that at MongoDB with our MentorHER program. We have a very strong team leading the program, and I feel very confident that we will meet our goals and embrace the different experiences and perspectives of the women around us. What is your advice to women looking to grow their careers as leaders? My advice to other women is this: be clear and honest in what you want from a leadership role. At the C-suite level you will be pulled in many directions. Control that, from the start, where possible. It’s important to be intellectually honest and have clear goals that will help your team grow and mature, and the business flourish. Join a team that builds together every day. View open career opportunities at MongoDB.

March 27, 2023