You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/howtos/solutions/caching-architecture/write-behind/index-write-behind.mdx
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,6 +16,8 @@ import mongoCompassImage from './images/mongo-compass.png';
16
16
17
17
<AuthorsfrontMatter={frontMatter} />
18
18
19
+
<SourceCodeMovieApp />
20
+
19
21
## What is write-behind caching?
20
22
21
23
Imagine you've built a movie streaming app. You used MongoDB as your data store, and as you needed to scale you implemented caching using Redis. This allows you to drastically speed up reads. However, now you are experiencing slowness when writing to MongoDB.
Copy file name to clipboardExpand all lines: docs/howtos/solutions/microservices/api-gateway-caching/index-api-gateway-caching.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,7 +32,7 @@ While this works, you end up with a fair amount of duplicated code. Plus, it's d
32
32
33
33
Once you decide to handle authentication at the API gateway layer, you must decide where to store sessions.
34
34
35
-
Imagine you're building an e-commerce application that uses MongoDBas the primary data store. You could store sessions in MongoDB, but think about how many times the application needs to hit MongoDB to retrieve session information. If you have millions of customers, you don't want to go to MongoDB for every single request made to the API.
35
+
Imagine you're building an e-commerce application that uses MongoDB/ any relational database as the primary data store. You could store sessions in primary database, but think about how many times the application needs to hit primary database to retrieve session information. If you have millions of customers, you don't want to go to database for every single request made to the API.
36
36
37
37
This is where Redis comes in.
38
38
@@ -60,7 +60,7 @@ Use a **Redis Enterprise Cluster** to get the benefit of linear scaling to ensur
60
60
61
61
<SourceCode />
62
62
63
-
## API gateway caching in a microservices application with Redis and MongoDB
63
+
## API gateway caching in a microservices application with Redis
64
64
65
65
What's nice about a microservice architecture is that each service is set up so it can scale independently. Now, seeing as how each service might require authentication, you likely want to obtain session information for most requests. Therefore, it makes sense to use the API gateway to cache and retrieve session information and to subsequently pass the information on to each service. Let's see how you might accomplish this.
Copy file name to clipboardExpand all lines: docs/howtos/solutions/microservices/caching/index-caching.mdx
+37-72Lines changed: 37 additions & 72 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@ import cacheHitImage from './images/redis-cache-aside-cache-hit.png';
24
24
Have you ever been in a situation where your database queries are slowing down?
25
25
Query caching is the technique you need to speed database queries by using different caching methods while keeping costs down! Imagine that you built an e-commerce application. It started small but is growing fast. By now, you have an extensive product catalog and millions of customers.
26
26
27
-
That’s good for business, but a hardship for technology. Your queries to MongoDBare beginning to slow down, even though you already attempted to optimize them. Even though you can squeak out a little extra performance, it isn’t enough to satisfy your customers.
27
+
That's good for business, but a hardship for technology. Your queries to primary database (MongoDB/ Postgressql) are beginning to slow down, even though you already attempted to optimize them. Even though you can squeak out a little extra performance, it isn't enough to satisfy your customers.
28
28
29
29
## Why you should use Redis for query caching
30
30
@@ -99,7 +99,7 @@ If you use **Redis Enterprise** and a database that uses a JDBC driver, you can
99
99
100
100
<SourceCode />
101
101
102
-
## Caching in a microservices application with Redis and MongoDB
102
+
## Caching in a microservices application with Redis and primary database (MongoDB/ Postgressql)
103
103
104
104
In our sample application, the products service publishes an API for filtering products. Here's what a call to the API looks like:
105
105
@@ -114,32 +114,27 @@ In our sample application, the products service publishes an API for filtering p
114
114
115
115
### Get products by filter response (cache miss)
116
116
117
-
```json {30}
117
+
```json {25}
118
118
{
119
119
"data": [
120
120
{
121
-
"_id": 11000,
122
-
"data": {
123
-
"id": 11000,
124
-
"price": 3995,
125
-
"productDisplayName": "Puma Men Slick 3HD Yellow Black Watches",
If you're familiar with MongoDB, this code should be pretty straightforward. You simply make a call to MongoDBto find products based on a filter on the product’s `displayName` property. You also define a projection object to specify which properties to get out of MongoDB. You can set up multiple columns for better fuzzy searching, but we simplified it for the purposes of this tutorial.
185
+
You simply make a call to primary database (MongoDB/ Postgressql) to find products based on a filter on the product's `displayName` property. You can set up multiple columns for better fuzzy searching, but we simplified it for the purposes of this tutorial.
221
186
222
-
Using MongoDB directly without Redis works for a while, but eventually it slows down. That's why you might use Redis, to speed things up. The cache-aside pattern helps you balance performance with cost.
187
+
Using primary database directly without Redis works for a while, but eventually it slows down. That's why you might use Redis, to speed things up. The cache-aside pattern helps you balance performance with cost.
223
188
224
189
The basic decision tree for cache-aside is as follows.
225
190
@@ -228,7 +193,7 @@ When the frontend requests products:
228
193
1. Form a hash with the contents of the request (i.e., the search parameters).
229
194
1. Check Redis to see if a value exists for the hash.
230
195
1. Is there a cache hit? If data is found for the hash, it is returned; the process stops here.
231
-
1. Is there a cache miss? When data is not found, it is read out of MongoDB and subsequently stored in Redis prior to being returned.
196
+
1. Is there a cache miss? When data is not found, it is read out of primary database and subsequently stored in Redis prior to being returned.
232
197
233
198
Here’s the code used to implement the decision tree:
Copy file name to clipboardExpand all lines: docs/howtos/solutions/microservices/common-data/microservices-arch-with-redis.mdx
+8-2Lines changed: 8 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,5 +6,11 @@ The e-commerce microservices application discussed in the rest of this tutorial
6
6
1.`payments service`: handles processing orders for payment
7
7
1.`digital identity service`: handles storing digital identity and calculating identity score
8
8
1.`api gateway`: unifies services under a single endpoint
9
-
1.`mongodb`: serves as the primary database, storing orders, order history, products, etc.
10
-
1.`redis`: serves as the stream processor and caching database
9
+
1.`mongodb/ postgresql`: serves as the primary database, storing orders, order history, products, etc.
10
+
1.`redis`: serves as the **stream processor** and caching database
11
+
12
+
:::info
13
+
14
+
You don't need to use MongoDB/ Postgresql as your primary database in the demo application; you can use other <u>[prisma supported databases](https://www.prisma.io/docs/reference/database-reference/supported-databases)</u> as well. This is just an example.
Copy file name to clipboardExpand all lines: docs/howtos/solutions/microservices/common-data/microservices-arch.mdx
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,10 +5,10 @@ You eventually land on the following architecture:
5
5
1.`order history service`: handles querying a customer's order history
6
6
1.`payments service`: handles processing orders for payment
7
7
1.`api gateway`: unifies the services under a single endpoint
8
-
1.`mongodb`: serves as the write-optimized database for storing orders, order history, products, etc.
8
+
1.`mongodb/ postgresql`: serves as the write-optimized database for storing orders, order history, products, etc.
9
9
10
10
:::info
11
11
12
-
You don’t need to use MongoDBas your write-optimized database; you can use other databases such as a SQL database as well. This is just an example.
12
+
You don't need to use MongoDB/ Postgresql as your write-optimized database in the demo application; you can use other <u>[prisma supported databases](https://www.prisma.io/docs/reference/database-reference/supported-databases)</u> as well. This is just an example.
The e-commerce microservices application consists of a frontend, built using [Next.js](https://nextjs.org/) with [TailwindCSS](https://tailwindcss.com/). The application backend uses [Node.js](https://nodejs.org). The data is stored in
2
+
[Redis](https://redis.com/try-free/) and MongoDB. Below you will find screenshots of the frontend of the e-commerce app:
3
+
4
+
-`Dashboard`: Shows the list of products with search functionality
Copy file name to clipboardExpand all lines: docs/howtos/solutions/microservices/common-data/microservices-ecommerce.mdx
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
-
The e-commerce microservices application consists of a frontend, built using [Next.js](https://nextjs.org/) with [TailwindCSS](https://tailwindcss.com/). The application backend uses [Node.js](https://nodejs.org). The data is stored in [MongoDB](https://www.mongodb.com/) and [Redis](https://redis.com/try-free/). Below you will find screenshots of the frontend of the e-commerce app:
1
+
The e-commerce microservices application consists of a frontend, built using [Next.js](https://nextjs.org/) with [TailwindCSS](https://tailwindcss.com/). The application backend uses [Node.js](https://nodejs.org). The data is stored in
2
+
[Redis](https://redis.com/try-free/) and MongoDB/ Postgressql using [Prisma](https://www.prisma.io/docs/reference/database-reference/supported-databases). Below you will find screenshots of the frontend of the e-commerce app:
2
3
3
4
-`Dashboard`: Shows the list of products with search functionality
0 commit comments