One of the very frequently asked open-ended interview questions is – Can you describe the high-level architecture of a recent application you had worked on? | ⏯ Java based high-level architecture & Integration Styles Interview Q&As Video.

You will be asked:

1) to draw an architectural diagram on a white board and

2) to provide a brief description of the architecture, and

3) to elaborate on decisions, pros, cons, challenges, risks, etc ….

Q1 to Q7 will prepare you for this.

Q1. What are the different application integration styles?

A1. Enterprise systems don’t stand-alone. They integrate with many other corporate systems to provide mission critical services to the clients. There are a number of different integration styles like

#1 Shared database

where multiple applications share the same database. This approach is simple, but has disadvantages such as

1) More likely to hit performance & bottlenecks and scalability issues. SQL Databases don’t really scale.

2) Any adjustments (e.g. version upgrade) to the database for one application will have side effects on other applications. Complicates indexing and table partitioning as different applications have different needs.

3) Concurrency & timing issues as there could be chronological dependencies among processes that share the database. What about different applications working on the same tables concurrently? What if one application modifies the data that should have been altered by another application first?

#2 Batch file transfers

Applications will have their own databases, and the data from one application will be copied into another application’s database via an over-night or regular interval batch jobs with an ETL (i.e. Extract Transform & Load) process. Extract from one database and transform them into feed files (e.g. CSV or TAB delimited). These feed files are then loaded or ingested into another application’s database.

Why make copies of the data? An order placement application will require customer or product information. Only one application will be the source of truth and can create or modify the data, and the other applications will use the data as read only.

A typical industrial example would be that a Java & Spring based online ordering application requiring data from a legacy mainframe system. You can also bring in data from external organizations.

Disadvantages of ETL are:

1) Not ideal for near real-time (i.e. NRT) or on-demand data access that requires fast response.

2) Not only takes lots of considerations & time to develop, but also difficult to keep up with changing requirements.

[ ETL architecture & process interview Q&As | ETL/ELT on BigData Interview Q&As]

#3 Invoking R emote P rocedure C alls (i.e. RPC)

RPC is an inter-process communication that allows one program to directly call procedures in another program either on the same machine or another machine on the network. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure (i.e. a block of code) with supplied parameters. The remote server sends a response to the client, and the application continues its process.

RPC is the earliest & simplest form of API using the “request–response” protocol. When this is implemented over HTTP or AMQP it becomes a Web API. You build Web APIs using REST, GraphQL, gRPC, and SOAP. A Web API is an A pplication P rogramming I nterface for either a web server or a web browser. Web APIs expose service(s) via endpoints on a server where clients can connect via HTTP to use that service(s). Clients can be a browser, mobile device or a web service client on another web server.

For example: JSON, XML, or protobuf (i.e. efficient binary format) data can be exchanged between App1 and App2 in language agnostic manner.

App1 (REST client aka consumer) ==> JSON ==> App2 (REST service provider)

App1 (i.e. gRPC stub) ==> protobuff ==> App3 (i.e. gRPC Server)

Spring supports inter-process communication via Web Services JAX-RS (i.e. RESTful web service) & JAX-WS (i.e SOAP Web service), which are successors of JAX-RPC. gRPC is an open source remote procedure call library with best practices patterns, and uses HTTP/2 for transport and protocol buffer as the interface definition language (i.e. IDL). gRPC provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts. It generates cross-platform client and server bindings for many languages.

One of the biggest differences between REST and gRPC is the format of the payload. REST messages typically contain JSON, whereas gRPC accepts and returns Protobuf messages, which are binary. Microservices is where gRPC really shines since it enables low-latency and high-throughput communication as well as strong API contracts. Whilst gRPC is better than REST for most of the things, there’s one thing that REST is still better, which is the browser support. REST is fully supported by all browsers, and the support for gRPC is limited and requires gRPC-web with a proxy layer to convert between HTTP/1 and HTTP/2. gRPC is a great choice for a network-constrained environment such as mobile applications (i.e. android/ios) due to its light-weight message format.

When creating RESTful web services backed by a formal contract, you can choose between two approaches: contract-last and contract-first. gRPC is strictly contract-first. Services and messages are defined in “.proto” files and the relative server and client stubs are auto-generated using the gRPC toolset in any of the supported languages including Java.

