Every release is all or nothing
A small change to invoicing needs a full regression test and a deploy of the whole application — so releases get bigger and rarer.
Microservices architecture
Break the monolith.Not the business.
For CTOs whose single codebase has become the bottleneck: we split it into services along real business boundaries, one piece at a time, while the existing system keeps serving customers.
- Big-bang cutovers — every step is reversible
- 0
- Services extracted and verified independently
- 1 at a time
- Sev 1 response, 24/7, once in production
- < 1 h
Signs the monolith is in the way
A monolith is not a mistake — it is usually how successful products start. It becomes a problem when its size starts setting the pace of the business.
One hot path scales everything
Search or reporting load forces you to scale the entire application, and a slow query in one module takes down the rest.
Teams step on each other
Everyone works in the same codebase and the same database schema. Merge conflicts and coordination meetings replace shipping.
The rewrite that never finishes
A previous attempt to rebuild from scratch stalled halfway, and now there are two systems to maintain.
How we split without a rewrite
We do not recommend microservices by default. We recommend the smallest number of services that removes your actual bottleneck — and we get there incrementally, with the old system live throughout.
Boundaries from the business
We run domain-mapping sessions with the people who use the system to find natural seams — billing, identity, inventory, notifications — so each service owns one capability and its own data.
Strangler-fig migration
A routing layer sits in front of the monolith. One capability at a time is rebuilt as a service and traffic is shifted to it gradually, with instant fallback. There is never a big-bang cutover.
Events over tight coupling
Services communicate through well-defined APIs and asynchronous events, so a slow or failing service degrades one feature instead of the whole product.
Data ownership, carefully
Splitting the database is the hardest part. We move data per service with change-data capture and dual writes where needed, and verify consistency before retiring the old tables.
Observability first
Distributed tracing, correlated logs and per-service dashboards go in before the first service goes live. When something is slow, you can see which hop is responsible.
Know when to stop
A well-structured modular monolith is sometimes the right end state. We will tell you when the remaining pieces are cheaper to leave where they are.
The stack
Services
- Node.js / TypeScript
- Docker
- REST & gRPC
- API gateway
Messaging
- Event bus / queues
- Webhooks
- Outbox pattern
- Idempotent consumers
Data
- MongoDB Atlas
- PostgreSQL
- Redis
- Change-data capture
Operations
- Render / DIV data centre
- Distributed tracing
- Per-service dashboards
- Automated rollbacks
How an engagement runs
- 1Weeks 1–2
Assess
Code, data model, traffic and team structure are reviewed to find where the monolith actually hurts.
- 2Week 2–3
Map the domain
Service boundaries and a migration order are agreed, starting with the capability that returns the most for the least risk.
- 3Per service, 3–6 weeks
Extract, one by one
Each service is built, run in parallel with the old code, then given live traffic behind the routing layer.
- 4Ongoing
Retire and operate
Old code paths and tables are removed once verified; services are monitored and supported under the SLA.
Case study · Logistics
Ten-plus workflows on one record, invoicing 75% faster
A logistics operator had customer, shipment and billing data siloed across tools and re-keyed by hand. We unified it into one CRM on Appwrite, MongoDB and Vercel.
Read the Logistics CRM case study →- Workflows unified
- 10+
- Faster invoicing
- 75%
- Source of truth
- 1
Questions CTOs ask
Do we actually need microservices?
Not always. If the main problem is code organisation rather than scaling or team independence, a modular monolith is cheaper to run. The assessment gives you a written recommendation either way.
Will customers notice the migration?
They should not. Traffic moves gradually to each new service behind the same URLs, with automatic fallback to the old path if error rates rise.
How do you handle the shared database?
Carefully, and last. Each service first reads through an API, then takes ownership of its tables with change-data capture keeping both sides in sync until the switch is verified.
Won't more services mean higher hosting costs?
It can. We size each service independently and only split out what benefits from it, so heavy components scale on their own while the rest stays small.
Can our in-house team take it over?
Yes. We pair with your engineers during extraction and hand over runbooks, dashboards and architecture decision records for every service.