Microservices or one panel. The wholesaler has the order, the warehouse has another figure
Author:
Paweł Matusiak
·
A sales rep promises the goods, the warehouse shows a different figure, the invoice waits for a message from a separate service. Microservices help when separate teams really move at different speeds. With one order flow and two people on the software, one panel with modules is cheaper to keep than four logs in which stock goes missing.
A sales rep at a wholesaler promises an installer goods for tomorrow. The warehouse floor shows a different figure. The invoice sits there because a separate service has not yet received the message. The owner is told that this is what a modern programme is supposed to look like.
Microservices split an application into separate services that are deployed and scaled on their own. That split helps when separate teams really own separate pieces of the product and those pieces change at different speeds. In a firm with one order flow and two people on the software, it rarely speeds anything up. The same working day — the call, the pick, the document — breaks into several deployments and several logs. Until the organisation has hard seams, it is cheaper to keep one panel with clear modules than a mesh of services in which stock goes missing. The split will not pick the pallets on the floor by itself.
The order, the stock and the invoice fit into one working day
A wholesaler does not plan the day by services. It plans it by the installer’s call, the pick on the floor and the invoice that has to go out before the customer leaves for site.
In the morning the sales rep takes an order. The price rarely comes from the public list. It is an exception from a contract, a quarterly discount, a kit the catalogue does not hold as a single line. At midday a warehouse worker does the picking. In the evening the office issues the document, sometimes with a deposit, sometimes with a line added after a second call.
When those three things live in three programmes, the truth about the order is assembled from a spreadsheet, a warehouse screen and an email thread. Someone from outside then proposes a split: a separate catalogue, separate orders, separate stock, separate invoices. On a slide it looks like order. In the working calendar it is the same mess, only with a bus in the middle.
Before a mesh of services appears, the firm needs an order card that shows the customer, the price, the reservation and the document status. A B2B panel for a wholesaler describes that flow from the price list to stock. A separate API is justified when that card already exists and one fragment of it regularly throttles the rest. Not while the card is still missing.
The sales rep will still ring when the customer changes the kit at midday. The card does not replace the call. It replaces guessing which stock figure is current and which document has already gone to accounts.
Example: an electrical wholesaler and four services instead of a panel
Imagine an electrical-supplies wholesaler. A dozen or so people in the office, a warehouse off the hall, sales reps driving out to installers. The panel covers customers, individual prices, orders and invoices. Stock is typed up at the end of the day. Two people sit with the programme; an outside developer drops in from time to time.
A typical situation looks like this. After a course on architecture a decision is taken: catalogue, orders, stock and invoices as separate services. Between them an event bus. The order emits a message, stock is meant to update, the invoice is meant to be issued.
For a few quiet weeks it works. Then on a Friday afternoon an installer orders a kit that is short on the shelf. The order service accepts the document. The stock service gets the message late, or not at all, because the queue has stalled. The warehouse picks from what it can see on the rack. A second sales rep at the same time promises the same goods to another customer, because their screen still shows the old figure. A rep in the field opens the panel on a phone and makes a promise from what they see. If that screen reads stock with a delay, the promise is already wrong before they are back in the office.
The result is ordinary and expensive. One line goes out twice, or not at all. The customer receives part of the kit. The office issues a credit note. The two people in IT hunt through logs for the missing message. The warehouse worker says they scanned into “their” programme. The office says the order in the panel was different.
A fifth service does not help in this story. What helps is a stock reservation on the same card the order is born on, and a queue only for heavy work: the seasonal report, a bulk price change, a batch of invoices. The warehouse worker ticks the pick against that card, not in a separate programme that will catch up later.
Two people will not keep four deployments
That cost usually never makes the slide about scale.
Each service is a separate image, separate secrets, a separate log, a separate check on whether it is alive at all. When an order hangs, someone has to know whether the catalogue, the queue, stock or the network between them has failed. In one panel that trail sits in one place. In four services it is assembled from observability: a request trace, correlation, a time limit, a retry, a dead message stuck after a restart.
A deployment of four services is four chances of a version that does not match its neighbour. The catalogue changed a field. Orders still read the old one. Stock waits for a different product identifier. Invoices stay silent because the event changed its name. In the building season that drift shows up on a Friday afternoon, when the hall cannot be closed for a “maintenance window”.
Two people can hold that for a month while nothing breaks. They cannot cover on-call for four programmes when orders arrive in the evening and the warehouse works on Saturday. On-call is a people cost, not a cloud-instance cost. Splitting into services moves that cost from the server onto sleep and onto the Monday spent reconstructing which message never arrived.
On top of that comes infrastructure the wholesaler’s traffic does not justify. Separate databases, separate queues, separate test environments. Every price or kit change needs a contract agreed between services. Time that was meant to go into the order card goes into the pipes between programmes.
The customer sees stock that is not on the rack
The argument about the diagram fades when the promise on the panel does not match the rack. Margin starts leaking.
The installer orders because the B2B panel shows the goods. If that panel reads stock from a delayed service, the promise is false. The warehouse picks something else, or nothing. The sales rep loses face. The office loses a morning to the phone and to a credit note. In the electrical wholesaler from the example, the same drum of cable can be promised to two sites because no screen subtracted the piece at the moment the document was taken.
An individual price list makes it worse. The customer’s price is not a field in the catalogue. It is an exception, a deadline, sometimes a tie to a particular job. When the catalogue is one service and the order another, the exception goes missing on the way or stays on an old version. The customer is billed a different amount from the quote. Accounts receive a document the sales rep does not recognise.
In one panel the reservation and the price sit on the order. The warehouse can see that the piece is already promised. The sales rep can see they must not sell it a second time. Eight services are not required for that. What is required is one truth about stock at the moment the document is created, not half an hour later when the queue finally arrives.
The end user does not judge architecture. They judge whether the panel lied. An installer who once received a promise without the goods goes back to the phone, or to another wholesaler. The cost of that loss does not appear on the cloud invoice. It appears in the lost order and in the hours the office spends sorting out the blame.
A boundary the firm does not yet have
Cutting into services makes sense when a domain boundary is visible. The order ends in one place, the pick starts in another, and those two worlds have different people, a different pace and different accountability. In a bank or on a platform with several products those seams are sometimes obvious. In a wholesaler with a dozen people in the office they often are not.
In a small wholesaler the same person takes the call in the morning, looks in on the warehouse at midday and asks about the invoice in the evening. If the system is now cut to the slide — catalogue, basket, payment, warehouse — it is technical layers being cut, not the firm. That split is hard to reverse. Every change to a price, a kit or a reservation against a job goes through several contracts between services. A fix that takes a day in one module takes a week of negotiation across four services.
The safer move is a modular monolith: one programme, one deployment, clear modules inside it with their own tables and a ban on short-cuts into a neighbour’s data. A report that throttles the order screen in season drops onto a job queue. When, after a longer stretch, invoicing really does live at a different pace and has a different owner in the firm, that piece may be pulled out. Not the other way round.
Technical debt in a panel grows faster when a bad boundary is flooded with yet more events. The team is not then paying the debt down. It is building bridges over a split the firm did not need. The building season shows it plainly: a heavy sales summary should get out of the sales rep’s way, not drag the catalogue, the basket and the warehouse into a demolition.
The monolith bloats and one fault takes everything down
The counter-argument is serious. Waving it away with a line about a “good enough” programme achieves nothing.
In tangled code the accounts report and the taking of an order sit in the same process. A heavy month-end summary slows the sales screen. A fault in a price-list import can bring the whole site down. Several people change the same file and overwrite one another’s work. A single point of failure is then real: everything falls over because everything is one process.
Independent deployment looks, in that moment, like a promise of calm. You break invoices, orders keep running. Scaling can be a genuine reason too. Reports eat the database, and taking an order has to stay fast. The report can then be pulled out, or read from a copy. There is no need, on that occasion, to break up the catalogue, the basket and the warehouse.
That description fits a bad monolith, not every programme in one process. Modules, a separate queue for the report, a limit on heavy screens and one pipeline that can roll back to the previous version deal with most of that pain without a mesh of services. When the same two people deploy four services, independence exists only on paper. Versions drift in four places, and blame is hunted in four logs.
The limit is honest. When a firm has several products, several teams and different availability needs — a customer panel, heavy analytics, a separate exchange with a counterparty — a split into services can be justified. The condition is organisational, not aesthetic: the boundary already exists in the people and in the calendar, not only on the diagram. If one team is on call for everything, a distributed programme is still a distributed monolith. A fault still takes the working day down; the trail is merely longer.
What may be pulled out earlier
There are exceptions that do not need a wait for a second team. A heavy export, a bulk markdown, a stock view that is read-only, documents sent in the background. Those are background jobs, not products in their own right. A queue in the same programme is usually enough. A separate service appears when that job has its own rhythm, its own contract with the outside world and someone who will keep it when the rest of the panel is down.
A spreadsheet, a ready-made programme, an integration or one’s own panel
Not every wholesaler needs its own code, and still less its own mesh of services.
A dozen orders a day, one warehouse and a price list in a sheet — a spreadsheet will do, provided nobody runs a second list on the phone and stock is not promised from memory. A ready-made stock-and-sales programme is often cheaper than one’s own panel when the flow is by the book: document, issue note, invoice, stock. A working warehouse programme is not scrapped in order to have a “modern architecture”.
The problem starts with individual prices, kits for the installer, a reservation against a job, and with accounts sitting in another programme. Then integration comes first: the panel talks to the warehouse programme and to the accounts package, instead of pretending to replace both. A ready-made programme stops adding up when there are more exceptions than standard cases, and when three programmes lie to one another about the same piece of stock.
The order that usually hurts less:
- One order card: customer, price, stock reservation, document status.
- An integration with the programme that already counts the warehouse or the books, instead of a second round of typing.
- Modules in one panel and a queue for the report that throttles the rest in season.
- A separate service only when a piece has a stable boundary, a different rhythm and someone who will keep it.
A dedicated panel is justified when that exception is everyday work and when one card saves people assembling the truth from three places. Microservices are not the next stage of that panel. They are a decision about how IT work is organised. In such jobs GESOFT first maps the flow: who promises the goods, who reserves stock, who picks, who issues the document. From that it is clear whether existing programmes can be wired together, whether one panel with modules is needed, and only later whether a module deserves a service of its own.
Sometimes the result is modest: a card, a reservation, a bridge to accounts. Sometimes the seasonal report has to get out of the orders’ way. More rarely, with several teams and several products, a genuine split appears. That conversation is cheaper than commissioning a “microservice architecture” before anyone has written down what happens between the sales rep’s call and the scanner on the floor.
A conclusion from the cost of people, not from a diagram
Microservices are not a mistake. The mistake is to use them as the default shape of a panel for a firm that has one team and one working day from the call to the invoice.
The arguments yield an order of work. First one card and one truth about stock, because without that the customer is promised goods that are not there. Then modules and a queue where the weight throttles the rest, because that treats a tangled monolith without four on-call rotas. Then, when the boundary and the people are ready, extraction of a service. Reversing that order gives the wholesaler in the example four logs and an installer whose panel showed a drum that was no longer on the rack.
The counter-argument about failure and about scaling still holds where the programme really is a tangle and the report eats the orders. The answer then is modularity and a background for heavy jobs, not an instant mesh of services. The limit still holds too: several products, several teams, different availability — a split can be justified. In other firms architectural evolution is cheaper than a revolution on a conference drawing. Two people in IT will keep one programme with clear seams. They will not keep four services and an event bus when a message vanishes on a Friday afternoon.
Frequently asked questions
- Should a small wholesaler start with microservices?
- Usually not. One team and one flow from order to invoice copes better with one panel and modules. Separate services are justified when a piece of the product has a different rhythm, different availability and people who will keep it. A slide about scale does not replace that.
- How is a modular monolith different from “one big programme”?
- In a module it is clear who owns the price list, the reservation and the document, and a neighbour’s data is not read by a short-cut. In a tangled programme the report, the order and the price-list import sit in one run and bring one another down. Splitting into modules does not require separate deployments. It requires seams in the code and in accountability.
- When should a separate service be pulled out of the panel?
- When the boundary has been stable for some time, when that piece throttles the rest or has a different contract with the outside world, and when someone in the firm will take on-call for it. A heavy report or a batch of documents is often enough as a queued job, without a separate programme.
Related service:
Custom B2B platforms and CRM
Describe your project