Liferay Microservices Communication Guide (Enterprise Architecture)

February 16, 2026

Modern portals are no longer monolithic.

Today, Liferay acts as a digital experience layer while business logic lives in independent microservices.

This means the most important design decision becomes:

👉 How Liferay communicates with microservices

In this guide you’ll learn all production communication patterns.

📌 Why Microservices with Liferay?

Old architecture:

Portal → Database → Business Logic inside portal

Modern architecture:

Portal → APIs → Microservices → Databases

Benefits:

Independent deployment
Better scalability
Easier upgrades
Domain separation

🖼️ High Level Architecture

🧠 Communication Patterns Overview

There are 4 enterprise patterns:

REST APIs (most common)
Event-driven messaging
GraphQL gateway
Async job workers

Each has different purpose.

🔹 1️⃣ REST API Communication (Synchronous)

Best for real-time UI responses.

Example:
User updates profile → Call customer service

Liferay Java Client


URL url = new URL("http://customer-service/api/profile");
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("POST");
con.getResponseCode();

Use when user waits for response.

🖼️ REST Flow

🔹 2️⃣ Event-Driven Messaging (Asynchronous)

Best for background processing.

Example:
Document upload → processing → notification

Portal publishes event → services react.

Technologies:

Kafka
RabbitMQ

Portal never waits.

🖼️ Event Driven Flow

🔹 3️⃣ GraphQL Gateway

Best for aggregating multiple services.

Instead of 5 REST calls → single query.

Benefits:

Faster frontend
Reduced network calls

🖼️ GraphQL Aggregation

🔹 4️⃣ Background Job Workers

Used for long processing tasks.

Example:
Generate PDF report
Bulk import users

Portal triggers job → worker processes later.

🖼️ Background Worker Flow

⚖️ When to Use What

Scenario	Best Pattern
User waiting	REST
Heavy processing	Async events
Multiple services	GraphQL
Long tasks	Workers

🔐 Security Considerations

Use:

OAuth2 / OIDC
API Gateway
Token forwarding
Rate limiting

Never expose services directly to internet.

🏆 Best Practices

✔ Keep portal thin
✔ No business logic in Liferay
✔ Use gateway layer
✔ Prefer async when possible
✔ Design domain-based services

⚠️ Common Mistakes

❌ Database sharing
❌ Large synchronous chains
❌ Portal orchestrating everything
❌ Tight coupling APIs

🎯 Conclusion

Liferay should act as:

👉 Experience layer only

Microservices handle business logic.

Correct communication pattern ensures scalable enterprise architecture.

💼 Need Help with Liferay, Alfresco, Jira, or Enterprise Content Management?

I help teams solve real production issues and build scalable systems.

Services I offer:
• Liferay, Alfresco setup, customization, and integration
• Repository structure design and content modeling
• Workflow implementation (jBPM / Activiti / APS)
• Java backend development, multithreading, and concurrency optimization
• Performance tuning and production issue troubleshooting
• Java, Spring Boot & microservices architecture
• Production issue troubleshooting

🔗 View Services: https://shikhanirankari.blogspot.com/p/professional-services.html

📩 Email: ishikhanirankari@gmail.com | info@realtechnologiesindia.com
🌐 IT Trainings | Digital metal podium

✔ Available for quick consulting calls and project-based support
✔ Response within 24 hours

🎥 Learn IT with Shikha on YouTube

Prefer learning through videos? Watch practical tutorials on Kafka, Camunda, Alfresco, Java, Spring Boot, Microservices and Enterprise Architecture.

▶ Subscribe to Learn IT with Shikha on YouTube

Search This Blog

Learn IT with Shikha Blogs