Modernadvanced
Hybrid Architecture: Microservices Alongside z/OS
Understand common hybrid architecture patterns where cloud-native microservices coexist with and depend on core mainframe systems of record.
Very few modernisation programmes leave the mainframe entirely. The realistic shape is new services alongside it, with the mainframe still the system of record.
A hybrid mainframe/microservices architecture is like a historic, still fully operational central bank vault (the mainframe's systems of record) with modern digital banking apps and services built entirely around it — nobody's ripping out the vault, because it's still the most secure and reliable place for the actual assets; the new apps simply need well-designed doors and secure channels to interact with it.
Key Concepts
1
Why it stays. The core data and transactions are there, they are correct, they are audited, and the
throughput is genuinely hard to replicate. Moving them is the highest-risk thing available.
2
The strangler fig pattern. New capability is built outside; existing capability is called rather than
copied.
3
mobile app ---> API gateway
|
+---------+---------+
| |
new microservice z/OS Connect
(notifications, |
preferences) CICS / DB2
the system of record4
Over time, more sits in front. The core is replaced last, or not at all.
5
The rule that keeps it honest: one system owns each piece of data. The failure mode is a microservice
that keeps its own copy of account balances "for performance", and the two diverge.
6
Whatever is authoritative on the mainframe stays authoritative. Services cache it and do not own it.
7
Events decouple the two sides. Rather than services polling for changes, the mainframe publishes them —
CICS or DB2 change data capture onto Kafka:
8
DB2 change -> CDC -> Kafka topic -> any number of consumers9
Consumers are added without touching the mainframe, which is the same argument as any event-driven design
and matters more here, because changing the mainframe side is expensive.
10
What the mismatch costs. Two operating models meet: one deploys weekly through a change process, the
other deploys continuously. One is measured in MIPS, the other in instances.
11
Teams that ignore this design a chatty service that makes ten mainframe calls per request and discover the
cost at the end of the month, because every call consumes chargeable capacity.
12
So the design constraint is call volume, not latency. Coarse endpoints, caching of reference data, and
events instead of polling — all for the same reason.
13
The informed position. Not "migrate off the mainframe", which is rarely funded and rarely finished.
Put new work where it is cheap to build, keep the system of record where it is proven, and be deliberate
about the boundary between them.
14
What the interviewer is probing.1. "Where should the boundary sit?" Probing: the architecture. Stalls: "Anywhere." *Moves
up:* around the system of record — the mainframe keeps authoritative transactional data and new
services own new capability, talking through explicit contracts.
15
2. "What is the usual failure of a strangler migration?" Probing: experience. Stalls: "It is
slow." Moves up: the new service duplicates data and the two drift, because nobody decided which
side is authoritative for each field.
16
3. "How is data kept in step?" Probing: the mechanism. Stalls: "Nightly batch." Moves up:
change data capture from DB2 to an event stream for near-real-time propagation, with batch
reconciliation to catch drift.
17
4. "What is the hardest non-technical part?" Probing: honesty. Stalls: "Nothing." *Moves
up:* the knowledge is in people who are retiring, and the existing behaviour is the specification —
which is why documenting before rewriting matters.