[Google Pixel XL Questions & Answers] jisoo:
There's a fairly comprehensive article on a/b partitions here: https://source.android.com/devices/tech/ota/ab/. Though it is mainly from the perspective of an OEM/dev, it does describe what has changed and how quite clearly.

To summarize, in the olden days we used to have the following key partitions:

recovery

boot

cache

system

vendor

data

Both boot and recovery partitions included their own kernel images, and the bootloader/fastboot would decide whether the phone should boot into recovery or boot (and onwards to system).

With the a/b system, the partitions look following:

boot_a

boot_b

system_a

system_b

vendor_a

vendor_b

data

You will notice Google has gotten rid of both recovery and cache partitions. I suspect cache was removed to decrease the impact on available storage we get from having 2 system and vendor partitions (and also because it was no longer needed to store OTA update images, for instance). FYI, cache is now within the data partition at /data/cache.

As there is no dedicated recovery partition, instead recovery has now been integrated into the boot_a and boot_b partitions.

The general idea is that if user is using "a" partition (i.e. system booted from boot_a and is using system_a and vendor_a), then updates can be applied to "b" partition while the system is running. After the update has been successfully applied to "b" partition, the bootloader is told to set "b" partition active for next boot. Upon reboot, the bootloader will load boot_b, which in turn loads system_b and vendor_b, thereby "seamlessly" switching to the new system.

The next update will be applied to the "a" partition while the user is using the "b" partition, and the cycle continues.

The advantage is that if something goes wrong with the update (fails to apply or fails to boot), the bootloader can switch back to the original partition, and the phone remains usable.

The main headache for hobbyists like us here at XDA is the fact that we no longer have a nice, independent recovery partition to stick TWRP onto. Instead, we need to replace the stock recovery inside the boot partition, while leaving the rest of the boot partition intact.

Because it is not possible to modify partitions over fastboot (only overwrite them), it is necessary to first boot into TWRP by loading the recovery image from the PC (fastboot boot twrp.img), and then while in TWRP (which is running from RAM instead of disk), run the installer which pulls the boot image from the disk, patches the recovery files and pushes it back.

The TWRP installer does this for both boot_a and boot_b, to make sure the user is able to access a recovery regardless of which partition is active at any point in time.

The problem arises from the fact that other mods (magisk, supersu, xposed, custom kernels) also rely on modifying the boot partition, and therefore flashing any of these carries a risk of either replacing files already modified by TWRP, or making the boot image (or ramdisk) so large it no longer fits the partition.

Apart from the above complication, I personally much prefer the a/b partition scheme. For a lonely hobbyist like myself who prefers to build my AOSP images, when I wasn't sure if my build would boot fully or not, I used to have to go to TWRP and make backups of both boot and system partitions, so I can restore back working system if the new build didn't boot.

Now, I just switch the active partition and flash boot.img and system.img images to the corresponding partition. If it doesn't work, I set active back to the working partition, and try again after a new build.