Backend services and microservices
Your systems exchange data automatically and keep up as your business grows
For companies with systems that do not exchange data, an app that slows down as users increase, or a need for an API that their own apps or the organizations they deal with can use.
01
Problems we solve
The online store, accounting, and inventory are separate systems, and we re-enter the same data in each one.
Our app slows down at peak times, and we worry it will stop working as we get more customers.
An organization we deal with wants a direct connection to our system, and we have no interface for it.
Every small change to the system requires shutting it down completely.
02
What the service includes
- F.01
System integration
Connecting the online store, accounting, inventory, payment gateways, and messaging services, so data moves between them without re-entry.
- F.02
Documented APIs
APIs used by your apps or the organizations you deal with, with permissions, usage limits, and clear documentation.
- F.03
Services that keep up with growth
Separating the parts under the heaviest load, caching, and job queues, so the system stays fast as the number of users grows.
- F.04
Microservices only when needed
We split the system into microservices when each part needs to be deployed or scaled independently. If the size of the system and its team does not call for that, we recommend a single application organized into clear modules.
- F.05
Monitoring and alerts
Logs and metrics that show what is happening between systems, and alerts when an integration fails, so you do not find out about a fault from a customer’s complaint.
03
How it runs
We map the systems
We identify the existing systems, the data that moves between them, who enters it, and where it is duplicated.
We choose the right architecture
We decide with you between a single well-organized application and separate services, based on the size of the system, its team, and its running cost.
We build and test the integration
We build the APIs and services, and test them on real data and against dropped connections and duplicate sends.
We transition and monitor
We move the work to the new architecture in stages, and monitor performance and errors after each stage.
04
What it looks like in practice
Illustrative example
A company sells through an online store and point-of-sale (POS) terminals in its branches, and an employee enters the orders by hand into the accounting software and updates inventory in a separate spreadsheet. We build an integration layer that automatically moves every order from the store and the branches to accounting and inventory, and retries when the connection drops. The figures match across systems, and the employee is free to follow up on exceptions instead of re-entering data.
05
What we need from you to start
- A list of your current systems, and the API or access rights available for each
- Someone on your side who knows these systems and approves integration decisions
- Examples of the data that moves between your systems today
06
Support and development after launch
Our work does not end when we hand over the system: we keep track of its day-to-day operation and develop it as your business grows.
- A post-launch support period to fix bugs and monitor stability, as set out in the contract.
- Keeping track of performance, backups, and security updates.
- Regular review sessions to rank improvements and the next modules by your priorities.
- Training for new users when the team grows or branches are added.
07
Common questions
Technologies we work with
- Node.js
- .NET
- PostgreSQL
- RabbitMQ
- Docker
Do we need microservices?
Not always. If the system is mid-sized and run by a small team, a single application organized into clear modules is simpler to run and costs less. We turn to microservices when parts of the system need to be deployed or scaled independently.
Do we need to replace our current systems?
No. We connect your existing systems to each other, and we only suggest replacing one when it can’t exchange data in any way.
What if our current system has no API?
We look at the available alternatives: access to the database, periodic export and import files, or an intermediate layer we build around the system. Then we choose the option with the least risk to your data.
Can we offer an API to external organizations we deal with?
Yes. We build an API with separate permissions for each organization, usage limits, and request logs, and we deliver documentation their technical team can work with.
08
Related work and articles
Backups and monitoring: what your system needs after launch
Launch day isn’t the end of the project but the start of a stage in which your daily work depends on the system. We explain what your system needs from then on: tested backups, monitoring that alerts the person responsible, and a clear plan for failures.
Why we build business systems on .NET
Choosing a technology platform is a decision that stays with you for years after launch, and its effects show in the cost of maintenance and upgrades and in how easily the system can be handed over. We explain why we choose .NET for business systems, and which questions to ask any vendor.
09
Related services
All services- S.03
Custom ERP systems
A custom ERP system built around your procedures and business rules, implemented module by module according to your priorities.
- Module map and numbered business rules
- Custom ERP system delivered module by module
- Permissions and roles matrix
- S.04
SaaS platforms
We build your platform to serve multiple customers by subscription, each with a separate account and isolated data.
- Multi-tenant SaaS platform
- Subscription and billing system
- Platform admin panel
- S.05
Mobile apps
iOS and Android apps for your customers and field teams, working on weak connections and linked to your system.
- iOS and Android apps
- API connecting the app to your system
- Admin panel for content and users
Let’s start with how you work
Describe your processes and the problem you want to solve, and we will define a clear first step with you.