Meetup Architecture Principles
Our Goal: Empower Meetup engineers to build coherent, lasting architecture solutions.
Meetup has been around for fifteen years, but today we rolled out the first-ever Meetup Architecture Principles. In my fractional VPE role, I’ve been tasked with helping to develop a new process for architecture reviews. As I got ramped up, Yvette Pasqua (Meetup’s CTO) and I agreed that it’d be beneficial to have some principles listed as a foundation to the work.
This process from zero to Principles took five weeks. I’m excited to share how we got to this list, and what they are!
The Process
I organized and facilitated a five-week Architecture Principles Working Group, inviting a handful of individuals who met the following characteristics:
- Are able to distinguish between their personal preference, and what’s best for the larger organization
- Are experienced at influencing others without authority
- Are effective communicators (especially with those who have different perspectives than they do)
- Are subject matter experts on this topic
- Are diverse (tenure, demographic, discipline, etc.)
Each of these working group members were responsible for representing a different part of Meetup Engineering (Data Science, Quality, Web, Mobile, the executive team, etc.). Brian Gruber, Meetup’s Principal Architect, was tasked with representing all of Meetup Engineering.
For each of those five weeks, the working group representatives and I met for up to an hour to collaborate, and afterwards the reps went back to their group to gather feedback using Slack channels and group meetings. There was a lot of Google Doc commenting and suggesting, a lot of great discussion, and a lot of asynchronous movement forward. Here was the arc of those five weeks:
I’m proud to say that Brian presented the following Architecture Principles doc, which contains lots of context about each and how to use the list, to the Engineering team yesterday:
Meetup Architecture Principles
How do we use these?
These principles are intended to help you evaluate engineering solutions to problems. Therefore, before you can apply them to your project, you have to be able to answer the question “What problem am I trying to solve?”
Once you know that, ask yourself questions like:
- Have I evaluated each of these principles in this architecture?
- What aspects of these principles am I actively prioritizing? Why?
- Why are the other aspects of these principles not a priority in this context?
Build for Change
Meetup’s engineering team and platform will scale. The demands of our members (we call our users members) will change, and our understanding of the needs of our members will evolve. The systems we build will need to either adapt to change or be replaced.
Systems built for change:
- … are easily replaced or extended
- … gracefully handle changes in the systems they interact with (robustness principle)
- … scale without an increase to operational overhead (people or processes)
- … are observable, so that we’re aware of when they’re not meeting our needs and the needs of our members, and need to be changed
What doesn’t this principle mean?
- It doesn’t mean it’s fine to make abrupt changes without consideration of consumer effects
- It doesn’t mean don’t think ahead, but neither should you build the most general, flexible, scalable system that will solve the problem; part of building for change means accepting that you don’t know on what axis change will be required.
Build for Understanding
Building a compelling product means integrating with other systems, and doing so effectively means understanding those systems. Do you understand the systems that you’re integrating with? Will engineers who need to integrate with or maintain your new system in the future (including you!) be able to understand how it works, and what the limits of this system are?
Seek to compose systems out of small, easy-to-understand components. Make their presence, intent, and how they fit together, discoverable. This likely means a combination of:
- Reusing common toolsets and patterns
- Well-structured code
- Builds, deployments, resource provisioning (e.g. databases, server instances, etc.) specified as artifacts in the code repository (infrastructure-as-code)
- Tests
- Documentation
- Code comments
- Instrumentation
What doesn’t this principle mean?
- This doesn’t mean “Make it as small as possible.” Instead, adequately separate the concerns.
- This doesn’t mean every code module of every component of every system needs exhaustive documentation before it can be released (or after)
- This doesn’t mean you need to ensure 100% test coverage
Build Meetup
The decisions we make in designing our systems should reflect the problem being solved. Some teams solve problems for our members, while others solve problems for other engineers, but all of us should be focused on solving problems pertinent to making Meetup.
What doesn’t this principle mean?
- This doesn’t mean challenge the validity of the problem being solved.
- This doesn’t mean we only solve Meetup-specific problems. We tackle problems where the lack of a solution, or a solution more suited to our needs, is significantly slowing us down.
What’s next?
Obviously, this isn’t the end of our work on architecture decision making! Now that we’ve shipped the list, the Architecture Principles Working Group has dissolved. Next, Brian and I will collaborate on building an inclusive and sustainable Architecture Review process for Meetup. More to come!
