Architecture patterns
Connect your systems without the tangle, and know when not to.ERP integration patterns
Patterns for connecting an ERP, a store, a bank and the rest. Each says when to use it, when not to, and how it breaks.
6 patterns. Each names its sources, with the date we read them.
Count the wires
Add systems and watch the links grow.
- 1ERP
- 2Store
- 3Gateway
- 4Bank
- 5WhatsApp
- 6Courier
6 systems
Counted, not measured. Not every pair needs a link: the explorer lets you count yours.
Start from what is going wrong.
Integration · reviewed 14 Oct 2026
Every new tool means another link to build
Point-to-point vs a hub
Integration · reviewed 14 Oct 2026
We check an API every minute and mostly find nothing
Webhooks vs polling
Integration · reviewed 14 Oct 2026
The same payment was booked twice
Idempotent webhooks
Integration · reviewed 14 Oct 2026
The order saved, but nobody was told
Transactional outbox
Integration · reviewed 14 Oct 2026
A sale on one channel sold the last unit on another
Eventual consistency in stock
Integration · reviewed 14 Oct 2026
The books and the bank disagree at month‑end
Reconciliation as a job
Next: cutover strategies. Need one sooner?
Every pattern is built the same way.
The seven parts
The problem
What goes wrong, in plain words, before any solution.
Use it when
The conditions where it pays.
Skip it when
The size or case where it does not. Every pattern has one.
Try it
A model you can move, with sample data.
What you give up
The trade-offs, and how it fails, each with its source.
In ERPNext, Frappe and Medusa
The exact doctype, field, setting or file, at a named version. Medusa where a pattern uses it.
Related
The glossary term, the post and the guide chapter behind it.
How they are checked
- Sources
- The maker's own docs or code, named by version or date.
- Failure modes
- Documented behaviour. None is a MithTech client result.
- Versions
- Frappe and ERPNext at a named release or branch. Medusa at v2.21.2, with one history row at v1.20.11.
- Reviewed
- Each page shows the date it was last read against its sources.
Questions about the patterns
An integration pattern is a reusable design for connecting systems, such as an ERP, a store and a bank. Each pattern here states the problem it solves, when to use it, when not to, what it costs and how it fails, so a team can decide whether it fits before building anything.
Because most designs are wrong for a business that is small or simple enough. A separate hub saves no links between three systems, and a reconciliation job is overkill for a few entries a month. Stating the limit first is what makes the rest of a pattern believable.
No. The designs hold in any ERP, including Zoho, Odoo, SAP Business One and Tally. The mapping sections use ERPNext, Frappe and Medusa because those are the systems we have read down to the code. Other systems' names and settings have not been checked here, so the pages do not claim them.
Each fact comes from the maker's own documentation or source code and carries the date or version we read. Frappe and ERPNext are read at a named release or branch, Medusa at v2.21.2, with one history row at v1.20.11. Failure modes are documented behaviour, not results from our client projects, and each is labelled that way.
Yes. The same definitions, limits, trade-offs, failure modes and mappings are published as /patterns.json, with identifiers that never change, so a tool can link to a pattern and stay correct when we update it. Each entry carries its sources and the date it was last reviewed.