Insights · 5 min read
Most architecture advice is written for greenfield unicorns. On real projects, boring choices and clear boundaries are what actually hold up.
By GGP Editorial
Most architecture advice assumes you have fifty engineers and a runway measured in years. Most real projects have eight people and a deadline. That gap is where bad architecture decisions happen, and they are expensive to undo later.
At GlobeSoft we have shipped more than 300 projects, from trading systems to property platforms, and the ones that stay maintainable share a few unglamorous habits. None of them are exciting. They are the reason a system still makes sense two years after launch.
Microservices are a scaling strategy, not a default. When a startup splits a simple product into twelve services before it has customers, it buys deployment complexity and network debugging without getting any of the benefits. I have watched teams spend more time on service-to-service communication than on the actual product, and watched that choice show up in every sprint that followed.
A monolith with clear internal modules gets you most of the benefits at a fraction of the cost. You split a service out when you have a specific reason: one part of the system needs to scale on its own, or one team owns it and ships on a different schedule. Until then, resist the urge. Extra services mean extra failure points and extra places for a bug to hide.
The honest test is boring but it works. Can a new developer run the whole system on their laptop in under ten minutes? If not, the architecture is already too complicated for the team size.
Most database debates are about fashion, not data. The right question is what your queries actually look like, and how often the answers need to be correct.
| Situation | What usually fits |
|---|---|
| Ledgers, payments, inventory that must never lose a record | PostgreSQL or MySQL with transactions |
| High-volume reads that tolerate some lag | Redis cache in front of the primary store |
| Documents or content with a flexible shape | MongoDB |
| Search-heavy product catalogs | Elasticsearch, fed by your primary database |
For financial and payment systems we default to relational databases, because the transaction guarantees matter more than developer convenience. A property rental system we built records rent payments and deposits; losing a row there is not an option, so it runs on MySQL with careful indexing rather than something trendier. The client never notices the database choice. They notice that the numbers reconcile at the end of every month.
The most useful architecture work happens before code, in a plain document or on a whiteboard. Decide what belongs in each module and, more importantly, what does not. Most tangled systems are not bad code; they are unclear ownership. Two modules both writing to the same table. A shared utility that everything imports. A service that reads another service's database directly. Each one seems fine on the day you write it and becomes a problem the week you try to change it.
A short architecture note at the start of a project, even five paragraphs, pays for itself during the first integration. It is also the document you hand a new developer on day one, which beats an hour of tribal knowledge.
Every system ships, and every system gets changed. The architecture that matters is the one that survives the first round of changes. When we build a multi-market trading system for a brokerage, the first version covers Hong Kong and US stocks, and the client expects A-shares later. So the market layer is built to add a new market as configuration plus a connector, not as a rewrite. That one decision saved the client months when the third market arrived.
The same habit shows up in smaller work. A restaurant POS system we built started as order and payment, then added inventory and delivery later. Because the order model was clean from the start, those features slid in without a migration nightmare.
We have done this across timezones, for clients in Brazil, South Africa, Singapore, and the United States. Overlap hours and a dedicated channel in English or Portuguese keep an architecture review from turning into a week of email tag. Architecture decisions are hard enough to make once; they should not get lost in translation or a twelve-hour reply cycle.
None of this is exotic. It is mostly restraint: fewer services than you think, a database that matches your queries, clear boundaries, and designs that assume change. Those four habits are the difference between a system you maintain and a system you rewrite.
If you are planning a build and want to talk through the architecture before the first line of code, Talk to us about your project
Tell us what you are building and where you are today. We typically reply within 24 hours.
