what's the strong point when we use RDB(like postgresql) and ElasticSearch Concurrently? is there a good time to use this architecture?

Relational Database Management Systems (RDBMS) like PostgreSQL and NoSQL databases like Elasticsearch have their own unique advantages and are used for specific types of tasks based on their strengths.

PostgreSQL (RDBMS):

ACID Compliance: PostgreSQL provides Atomicity, Consistency, Isolation, Durability (ACID) properties, which ensure reliable processing of transactions.
Structured Data: PostgreSQL is excellent for managing structured data with complex relations.
SQL Queries: PostgreSQL uses SQL for querying, which is a powerful and standardized language for database management and data manipulation.
Integrity Constraints: PostgreSQL supports integrity constraints like primary key, foreign key, ensuring data consistency and accuracy.
Support for complex operations: PostgreSQL can handle complex operations and computations, such as joins and subqueries, which might not be possible in a NoSQL solution like Elasticsearch.
Elasticsearch (NoSQL):

Full-text Search: Elasticsearch is renowned for its full-text search capabilities. It provides fast, real-time search functionalities.
Scalability: Elasticsearch is designed to scale horizontally. It's easy to scale out by adding more nodes to the system.
Real-Time Analysis: Elasticsearch is excellent for log or event data analysis, allowing for real-time insights.
Flexible Schema: Elasticsearch can handle semi-structured and unstructured data effectively. It's suitable for diverse forms of data.
Geo-Spatial functions: Elasticsearch supports complex geo-spatial queries like distance and location-based searches.
In terms of architecture, a common pattern is to use both of these technologies in tandem:

Transactional and Complex Queries: You would use PostgreSQL to manage transactional data, handle complex queries, and manage data integrity.
Search and Analytics: You would use Elasticsearch for text search, data analysis, logging, and scenarios where you need fast, real-time insights.
This combined architecture can be beneficial in use-cases like an e-commerce application where PostgreSQL can handle transactional operations (like user info, orders, payments) and Elasticsearch can power the product search and analytics functionality.

As a rule of thumb, you should consider the needs and requirements of your specific project to decide whether this architecture is right for you. For instance, if your application heavily relies on text search and analysis but also needs to handle complex relations and ACID properties, combining PostgreSQL and Elasticsearch can be a very effective solution.

is there a tool for Ensuring data consistency between elasticSearch and RDB

Ensuring data consistency between two separate data stores like Elasticsearch and a relational database (RDB) like PostgreSQL can be challenging because they work in fundamentally different ways. There are however a few strategies and tools you could use:

Dual writes: One strategy is to write data to both systems at the same time. However, this can lead to inconsistency if one write fails and the other succeeds. This could be mitigated by using an atomic commit protocol (two-phase commit), although this adds complexity and can affect performance. It's also worth noting that Elasticsearch doesn't provide the same consistency guarantees as PostgreSQL, so there could still be temporary inconsistencies even if both writes succeed.

Change Data Capture (CDC): Change data capture (CDC) is a technique that captures changes made at the data source and applies them to the target systems. Tools like Debezium can capture changes in your RDB and push them to a message queue system like Apache Kafka. From there, changes can be consumed by a separate process and applied to Elasticsearch. This ensures that both systems have the same data without the need for dual writes or atomic commit protocols.

Logstash: Logstash, part of the ELK stack (Elasticsearch, Logstash, Kibana), can also be used to import data from RDBs into Elasticsearch. While this is more often used for the initial import of data, it could also be used in conjunction with a job scheduler to regularly sync data.

Custom Application Logic: You can write your own application logic that writes to the RDB first and then propagates those changes to Elasticsearch. In the event of failure, your application can implement retry logic, or flag the data for a future reconciliation process.

Remember, there's no silver bullet to maintain consistency across different data stores. The best strategy depends on your specific use-case, requirements, and the resources at your disposal. You also need to consider how much inconsistency (if any) your application can tolerate, and how you plan to handle failures when they occur.