Advanced · Copies everywhere, until the network splits.
Replication & CAP
Copies of a database in several places make reads fast and survive failures. But copies lag, and when the network between them breaks you have to choose: refuse requests and stay consistent, or keep answering and reconcile later.
Try this
Run each experiment in the simulator above, then tick it off.
Key ideas
Replication lag
Copies catch up after a delay, so reading right after writing can show old data.
CAP in one line
During a network partition a system picks consistency (refuse) or availability (answer, maybe wrongly).
Conflicts need a rule
Last write wins is simple, but it silently drops the other side's write.
In your Pabbly workflows
You meet replication lag constantly: an API that says “not found” for a record you created a second ago. When step 2 reads what step 1 just wrote, use the ID step 1 returned instead of searching, or add a short delay.
Check yourself
0/2Get every question right to mark this lab done. Wrong answers let you try again.
Q1. You create a contact, then immediately search for it and get “not found”. Most likely cause?
Search usually reads from a replica or an index that updates a moment later.
Q2. During a partition, an AP system…
Availability means it answers. The price is that the two sides can disagree until the network heals.
Lab complete
Marked done on this device. On to the next one.
Watch next
Searches for “CAP theorem replication” on the channels worth your time.