The CMDB at Insnapsys
Some details of this work are confidential, so this page leaves out product names, customers and numbers from work. The demos are rebuilt from scratch with made-up data.
The platform, in plain words
A CMDB (configuration management database) is a live map of a company’s network and IT. Every device, connection and setting is a record in it, so anyone, or anything, can look up what exists and how it fits together.
At Insnapsys that map does real work. An AI agent runs on top of it and handles the first response to network problems, day and night:
- It reads the alert and looks up the equipment involved in the CMDB, so it starts with the full picture.
- It runs the fix it knows, using step-by-step procedures written so a machine can follow them safely.
- If that does not work, it hands over to a person with everything they need: the alert, the equipment involved, what it tried and what happened.
- It keeps the map honest. It compares what is really on the network with what the CMDB says, fixes clear mismatches itself and raises the rest for review.
Every decision the agent makes is recorded, so there is always a trail to check.
Where my work fits
Before anything goes into the map, the platform has to answer two questions: may this customer create another item, and whose share does it count against? Those answers are my part of the platform.
Built end to end
Licensing
- What it does
- Caps how many new items a customer can create in the CMDB. At the limit, new ones are refused, but everything already there keeps working.
- Why it matters
- Customers can move between plans, even to a smaller one, without anything they rely on breaking.
Worked on
Allocations
- What it does
- Shares capacity out between parts of the system. Each share limits how many items can be created under it, and shares can be moved around.
- Why it matters
- No single area can use up everything, and capacity can go where it is needed without touching what already exists.
Licensing, which I built end to end
The rule is simple to say and easy to get wrong: a licence sets a limit on new items. Once the limit is reached, new items are refused. Items created earlier stay fully usable. And if the licence is lowered, nothing that already exists is removed or blocked; only new items have to wait until usage is back under the limit.
Try it below. Each gate is something being created. Open three gates, then try a fourth: it is refused. Lower the permit to two: the three open gates keep running, and new gates stay refused until fewer than two are open.
Open a gate to let requests through. The permit allows three at once.
- Closed
- Closed
- Closed
- Closed
- Closed
Gate log
Allocations, which I work on
Allocations split the licence into shares. Each part of the system gets a share, and can only create as many items as its share allows. Shares can be moved from one part to another, but never below what a part is already using, and never beyond the licence as a whole.
Try it below: use slots in a service until it is full, then drag a boundary to give it more from its neighbour.
- C1: 2 of 4 slots in useSpace for 2
- C2: 4 of 4 slots in useFull
- C3: 1 of 3 slots in useSpace for 2
Router set to C1: 2 of 4 slots in use.
Point at a service, or tab to one. Use slots until its share is used.
Decisions I made
Where the licence check lives
The check sits at the one place an item is actually created, not in a single screen or web route. Items can be created by the app, by imports, by background jobs or by scripts, and a check on just one of those paths would let the others slip past. So every path goes through the same step, and that step asks the licence first.
Why not a validation rule or middleware?
Those only guard one web route. The rule is about the data, not the route, so it lives right next to the write. Whether a user may create anything at all is a separate question, handled by a policy class; whether there is room for one more is the licence’s job.
Two requests, one slot left
If two requests arrive together when only one slot is left, both could see “one left” and both succeed, breaking the limit. To stop that, the count is checked and the item is saved inside one database transaction that locks the licence first. The second request waits, then sees the limit has been reached, and is refused.
What that looks like in Laravel
Inside DB::transaction(), the licence row is loaded with lockForUpdate(), usage is counted, and the item is created only if usage is under the limit. The lock is held as briefly as possible: nothing slow, like a network call, happens inside it.
How the rules are tested
Each rule is tested right at its edge: one under the limit is accepted, one at the limit is refused, lowering the licence keeps every existing item, and freeing an item only opens a slot once usage drops below the new limit. The demos on this page run on a rebuilt version of the same rules, with the same tests.
What I would do differently
Treat a refusal as a proper result from day one, carrying the reason and the numbers behind it (“3 of 3 in use”), instead of a plain error. The screen, the logs and the tests all need that same answer, and a clear refusal object gives it to all three.
Coming next
A public Laravel repository that rebuilds this pattern with generic names (Licence, Resource, Allocation), Pest tests and a lock on the last slot is planned. It will be linked here once it is published.