Backend
Backend services for operations
Go and Python services for warehouses, dispatch and payments, where an operation must never run twice.
- backend and integrations in production
- 6 years
What you get
- An API and background workers for a concrete operation: receiving goods, shipping orders, dispatching vehicles, accepting payments.
- An operations journal in PostgreSQL. Every operation is written with an idempotency key before it touches an external system, so a double button press on a handheld terminal creates one document.
- Metrics in Prometheus, structured logs and a health endpoint.
- Tests against a real database in CI, a Docker image and deployment to your server or Kubernetes.
How I build it
One module per business area, thin handlers and the core logic in plain functions that are easy to test. No abstractions for a future that may not come. A single command checks the whole project, and its exit code decides whether a change ships.
How an operations journal prevents a second document or payment is covered in A repeated request must not create a second order. If you need an exchange between existing systems rather than your own service, see CRM, ERP and marketplace integration.
When you need a separate backend service
- Warehouse staff work on handheld terminals and the ERP is too slow or too fragile to talk to directly.
- A process runs on spreadsheets and messengers and needs a proper service.
- An existing backend works but nobody dares to change it.
Questions
What stack do you use?
Go or Python with PostgreSQL, RabbitMQ or Redis for queues and Prometheus for metrics. The service ships as a Docker image and runs on your server or in Kubernetes.
Do you take over an existing codebase?
Yes. The first week goes into reading the code, adding a test gate and writing down what breaks. Then we agree what to change first.