From Monolithic- to Micro Service Architecture 2/4

From Monolithic- to Micro Service Architecture 2/4

The Semi-Monolith

semi-monolithA ‘Semi Monolith’ is a setup where your application is split into exactly two parts. Usually it does not follow the SOA paradigm but has been constructed this way for a special reason. I came in touch with it three times and gonna share my experience in this second part of my series. My gut feeling is that this setup has its place in the development universe.

Java – Postgres

A Rocket venture I worked for as CTO some years ago in Berlin was running a Java Spring application powered by a PostgreSQL database. Exotic in this case was, that most of the application logic was running in the database  wired into stored procedures. The fact that every user requested ended up in exactly one Stored Procedure call made the application quite performant. The Stored Procedure itself triggered all consecutive internal calls and returned a single object back to the calling Java application. The Java business layer was quite thin and acted de facto  as a caching and controller layer. This setup has been quite successfully used by Skype before us and turned out to work quite well for a while.

We were running into the following challenges:


  • Master – Slave Postgres setup introduced a single point of failure and could only be scaled up, not out
  • DB Migration scripts + respective schema information were required to be versioned to facilitate a roll forward and backward
  • Rollout was processed in two steps, started with the DB part followed by the Java application
  • Postgres Developers were needed which was a challenged back then in 2009 in Berlin, Germany
  • Keeping the one-call-per-user-request policy up turned out to be a tough challenge especially with the introduction of Ajax based communication
  • We lost a lot of development performance on the interface between Java and Postgres due to the nature of that interface and the fact that mocks for Postgres responses were hard to code.


One of Rocket’s biggest success stories, the e-commerce platform “Alice & Bob”  is build around that ‘Semi-Monolithic’ architecture. A lightweight PHP frontend layer (Alice) acts as shop frontend and fetches all product and category related information from a fast key/value store. The backend layer (Bob) is build around a full-blown framework and acts as de facto zendbusiness layer for the whole shop. It houses the configuration of the shop, manages the communication with the storage layer for all transaction related activities and provides a basic reporting system. We faced the following challenges:

  • CPU burn of PHP forced us to scale out early which came along with high OPEX for infrastructure
  • Drivers for third party components like RabbitMQ were not operating stable under load
  • Going from here to any real SOA solution was a highly complex and a painful undertaking
  • Housing reporting, shop configuration and all DB related functionality in a single none cluster-able layer introduces a massive risk for scaling out the platform

PHP – Java

The third and most promising of the Semi-Monolithic setups I worked with uses PHP as its frontend layer and Java/Spring  as Webservice. We built an eWallet application around that stack and were quite happy with it for a while. The clear separation between view/controller- and  business layer on the other side allowed us to scale the platform out selectively.

We faced the following challenges:

  • springDue to the nature of a financial platform, we were suffering from a massive CPU burn on the Java layer mainly caused by many encryption/decryption operations and the absence of a HSM (quite expensive for a startup with a platform deployed to multiple DC’s)
  • Even though we followed the service orientation paradigm , all domains were deployed into a single DB schema referencing each other via foreign-key constraints. This is good DB design, but introduces problems while migrating them into self contained SOA services.
  • We were handling multiple levels of complexity within the java application. Managing / extending very low level modules (e.g. Accounting / Wallet) require development seniority which is usually spread across the available teams
  • The application was designed and built in a synchronous way. This becomes a pain point for every fintech application as they tend to work extensively with external providers and their respective APIs.

Take away

takeAwayMe personally, I would always go with the latter setup. Java with its huge ecosystem has proven to be a very solid business option for enterprise applications. On the frontend layer however, a pure Java application behaves a bit like a behemoth and requires some basic Java skills to be mastered. From a pure feature throughput perspective I would go with some lightweight technologies like PHP, React or Angular for the frontend layer as they are relatively easy to learn and some guys really get sh!@t done with it.

Author: Thorsten Maus

Grown up in Berlin, Germany
Starting coding with 12 years on a Z80 processor
First contact with the internet in 1994 in Dublin

Living in Singapore

CTO Jobs:
helloPay (current)
Lazada (Special Projects)

Leave a Reply

Your email address will not be published. Required fields are marked *