Key concepts of System design 2: Constraints
Self imposed or dictated by the situation, knowing your constraints is a must to design any system.
Welcome to the second installment of Key Concepts of System Design. Two weeks ago, we explored how to define problems effectively and gather requirements, establishing the foundation for any successful system design. Today, we'll build upon those fundamentals by diving into the next crucial step: analyzing constraints.
Let’s start shall we?
Overview
When designing an IT solution, constraints represent the limitations or boundaries that shape the system's architecture, technology choices, and implementation strategy. These constraints can be technical, such as infrastructure scalability or team expertise, or business-related, such as budget, time-to-market, and existing commitments to tools or vendors. Identifying constraints early is critical because it enables the team to:
- Make informed decisions: Understand trade-offs between cost, time, and performance.
- Avoid rework: Align choices with real-world limitations to prevent major changes later.
- Set realistic expectations: Clearly communicate what can be delivered under the given constraints.
In the ideal case like our Discord clone example in this series, we are working on a greenfield project, meaning we have the freedom to make technology and design decisions purely based on budget, performance requirements, and time constraints. We’re not bound to legacy systems, tools, or platforms, which provides flexibility but also requires careful evaluation of all options to optimize the design.
However, in real-world scenarios, many projects are brownfield: they involve existing systems, technologies, or vendor preferences that limit flexibility. For example:
- A customer may already use a specific cloud provider (e.g., Azure instead of AWS).
- The development team might be required to use Java EE due to internal policies, even if a lighter framework like Node.js might be beneficial.
- Legacy systems may force certain integrations that impact architectural choices.
Recognizing these constraints ensures that the solution is both feasible and aligned with the customer’s environment and goals. In our example, where we’re free from these limitations, the focus will be on balancing:
- Performance: Meeting low-latency and scalability goals.
- Budget: Staying cost-effective, especially during MVP development.
- Time: Delivering a functioning system quickly while planning for future growth.
- Team knowledge: How familiar is the team with the technology that we can use.
By systematically identifying and addressing constraints, we create a realistic foundation for designing robust, scalable, and maintainable systems—whether greenfield or brownfield.
In my career, I rarely had the possibility of working on a full greenfield project. I mostly worked in an established organization or for medium to large customers. There was always a technology stack in place that could not be replaced. The reasons were the most diverse, from team knowledge to budget or politics (like agreements with other providers) or simply because your boss was stubborn and afraid to change what he knew better. This makes the identification of the constraints even more important, with the final goal of finding the best combination of trade-offs that will make your solution successful.
Now let's put the concept to practice with our example.
The numbering starts from 3 because it is where we stopped in the previous article.
3.1 Technical Constraints
Technical constraints define the boundaries set by technology, tools, infrastructure, and the development team's capabilities. These will directly impact the system's design and implementation. As said before we don't have any frame constraint from a customer or an existing infrastructure so we can base or decisions on our preference and self imposed conditions only.
3.1.1 Deployment Model: Cloud vs. On-Premise
Cloud-hosted
Advantages: Scalability, cost-effectiveness, and managed infrastructure (e.g., AWS,Azure, GCP).
Challenges: Potential latency for global users and vendor lock-in.
On-Premise
Advantages: Greater control over data and infrastructure.
Challenges: High upfront costs and increased operational overhead.
Decision Point: Given the need for scalability and low upfront cost for a Discord clone, cloud deployment is the preferred option.
Justification: Cloud infrastructure allows us to leverage auto-scaling, managed services, and global CDNs to minimize latency and optimize costs.
3.1.2 Development Team Expertise
Technology Familiarity
Consider the team's experience with technologies like WebSockets for real-time communication, Kafka for event streaming, and programming languages (e.g., Javascript/TypeScript, Python, Go, or Java).
Remember: Limited expertise may increase development time and technical debt.
Decision: In this adventure I’m alone. I’m a Java guy so I could consider that Java is a language constraint for the backend since my familiarity will speedup the development process. For the frontend part I don’t have any specific advantage using any specific technology, so I leave the decision to the actual system design phase. If messaging and asynchronous events are needed I will go with Kafka because is the platform I have the most experience with.
In therm of technical constraint we are already over. There is not much more that can hinder progress in a greenfield project. We don’t have any pre existing component or piece of software in mind so we can leave the rest of the decision to the solution phase.
3.2 Business Constraints
Business constraints stem from non-technical limitations such as budget, timeline, and market dynamics. These constraints heavily influence the project's scope and priorities.
In our specific case we are trying to build a POC (prove of concept) that can be didactical and can also serve as a platform to develop new ideas.
3.2.1 Budget Limitations
Again I’m alone in this and without any funding (unless some reader is feeling particularly generous 🙂 ) so the budged effectiveness is key.
In order to keep this project as cheap as possible I have identified 2 main constraint that I want to impose to the project:
Stick to open source tools. Even if this mean more time to invest in development, configuring and customising the project don’t have budget to put into commercial software and tools.
Start with cost-effective cloud services with a pay-as-you-go model. I’m not a fan of “always cloud” but in the case of a prototype I think that not having to think much about infrastructure will give the project a considerable boost. Note: this could be also a topic for the technology familiarity. If the team you are working with is completely new to cloud infrastructure you need to consider the ramp up time and the impact on the time to market and budget.
3.2.2 MVP Launch Timeline
A strict deadline for the Minimum Viable Product (MVP) to validate the system in the market. The product development window will open after the end of this series on system design. We don’t have a real deadline that we need to respect as a constraint but it is in any case worth to mention it here because it is often the case.
A couple of points that can have an impact on defining your timeline:
Scope must be clearly defined, with core features prioritized. If you have an hard deadline you need to be sure what you are going to implement. Be honest with your customer and with yourself.
A short or tight deadline means development speed may take precedence over full optimization.
Asses the team skills properly. Do a confidence check on each of the main technology.
Hard deadline add complexity to the system design. This kind of constraint are like the quality goals: overarching. The can impact basically every part of your system design. From the choice of the platform to the actual component you want to implement.
You don’t hear much talk about timeline and deadline in the indie dev and solo preneur community because these kind of companies are rarely working for a customer initially.
The real world situation is different and time is almost always a constraint.
3.2.3 Resource Constraints
This is another point that doesn’t affect our Discord clone project but it is often a consideration in real life projects when working in a company.
This is again again an overlapping topic that start as a buisenss/organisational constraint but it can have impact on the whole project.
Limited development team size and expertise
Impact:
Complex components (e.g., voice/video streaming) may require simplified versions initially (due to timeline problems and team knowlege).
Development speed might slow without access to specialists.
Mitigation strategy:
- Build modular components to allow incremental team growth.
We identified all the constraint for our project and mentioned some more aspect that need to be considered.
3.3 BONUS - Documentation
I like to use the arc42 way of describe constraints.
Here is a summary of what the template suggest about Constraints.
Present constraints in straightforward tables accompanied by explanations. If necessary, categorize them into technical constraints, organizational and political constraints, and conventions (such as programming or versioning guidelines, documentation, or naming conventions).
Constraints are often dictated by prior infrastructure decision or by policies about technology that cannot be changed. These are called technical constraints.
Some classic example of those are:
- Using a specific programming language
- Using a certain DBMS
- The app must run on multiple platforms.
There are also Organizational Constraints, some examples:
- A dedicated deployment window during the week/month
- SCRUm as a work modus for project and maintenance
Constraints as you see can overlap with the concept of non functional requirements. Having them described in a clear way in a document can help every person working on a project to clarify the boundaries of their possibility to chose and discuss solutions.
Constraints as you see can overlap with the concept of non functional requirements. Having them described in a clear way in a document can help every person working on a project to clarify the boundaries of their possibility to chose and discuss solutions.
Articles I enjoyed this week
Why do some engineering teams consistently outperform others? by Milan Milanović
Inside the Queue: How Distributed Systems Handle Large-Scale Tasks by Baran Cezayirli
Nobody told me I would miss my JOINs when I started in microservices. by Raul Junco