It's easy to begin a backend project with:
Node.js or Python?
PostgreSQL or MongoDB?
Monolith or microservices?
Those questions matter.
But answering them before understanding the system can lead to an architecture that looks good on a diagram and becomes painful in production.
Here are seven questions worth answering first.
1. What is the system responsible for?
Write down the business operations the backend actually owns.
For example:
- Creating an account
- Placing an order
- Changing a subscription
- Assigning permissions
- Updating inventory
- Sending notifications
Framework selection becomes easier once those responsibilities are clear.
2. Which data does the application own?
If the same customer exists in your application, CRM, payment provider, and analytics platform, decide which system owns which fields.
Without clear ownership, integrations easily turn into synchronization problems.
A useful rule is:
Every important piece of data should have an identifiable source of truth.
3. Which operations must happen immediately?
Not every task belongs in the request-response cycle.
Some actions must finish before the user receives a response.
Others can happen asynchronously:
- Sending email
- Generating reports
- Processing files
- Syncing external systems
- Running analytics jobs Separating these early can prevent slow endpoints and unnecessary coupling.
4. What happens when an integration fails?
A successful API call is the easy case.
The more interesting questions are:
- Do we retry?
- How many times?
- Can the request safely run twice?
- Do we queue it?
- What gets logged?
- Does a human need to intervene? If your system integrates with payments, CRM, messaging, identity, or other third-party services, failure handling is part of the architecture.
5. What is the authorization model?
Authentication is only the beginning.
A real application may have:
- Users
- Administrators
- Support staff
- Account owners
- Organization members
- Vendors Decide whether permissions are role-based, resource-based, organization-based, or some combination.
Adding authorization as an afterthought usually spreads conditional logic everywhere.
6. What information will you need in production?
Before launch, define what developers need when something fails.
At minimum, consider:
- Structured logs
- Error tracking
- Request identifiers
- Performance metrics
- Integration failures
- Database health
- Alerts Observability is much easier to add intentionally than retroactively.
7. What is likely to change?
Architecture should leave room for realistic change, not every hypothetical future scenario.
Ask:
- Will multiple clients use the same application?
- Are new integrations expected?
- Could workflows change?
- Will separate teams eventually own different areas?
- Which parts are stable? This often gives you better architecture boundaries than beginning with a diagram of services.
Framework selection comes after system understanding
Once these questions are answered, choices like Node.js vs Python, SQL vs NoSQL, or monolith vs microservices become much less arbitrary.
For a broader view of how APIs, databases, integrations, authentication, and application logic fit together, this overview of backend development services provides additional context.
A good backend architecture isn't the one using the most sophisticated technology.
It's the one whose complexity matches the problem it needs to solve.
What backend decision have you seen become unexpectedly expensive later?
Top comments (0)