In this article
Follow one request across the three tools
Consider a supplier-onboarding request arriving by email with an attachment. A proposed design uses n8n to receive the event and notify an operator, a Python service to extract and normalise document fields, and a Spring application to create the supplier record. This is an illustrative architecture, not a requirement to introduce three technologies.
The boundary matters more than the product names. Extraction returns proposed values and evidence; the business application checks required fields, duplicates and the user’s authority. A model may help interpret inconsistent documents, but it should not become the sole owner of supplier creation rules. If your existing stack can perform all three jobs cleanly, fewer moving parts may be preferable.
A proposed division of responsibility
Use only the components your existing stack and operating model need.
Scroll horizontally to read the table →
| Responsibility | Possible location | Contract |
|---|---|---|
| Receive and route a request | n8n orchestration | Request ID and explicit status |
| Extract document fields | Python processing service | Proposed values with evidence |
| Apply business rules and persist | Spring business service | Authorised, idempotent operation |
| Interpret a variable request | Model integration where needed | Bounded input, tools and output |
Separate orchestration from domain logic
n8n is effective when the visible flow, connectors and approvals are the product boundary. Keep complex invariants and transactional writes behind a versioned service rather than spreading them across nodes.
Python is a strong fit for data transformation, evaluation and model-adjacent experiments when packaging, observability and ownership are designed—not postponed.
Use Spring AI inside an owned application boundary
Spring AI can integrate model calls, tools and retrieval into an existing JVM application, but the framework does not decide consent, evaluation, failure policy or data ownership.
Put durable commands, authorization and audit in the application. Treat model output as untrusted input until the use case defines validation and human review.
Give each layer a clear job
One possible division of responsibilities; not a mandatory stack.
n8n · orchestration
Triggers, connectors and visible workflow coordination.
Python · processing
Focused transformations and specialised data processing.
Spring AI · application
Model interactions within authenticated business services.
Choose with failure and change scenarios
Compare how each boundary handles duplicate triggers, provider outage, schema change, secret rotation, manual replay, model version change and rollback. A hybrid is often clearer: n8n orchestrates, a service owns invariants, and a Python evaluation job measures behavior.
The correct boundary is the one a named team can test, observe and recover—not the one that produces the fastest demo.
Design the contract at each handover
Pass a request identifier, a schema version and a status with each handover. Distinguish “document unreadable”, “required field absent” and “service unavailable”; they need different treatment. A missing field should return to the operator, while a temporary outage may justify a bounded retry. Keep the original request traceable without copying sensitive attachments into every execution log.
The dangerous case is a timeout after supplier creation. Replaying the complete workflow may create a second record. Let the business service accept a stable operation key and expose the result of the original attempt. n8n can then ask what happened instead of guessing from the absence of an HTTP response. Durable state belongs where its consistency can be enforced.
Recognise when a workflow has become an application
Warning signs include the same validation copied into many workflows, manual editing of execution state, business rules hidden in large scripts and releases that nobody can review confidently. At that point, move the repeated capability behind a tested service interface while leaving orchestration visible to the operations team.
Do not migrate solely because a workflow has many nodes. A long but explicit integration can be easier to own than a short opaque script. Ask whether a colleague can explain a failed request, change a rule once and replay safely. Keep one end-to-end test across the boundaries as well as component tests; locally correct pieces can still disagree about dates, identifiers or status semantics.
FAQ / DECISIONS
Frequently asked questions
Should every n8n workflow call a custom service?+
No. Add a service when invariants, scale, transactions, reuse or testability justify the boundary. Keep simple recoverable orchestration visible.