Backend Architecture
1 patternHow an enterprise Java backend is structured so it can keep changing.
View patterns →Architecture Gallery
Not a tutorial and not documentation — a curated look at how architectural decisions actually get made: patterns organized by engineering concern, five named production systems examined in depth, the specific decisions behind them, and the principles that keep recurring. Every pattern either comes from a verified system, linked below it, or is explicitly labeled a generic pattern with no claimed production instance.
10 categories · 12 patterns · 9 decision records
Ten engineering concerns, each with at least one pattern below — grouped by what the pattern is for, not by which technology implements it.
How an enterprise Java backend is structured so it can keep changing.
View patterns →Splitting a system into independently deployable, independently scalable services.
View patterns →Establishing who a caller is, and trust across an organizational boundary.
View patterns →The integration surface a service exposes to the rest of the system.
View patterns →Moving state between services as an explicit sequence of events.
View patterns →Keeping latency-sensitive read paths fast without overloading the system of record.
View patterns →Making a running system's behavior inspectable without reproducing it locally.
View patterns →Getting a change from merged to running in production, repeatably.
View patterns →Grounding and structuring LLM-based systems around real source data.
View patterns →Enforcing access control centrally rather than scattering it through business logic.
View patterns →A handful of shapes show up in more than one category above — each is explored as individual cards and decision records elsewhere on this page.
Each card names a real decision behind it, or is labeled a generic pattern with no claimed production instance — never a blend of the two.
How an enterprise Java backend is structured so it can keep changing.
Give a growing enterprise codebase a structure that can absorb new features and a growing team without a rewrite.
Splitting a system into independently deployable, independently scalable services.
Let independently-changing parts of a system scale and deploy on their own schedule.
Establishing who a caller is, and trust across an organizational boundary.
Give every deployment of a multi-tenant platform the same, centrally-reviewable authentication model.
Establish trust and tenant isolation across an organizational boundary the platform doesn't fully control.
The integration surface a service exposes to the rest of the system.
Give a service a well-understood, broadly-tooled integration surface for both internal and external callers.
Moving state between services as an explicit sequence of events.
Make a multi-step business process inspectable and recoverable at every intermediate step.
Keeping latency-sensitive read paths fast without overloading the system of record.
Keep latency-sensitive read paths fast without adding load to the system of record.
Making a running system's behavior inspectable without reproducing it locally.
Make a distributed system's behavior inspectable without attaching a debugger to a specific instance.
Stop a failing downstream dependency from taking the calling service down with it.
Getting a change from merged to running in production, repeatably.
Make releases repeatable and reduce the manual steps between a merged change and it running in production.
Grounding and structuring LLM-based systems around real source data.
Reduce an LLM's tendency to answer confidently from its parameters alone by grounding its output in real source data.
Enforcing access control centrally rather than scattering it through business logic.
Enforce a single, consistent authorization model at the framework layer rather than scattering access checks through business logic.
Five named, verified systems — architecture summary, decisions, and stack from each case study.
Opal BPM India Pvt Ltd
A standardized OAuth2 authentication and authorization system rolled out across multiple client deployments of Opal's platform.
An OAuth2-based authorization layer sitting in front of Opal's Spring MVC / Spring Boot services, using Spring Security for enforcement, providing a single, consistent authentication and authorization model that every client deployment adopts instead of a bespoke per-client scheme.
Standardize on OAuth2 as the single authentication/authorization model across all client deployments.
Why — A common, well-understood standard reduces the security review burden per client and lets the platform team reason about access control once instead of per-deployment.
Technology stack
Opal BPM India Pvt Ltd
A 16-microservice trading platform matching buyers and sellers across multi-tenant e-waste categories, run at 99.9% uptime.
The platform is composed of 16 interconnected microservices on Java 21 and Spring Boot 3.4.13, covering buyer/seller order management, trade matching, settlement, and notifications. PostgreSQL is the system of record; Kafka carries the event flow between services (orders → matching → settlement → notification); Redis supports low-latency lookups and caching in the matching/notification path.
Decompose the platform into 16 focused microservices rather than a smaller number of broader services.
Why — Order intake, trade matching, settlement, and notification have distinct scaling and change profiles per tenant and waste category — separating them let each evolve and scale independently.
Tradeoff accepted — More services to operate, deploy, and monitor, and more discipline required in inter-service contracts and versioning.
Use Kafka as the backbone for order-to-settlement event flow.
Why — Trade matching and settlement are inherently event-driven (an order placed, matched, and settled is a sequence of state transitions across services) — Kafka gives durable, ordered delivery and lets notification consume the same event stream without coupling to the transactional path.
Technology stack
Opal BPM India Pvt Ltd
Opal's core product lifecycle, regulatory compliance, and packaging artwork management platform for private-brand retailers — architected and built from the company's second employee onward.
A distributed, service-oriented enterprise application built on the Spring stack (Spring MVC → Spring Boot as the platform matured), with ExtJS and later React on the client side, deployed via AWS EC2 and Docker with Jenkins-driven CI/CD.
Evolve the platform from Spring MVC toward Spring Boot and Microservices as it scaled.
Why — As the client base and feature surface grew, moving toward Spring Boot and a microservices decomposition supported independent scaling and deployment of platform capabilities rather than a single monolithic release train.
Migrate the frontend from ExtJS toward React over the platform's lifetime.
Why — ExtJS met the platform's early enterprise-UI needs; React was adopted as the ecosystem and hiring pool shifted, without a full-stop rewrite.
Technology stack
Personal project
A personal product built to make part of the hiring workflow easier — full scope to be confirmed.
Technology stack
Personal project
Retrieval-augmented generation work applying LangChain-based pipelines to ground LLM output in real source data.
Technology stack
Every decision already on record for the five case studies above, one ADR per decision — collapsed by default; expand any of them for context, alternatives, and consequences.
Enterprise Exchange Platform
Beckn Protocol Verification Adapter
OAuth2 Authentication Platform
Enterprise Artwork Management Platform
Financial Transaction Platform
A conceptual layering for a Java enterprise backend — each layer shows only the verified technology that actually belongs there.
Java
Spring Boot
REST APIs
Security
Messaging
Databases
Deployment
Conceptual, not a deployment diagram
Five maxims, each tied to one already-verified decision that put it into practice.
Design for maintainability.
An architecture only earns its keep if it can be changed later without a rewrite — Opal's platform moved from Spring MVC toward Spring Boot, and its frontend from ExtJS toward React, incrementally and in production, rather than as a stop-the-world migration.
Read the case study →Prefer composition over duplication.
Standardizing OAuth2 across multiple independently-run client deployments replaced N separate, bespoke authentication implementations with one shared, centrally-reviewable capability every deployment composes with.
Read the case study →Measure before optimizing.
The 30% reduction in production-issue resolution time at InterGlobe is a measured before/after outcome of a specific ownership change, not a general performance claim.
Read the case study →Automate repetitive work.
Deployment for Opal's platform runs through a Jenkins-driven CI/CD pipeline rather than manual release steps, once the team and release cadence grew past what manual deployment could keep up with.
Read the case study →Build reusable platforms.
Opal's artwork-management platform is one codebase serving its entire private-brand retail client base, not a fork per client — the same reuse principle behind standardizing OAuth2 once across those same deployments instead of per-client.
Read the case study →