GraphQL is a Web API works with a one endpoint with only “POST” verb, and exchanges JSON data. It is stateless like REST APIs. In REST APIs the designers decide which URL Paths as GET/Users, GET/Users/1, GET/Addresses, GET/Addresses/2, etc, what verbs as in GET/users/1, POST /users/1, PUT /users/1, DELETE /users/1, etc and optionally what request body as in JSON payload, etc use.

POST /users/1 {name: "Peter"} 1 2 3 POST / users / 1 { name : "Peter" }

But in GraphQL, you only have one endpoint and only POST request with the request body containing the query to retrieve the required data.

POST /graphql {query: 'query"....'} 1 2 3 POST / graphql { query : 'query"....' }

Requesting GraphQL API to return user name:

query { viewer { user { name } } } 1 2 3 4 5 6 7 8 query { viewer { user { name } } }

Response:

{ "data": { "viewer": { "user": { "name": "Peter" } } } } 1 2 3 4 5 6 7 8 9 10 { "data" : { "viewer" : { "user" : { "name" : "Peter" } } } }

You can use https://graphql.buildkite.com/explorer to explore more on GraphQL. In GraphQL you can instruct it to bring back only the data you need. In the above example it only brings back user name. There are other operation types like “mutation” to update existing data or add new data & “subscription” for live subscriptions where server informs client of any events via WebSockets in addition to the “query” operation type. WebSocket uses HTTP as the initial transport mechanism, but keeps the TCP connection alive after the HTTP response is received.

There are other protocols like RMI, Spring’s HTTP Invoker, Hessian, and Burlap for inter process communication.

#4 Messaging (i.e. events driven) via MOM (i.e. M essage O riented M iddleware)

This is also an inter-process communication whereby exchanging messages asynchronously over a message oriented middleware (MOM) like Apache Kafka, Websphere MQ, Rabbit MQ, etc. MOM is useful for asynchronous request-reply or publish-subscribe messaging because a request may take a long time to complete or several parties may be interested in the actual message.

Spring supports both JMS and AMQP . [ Asynchronous processing in Java real life examples.]

A real world example is that of a web application that is used to place orders or trades for customers. Your application taking orders on-line will save the order to a database & publish a message onto a JMS queue. Another application listening to the queue will respond to the event by taking the order and then placing that order with another third party system (e.g. a trading system). The third application may be responsible for taking the order and sending emails on order statuses such as confirmation and completion. All these events take place asynchronously. [ Asynchronous processing in Java real life examples]

Monolithic Vs. Micro Services

#3 & #4 can be architected as a

1) Monolithic application where all the business capabilities like managing products, placing orders, shipping orders, invoicing customers, etc will be using the same database, infrastructure & similar/same technologies.

OR as a

2) Micro services architecture where each business capability will be an independent service having its own database, infrastructure & programming language. This has the advantages of being able to independently scale an individual service, independently deploy a service more frequently, looser coupling of services, separate teams can manage & specialise in different services, parallel development, independent testing of services and if a service is down the site can still function with the other services.

This flexibility of micro services architecture comes at a price of more complexity due to more moving parts in the architecture. Also, it requires good architects & designers to set the right boundaries & granularity for the services. Eric Evans’s Domain Driven Design principles are very useful to define the granularity of a service. [10+ Domain Driven Design (i.e. DDD) Interview Q&As]. A number of patterns & best practices need to be applied to make the services resilient (i.e. handling failures & monitoring).

There are two approaches for developing modern applications using microservices:

1) Start a new application using microservices architecture right away, or

2) Start with a monolith and then gradually split and migrate to microservices. This is because

a) Setting up the initial base infrastructure for microservices from scratch can be time-consuming,

b) As the monolith application grows in size, it becomes much clearer and easier to identify functional boundaries for potential refactoring into microservices with minimal effort.

Q2 – Q7 Java architectural patterns interview Q&As

Q2: How does a Java EE application integrate with other systems?

Q3 – Q8 Java architectural patterns interview Q&As

Q3. Can you discuss some of the high level architectures you are experienced with?

Q4. In your experience, what are some of the common architectural and development mistakes?

Q5. What causes performance issues in Java?

Q6. In your experience, what are some of the key security considerations in an enterprise Java application?

Q7. Can you list some key software design principles?