Skip to content

Infrastructure & Integrations

Backend architecture: each rule in one place, behind every screen

When the office app, the technician's phone and the customer's account each check the same rule, one of them eventually checks an old version. Then a technician starts work the customer never approved. The backend is where each rule and each record should live once, with every screen asking it, and where you decide what has to happen before the reply and what can happen after.
Talk through your backendSee how it's divided ↓
office appJ-644 · extra work: blower motorrule copy: needs approvalasks the jobs moduleapproval status: waitingtechnician app · T3J-644 · extra work: blower motorrule copy: needs approvalrule copy: needs approvalold copyT3 can start: not approvedasks the jobs modulewaiting for J.H. to approvecustomer account · J.H.J-644 · extra work: blower motorrule copy: needs approvalasks the jobs moduleApprove the extra work?backendjobscustomersschedulingbillingjobsextra work waits forthe customer's approval

Modules that own their data

One backend, divided by what the business does. Each module owns its records; the others ask it rather than reaching in.
Jobsjobs, extra work, approvals, job historystart work, record an approval, close a job
Customerspeople, properties, contact preferencesfind a customer, check how they want to be reached
Schedulingtechnicians' calendars, visits, time slotsoffer open slots, book or move a visit
Billingestimates, invoices, payments recordeddraft an invoice, mark one paid

Now, or after the reply

J.H. taps Approve. Some of what follows has to happen before the screen says “approved”. The rest can wait a few seconds, and should.

Before the reply

What
record J.H.'s approval and mark the extra work ready to start
Why now
the screen must only say “approved” once it's true
How
one save: approval, job status and history together, or none of them
If it fails
J.H. sees “not saved, try again”; nothing half-done

What a backend design decides

Written down before the first screen is built, and revisited when the business changes.

  1. 01

    Boundaries

    Divided by what the business does

    Jobs, customers, scheduling, billing: modules that can change without breaking each other.

  2. 02

    Who owns each record

    One owner, everyone else asks

    A record kept in two places will disagree. Each one has a home, and copies are labelled as copies.

  3. 03

    States and the moves between them

    Written as rules, checked on the server

    Extra work goes from proposed to approved to done, and only the allowed moves are possible.

  4. 04

    Now or later

    Before the reply, or after

    Only what the person needs to see happen waits in the request. The rest is queued.

  5. 05

    What happens when something fails

    Saved first, then the next step

    Important steps are saved before anything else is triggered, so a failure is a retry, not a lost approval.

  6. 06

    How screens ask

    One way in

    Every app, and every connected system, goes through the same checks.

Split later, when there's a reason

Separate services on day one

  1. 01A service per noun, each deployed on its own
  2. 02Network calls where a function call would do
  3. 03Records spread across services that must agree
  4. 04More to deploy, secure and watch

A small team spends its time keeping the pieces in step.

One well-divided backend

  1. 01Clear modules inside one application
  2. 02Each module owns its records
  3. 03One deployment, one place to look when something's wrong
  4. 04A module moved out when it needs to scale or change on its own

The boundaries are there from the start; the splitting waits for a reason.

What the backend sits between

In

Screens
office, technician, customer
Connected systems
accounting, payments, texts
Who's asking
sign-in and role
Backend
rules, records, now or later

Out

Database
one home per record
Background jobs
what can wait
Answers
the same to every screen

Worth designing when more than one screen shares the rules

Good fit

  • Staff, customers and connected systems all work on the same records.
  • Your apps disagree about what's allowed.
  • The software will grow for years, with more people changing it.

Not the right fit

  • A single form that sends an email. Ordinary code is enough.
  • An off-the-shelf tool already does the job and you don't need to own the rules.

Where this capability is used

Next to backend architecture

Questions about backend architecture

Should we use microservices?

Usually not at first. One backend divided into clear modules is simpler to run and change. A module moves out on its own when it needs to scale or be released separately, and the boundaries make that move straightforward.

Can rules live in the screens instead?

Screens can show and hide things for convenience, but the decision is made on the server. Otherwise each screen enforces its own version, and anything that calls the backend directly skips the check.

What database do you use?

A relational database is the usual starting point for business records. Other kinds of storage are added when something needs them, like search or large files, not by default.

Can you work with our existing backend?

Yes. We start by mapping where each rule and record lives today, then move them one at a time, with the current system running throughout.