Skip to main content
Mostafa Effati

About this platform

A working notebook for engineering practice

This is Mostafa Effati’s personal engineering platform: a place to turn hands-on work into clear writing, structured learning, and useful digital products.

Student collaborator

  • Ms Zahra Ehsani

    Former student · platform contributor

    Ms Zahra Ehsani worked on parts of this platform during her studies and brought thoughtful, practical contributions to its development. I'm glad to recognize her work here.

What you will find

  • Long-form articles, books, tutorials, and practical snippets.
  • Courses and guided learning paths built around real engineering work.
  • Case studies, open-source work, experiments, and product releases.

Built deliberately

  • A bilingual Persian and English experience with native RTL support.
  • Theme-aware, keyboard-friendly interfaces with a focused visual language.
  • Content and product changes developed as one versioned system.

The platform is continuously evolving. Some sections are complete products; others are active experiments that improve as the underlying work develops.

Citizenship as a Relationship

Why citizenship should not be a single field on the Person entity.
Mostafa Effati3 min readsoftware-architecture

Why I Didn’t Store Citizenship Directly on the Person Entity

A small modeling decision that prevents large architectural mistakes in identity systems.

While redesigning my Identity Service, I noticed a recurring pattern: many systems assume a person has exactly one citizenship.

Person
 └── citizenship_country_id

Simple to query. Easy to understand. Hidden assumption: one nationality forever.

Reality check

  • Multiple citizenships are normal in many regions
  • Second citizenship can arrive later in life
  • Primary nationality can change; some are renounced

These are legitimate scenarios — not exotic edge cases you can forever postpone.

Attribute vs relationship

Turning a relationship into an attribute is one of the most common design shortcuts — and one of the most expensive to undo.

The model I used

Person
     │
     ├── Citizenship #1
     ├── Citizenship #2
     └── Citizenship #3

In database terms:

Person
     │
     └── PersonCitizenship
              │
              └── Country

Each citizenship can carry:

FieldWhy it exists
CountryWhich state
Acquisition dateHistory / audit
StatusActive, renounced, pending
Primary flagUX and default jurisdiction

Why this matters

1. It reflects reality

People can have one citizenship — or several. The model should represent both.

2. It avoids expensive migrations

Discovering multi-citizenship late means schema surgery under load. Modeling the relationship early is cheaper.

3. Clearer boundaries

Citizenship is not merely a column. It is a relationship between a person and a country.

Example: one person, two states

A small modeling lesson

Sometimes an attribute is hiding a richer concept underneath. Citizenship was one of those concepts in my system.

Design goal

Not “support every edge case on day one” — avoid assumptions that aren’t universally true. One citizenship or several: both should fit.

You’ve now seen the first modeling arc of this book: Person / User → Contacts → Citizenship. Next: dual sessions — device before account — and the refresh-token families that make theft detectable.

Next chapter


Canonical version. Also on Medium.

Related documents

Command menu

↑ ↓to move · Enter to select · Esc to close
Navigation
Actions

Press Esc to close · ⌘K to toggle