One idea
A trade-off is not a weakness. It is a choice with a cost.
Good system design does not say “this is best”. It says “we chose this because it fits our users, deadline, and constraints”.
What to compare
For a hackathon project, compare choices that a reviewer can see in your app. Do not write theory that your code does not use.
Common trade-offs are SQL vs NoSQL, cache vs fresh data, queue vs direct processing, scale up vs scale out, and managed service vs self-hosted.
Use this frame
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done
Use real constraints
Tie your explanation to your project. Mention things like team size, demo deadline, expected users, free tier limits, or Indian user behaviour such as mobile-first usage and patchy networks.
A clear small reason beats a vague big claim. “We cache college list data for 10 minutes because it rarely changes” is stronger than “cache improves performance”.
Avoid fake certainty
Do not write “MongoDB is faster than PostgreSQL” or “queues are always better”. These are not useful without context.
Also avoid hiding downsides. If you used a simple design because the hackathon was 36 hours, say it. That sounds honest and practical.
README trade-offs
Add a short section like this to your repository README. Keep it close to your architecture diagram and API list.
This example is for a campus event app that sends registration emails after a user signs up.
## Trade-offs
### 1. PostgreSQL instead of MongoDB
We chose PostgreSQL because our main data is relational: users, events, registrations, and colleges.
It lets us use joins and unique constraints to stop duplicate registrations.
Trade-off accepted: changing the schema takes more planning than a document database.
For a hackathon app, this is okay because our data model is small and stable.
### 2. Queue for email sending instead of sending inside the signup API
We push email jobs to a queue after saving the registration.
This keeps the signup API fast even if the email provider is slow.
Trade-off accepted: the email may arrive a few seconds later.
We also need a worker process, so deployment has one extra moving part.What reviewers notice
Reviewers are not looking for one perfect answer. They want to see that you understand consequences.
If your app works and your README explains two real choices with costs, your system design proof becomes much stronger.
Do this now
Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.
0 of 5 done