Architecture for a new or growing system
We decide how the system is split, where the data flows and what happens as load grows, with every decision written down and explained.
Who it's for
For companies building a new system, or whose current system has become hard to change.
What it solves
- Every small change touches parts of the system that had nothing to do with it.
- The team argues about microservices without knowing whether the problem calls for them.
- Nobody remembers why a decision was made, so changing it feels risky.
- The system slows down at month-end close and nobody knows where the bottleneck is.
What we do
- Module boundaries
- Which parts of the system stay together, which are separated and how they talk to each other.
- Modular monolith or services
- The split that the size of the team and the problem justifies, not the fashionable one.
- Data flow
- Where each piece of data is created, who owns it and which systems it passes through.
- Load and capacity
- Volume estimates, predictable peaks and what needs to scale first.
- Where the data lives
- Cloud, region and hosting in Brazil or abroad, discussed with whoever answers for the data.
- Decision records
- Each significant decision written down with its context, the alternatives and the reason for the choice.
- Planned failure modes
- What happens when a service, a queue or an external supplier stops responding.
What you get
- Layered architecture diagrams, from context down to components
- A record of architecture decisions, including the alternatives ruled out
- Load estimates and the known limits of the design
- A list of technical risks, with a suggested order for tackling them
- Criteria for checking that the build followed the architecture
How we do it
Context
Business goals, expected volumes, the available team and constraints already known.
Alternatives
Two or three ways to build the system, with the costs and risks of each.
Decision
A choice made with your team and recorded with its reason.
Detailed design
Diagrams, contracts between modules and a path to production in stages.
Follow-up
Reviews during the build so the architecture does not stay on paper.
Technology examples
- C4 model
- ADR
- PostgreSQL
- Redis
- RabbitMQ
- Kafka
- OpenTelemetry
Related services
FAQ
Do you also build what you design?
We can, but the architecture also works for your own team or another supplier. The documents are written with that in mind.
Do we need microservices?
It depends on the size of the team, how many parts change at different speeds and the load. Often a well-divided monolith is enough for quite a while.
Does our data have to stay in Brazil?
That is your company's decision, taken with your legal team. We show the region options and what each one changes in cost and operations.
Does this work for a system that already exists?
Yes. We start from what is in production and propose changes in stages. When the system is old, that becomes legacy modernisation.
Write to Balkan
Talk to us about your project