Split your monolith into services you can scale
Kitecorp takes monoliths apart one service at a time, in production, without a rewrite. Each extraction is chosen for the scaling or delivery problem it solves, ships behind the existing interface, and is measured before the next one starts.
What does Kitecorp deliver?
A map of the monolith: its modules, the calls between them, the tables each one touches and the parts of it that actually need to scale differently from the rest. A ranked list of extraction candidates with the reason for each. The first extractions, delivered with your team and shipped behind the monolith’s existing interfaces so nothing upstream changes. The platform pieces an extraction needs and the monolith did not: a deployment pipeline per service, service discovery, an API gateway or load balancer, and tracing that follows a request across the boundary. And the measurement that tells you whether each split was worth it.
Which service do we extract first?
The one that hurts. A module that needs ten times the capacity of the rest at peak, a module whose releases are blocked by everyone else’s test suite, or a module a separate team already owns in all but deployment. Among those, the first candidate is the one with the clearest boundary: few callers, few shared tables, a contract you can write down. Extracting a well-bounded module first builds the pipeline, the observability and the team’s confidence; extracting the tangled core first builds frustration.
How do we handle the database?
Slowly and in that order: code first, data last. The extracted service starts by calling the monolith for its data. Then it owns its tables inside the shared database, with the monolith reading through it. Then the tables move to the service’s own store, with dual writes and a verified backfill while both exist. Every step is reversible and every step is measured, because the database split is where most microservice migrations lose data or lose months.
Horizontal or vertical: how do we scale the result?
Both, chosen per service. A stateless request handler scales horizontally: more replicas behind a load balancer, autoscaled on the signal that limits it. A service bound by a single large working set, a connection-heavy database client or a license per instance scales vertically first, with a bigger instance, and horizontally only once the vertical ceiling is in sight. The guide on horizontal versus vertical scaling walks through the limits each one hits.
How does an engagement run?
A discovery call to understand the monolith and the pain. The map and the ranked candidates, with the platform pieces the first extraction needs. The extractions, one at a time, with your team, each measured before the next. A handover with runbooks, dashboards and the decision record for why each boundary sits where it does. Pricing follows the discovery call, once we know the scope.
Frequently asked questions
Do we have to rewrite the monolith?
No. Rewrites fail because they stop delivery for a year and then ship a system nobody tested at scale. Services are extracted one at a time while the monolith keeps running, and each one proves itself before the next.
Which service should move first?
The one whose scaling or release cadence hurts most and whose boundary is clearest. The assessment ranks candidates by both, so the first extraction pays for itself.
What happens to the database?
It is split after the code, not before. A service first reads and writes through the monolith's data, then owns its tables, then moves them, with each step reversible.
Do you work with our existing team?
Yes. Every engagement is delivered with your engineers and ends with a handover, runbooks and alerts they own.
How do we start?
Send a message through the contact page. We schedule a discovery call, agree the scope, and pricing follows what we find.
Tell us what you are scaling
Send a short description of the system and the deadline. A senior engineer replies by email, and pricing follows a discovery call.
Contact Kitecorp or email admin@kitelang.cloud