Designing the Data Model (Before Writing Any Code)

Before we talk about authentication, APIs, or frameworks, let me ask you something:

👉 What data does your system actually store?

If you can’t answer that clearly, writing code will feel messy — because it will be.

So in this post, we’ll slow down and do something most tutorials skip:

design the data first.

No code yet. Just thinking.

---

Why Data Comes Before Everything Else

Every application, no matter how simple or complex, exists for one reason:

To store information and act on it later.

Authentication? → stores users
Events? → stores event details
Authorization? → depends on roles stored in data
Frontend UI? → displays stored data

If the data model is unclear:

• APIs feel confusing

• roles feel hacked together

• features become hard to add later

So instead of asking “How do we implement login?”,
we first ask:

What is a user in our system?

---

Let’s Think Like Humans, Not Databases

We won’t start with schemas, tables, or theory.

We’ll start with a simple question:

“What do we need to remember about a user?”

User (in plain English)

For EventHive, a user needs:

• a unique identity

• a name

• an email

• a password (securely stored)

• a role

• when they joined

That’s it.

Already, this gives us clarity.

---

Roles Matter (Even at the Data Level)

From the previous post, we identified three roles:

• Attendee

• Organizer

• Admin

So our user data must store what role the user has.

This single field will later control:

• what APIs they can access

• what UI they see

• what actions are allowed

Notice something important?

👉 Authorization starts in the data model.

---

What About Events?

Now let’s ask the same question:

“What do we need to remember about an event?”

Event (again, in plain English)

An event needs:

• a title

• a description

• a date & time

• a location

• who created it

• who is attending

Nothing fancy.

But one thing stands out:

👉 Events are connected to users.

That means relationships exist in our data.

---

Choosing a Database (Without Overthinking)

At this point, we know:

• we have users

• we have events

• they are related

• data will evolve over time

For this series, we’ll use MongoDB.

Why?

• beginner-friendly

• flexible structure

• works naturally with JSON

• widely used in real systems

We’re not choosing MongoDB because it’s “cool”.
We’re choosing it because it lets us focus on thinking, not fighting schemas.

---

How MongoDB Fits Our Thinking

MongoDB stores data as documents.

So our earlier “plain English” thinking maps nicely.

User document (conceptually)

• id

• name

• email

• password

• role

• createdAt

Event document (conceptually)

• id

• title

• description

• date

• location

• createdBy (user id)

• attendees (list of user ids)

No magic. Just structure.

---

References, Not Complexity

We won’t embed everything everywhere.

Instead:

• users live in one collection

• events live in another

• relationships are connected using IDs

This keeps things:

• simple

• scalable

• easy to reason about

And most importantly — easy to explain.

---

What We’ve Achieved (Without Code)

Before writing a single API:

• we know what data exists

• we know how entities relate

• we know what roles mean

• we avoided future confusion

This is real engineering work.

And it makes everything that comes next smoother.

---

What’s Next?

Now that we know what a user is, we can finally talk about:

• signup

• login

• password storage

• JWTs

But this time, it will all make sense — because the data already exists.

➡️ Next Post: Authentication Starts with Data

We’ll build login and signup on top of this model, not randomly.

And you’ll see why doing it this way feels… calm.