How KamoCRM Is Built

You don't need to know any of this to use KamoCRM. It's here because IT teams, security reviewers and procurement people ask, and it's easier to hand them a page than to arrange a call.

Many small services, not one big program

KamoCRM isn't a single application. It's a few dozen independent services, each responsible for one area — one handles email, one handles documents, one handles the knowledge base you're reading now, one handles calls.

The practical consequence is the one that matters to you: a problem in one area doesn't take down the others. If the document service is having a bad afternoon, email keeps working. A single large program doesn't behave that way — everything shares its fate.

Spread across several machines

Those services run on a cluster: a group of machines that work as one. Each service runs on whichever machine has room, and if a machine fails, the services it was running start again elsewhere, automatically, without anybody being paged.

This is also how KamoCRM is updated. A new version of one service is rolled out while the old one is still answering, and traffic moves across once the new one is healthy. Most updates happen without anybody noticing.

Your data is separated at the database level

Every record in KamoCRM carries the organization it belongs to, and every query is scoped to one organization before it runs. That separation is in the data layer, not in a filter that a screen applies afterwards.

The difference matters. A filter applied at the screen is something a developer can forget on a new screen. A constraint applied at the query is not something a screen can opt out of.

What talks to what

Services don't reach into each other's data. When something happens that another service needs to know about — an article is published, a call ends, a document is signed — a message is published and whoever cares picks it up. So a slow service delays its own work rather than blocking everybody else's.