ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ (Event sourcing) ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಪದೇ ಪದೇ ಓವರ್ರೈಟ್ (overwrite) ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಲು ಹೇಳುತ್ತದೆ. ಸಾಂಪ್ರದಾಯಿಕ CRUD ಅಪ್ಲಿಕೇಶನ್ನಲ್ಲಿ, ಬಳಕೆದಾರರ ಶಿಪ್ಪಿಂಗ್ ವಿಳಾಸವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡುವುದು ಎಂದರೆ ಆ ಸಾಲನ್ನು (row) ಹುಡುಕುವುದು, ಮೌಲ್ಯವನ್ನು ಬದಲಾಯಿಸುವುದು ಮತ್ತು ಹಿಂದಿನ ಸ್ಥಿತಿಯನ್ನು (previous state) ಕೈಬಿಡುವುದು ಎಂದರ್ಥ. ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ವಿಭಿನ್ನ ಹಾದಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯನ್ನು ಒಂದು ಬದಲಾಯಿಸಲಾಗದ ಸತ್ಯವಾಗಿ (immutable fact) ಸಂಗ್ರಹಿಸುತ್ತದೆ: ಬಳಕೆದಾರರು ಖಾತೆಯನ್ನು ರಚಿಸಿದ್ದಾರೆ, ವಿಳಾಸವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದ್ದಾರೆ, ಇಮೇಲ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದ್ದಾರೆ ಇತ್ಯಾದಿ. ಸಿಸ್ಟಮ್ನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ನೇರವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ. ಈ ಇವೆಂಟ್ಗಳನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಮರುಪ್ರತಿಷ್ಠಾಪಿಸುವ ಮೂಲಕ (replaying) ಅದನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.
ಈ ಮಾದರಿಯು ನೈಜ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಆಡಿಟ್ ಟ್ರೈಲ್ಸ್ (Audit trails) ಉಚಿತ ಉಪ ಉತ್ಪನ್ನಗಳಾಗುತ್ತವೆ. ಯಾವುದೇ ಹಿಂದಿನ ಕ್ಷಣದಲ್ಲಿ ಆರ್ಡರ್ನ ಸ್ಥಿತಿಯನ್ನು ನೀವು ಮರುನಿರ್ಮಿಸಬಹುದು. ಏನಾಯಿತು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಮರುಪ್ರತಿಷ್ಠಾಪಿಸುವ ಮೂಲಕ ನೀವು ಡಿಬಗ್ ಮಾಡಬಹುದು. ಇದರ ಸವಾಲೆಂದರೆ ಸಂಕೀರ್ಣತೆ (complexity). ನೀವು ಈಗ ಸರಳ ಸಾಲುಗಳ ಬದಲಿಗೆ ಸತ್ಯಗಳ ಸ್ಟ್ರೀಮ್ಗಳು (streams of facts), ರೀಡ್ ಮಾಡೆಲ್ಗಳು (read models) ಮತ್ತು ಎವೆಂಟುವಲ್ ಕನ್ಸಿಸ್ಟೆನ್ಸಿ (eventual consistency) ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ.
PostgreSQL ನಿಮ್ಮ ಇವೆಂಟ್ ಸ್ಟೋರ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು. ಹೆಚ್ಚಿನ ತಂಡಗಳು ಈಗಾಗಲೇ ಇದನ್ನು ಬಳಸುತ್ತಿವೆ. ಇದು ACID ಟ್ರಾನ್ಸಾಕ್ಷನ್ಗಳು, ನಮ್ಯತೆಯ ಪೇಲೋಡ್ಗಳಿಗಾಗಿ (flexible payloads) JSONB ಮತ್ತು ಸಾಬೀತಾದ ಬ್ಯಾಕಪ್ ಪರಿಕರಗಳನ್ನು ನೀಡುತ್ತದೆ. ಮೊದಲ ದಿನವೇ ನೀವು Kafka, Cassandra ಅಥವಾ ವಿಶೇಷವಾದ ಇವೆಂಟ್-ಸ್ಟೋರ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪರಿಚಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಒಂದು ಪ್ರಮಾಣಿತ Postgres ಇನ್ಸ್ಟೆನ್ಸ್ ನಿಮ್ಮ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಫುಟ್ಪ್ರಿಂಟ್ ಅನ್ನು ವಿಸ್ತರಿಸದೆ, ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಬಯಸುವ ಟ್ರಾನ್ಸಾಕ್ಷನಲ್ ಗ್ಯಾರಂಟಿಗಳು ಮತ್ತು ಆಡಿಟ್ ಟ್ರೈಲ್ಸ್ಗಳನ್ನು ನೀಡುತ್ತದೆ.
ಒಂದು Postgres ಇವೆಂಟ್ ಸ್ಟೋರ್ನ ಸ್ವರೂಪ
ಸ್ಕೀಮಾವನ್ನು ಅತ್ಯಂತ ಸರಳವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು. ಕನಿಷ್ಠ ಪಕ್ಷ, ಇವೆಂಟ್ಗಳನ್ನು ಸೇರಿಸುವ (append) ಮತ್ತು ಅವುಗಳನ್ನು ಎಂದಿಗೂ ಸ್ಥಳೀಯವಾಗಿ ಅಪ್ಡೇಟ್ ಮಾಡದ ಒಂದು ಟೇಬಲ್ ನಿಮಗೆ ಬೇಕಾಗುತ್ತದೆ. ಒಂದು ಪ್ರಾಯೋಗಿಕ ವಿನ್ಯಾಸ ಹೀಗಿರುತ್ತದೆ:
idಅನ್ನು bigserial ಅಥವಾ UUID ಆಗಿ ಬಳಸಿ, ಇದು ಗ್ಲೋಬಲ್ ಆರ್ಡರಿಂಗ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.- ಸಂಬಂಧಿತ ಇವೆಂಟ್ಗಳನ್ನು ಗುಂಪು ಮಾಡಲು
stream_id, ಉದಾಹರಣೆಗೆ ಒಬ್ಬ ಬಳಕೆದಾರ ಅಥವಾ ಆರ್ಡರ್ನ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳು. - ಪ್ಲೇನ್ ಟೆಕ್ಸ್ಟ್ ಆಗಿ
event_type:UserEmailChanged,PaymentReceived,InventoryAdjusted. - JSONB ಆಗಿ
payload, ಇದು ಆ ಘಟನೆಯ ನಿರ್ದಿಷ್ಟ ಡೇಟಾವನ್ನು ಹೊಂದಿರುತ್ತದೆ. - ಟೈಮ್ಜೋನ್ ನಿಖರತೆಯೊಂದಿಗೆ
occurred_at. - ಪ್ರತಿ ಸ್ಟ್ರೀಮ್ಗೆ
version, ಇದು ಆಪ್ಟಿಮಿಸ್ಟಿಕ್ ಕನ್ಕರನ್ಸಿಯನ್ನು (optimistic concurrency) ಕಡ್ಡಾಯಗೊಳಿಸುತ್ತದೆ.
ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ನಲ್ಲಿ ಅಥವಾ ಡೇಟಾಬೇಸ್ ಕನ್ಸ್ಟ್ರೈಂಟ್ ಮೂಲಕ ಬದಲಾಯಿಸಲಾಗದ ನಿಯಮವನ್ನು (immutability rule) ಜಾರಿಗೊಳಿಸುತ್ತೀರಿ. (stream_id, version) ಮೇಲೆ ಒಂದು ಯೂನಿಕ್ ಇಂಡೆಕ್ಸ್ ಇರುವುದು ಇಬ್ಬರು ಬರೆಯುವವರು (writers) ಒಂದೇ ಸರಣಿ ಸಂಖ್ಯೆಯನ್ನು ಸೇರಿಸದಂತೆ ತಡೆಯುತ್ತದೆ. ಕಮಾಂಡ್ ಬಂದಾಗ, ನೀವು ಆ ಸ್ಟ್ರೀಮ್ನ ಪ್ರಸ್ತುತ ವರ್ಷನ್ ಅನ್ನು ಓದುತ್ತೀರಿ, ಅದನ್ನು ಹೆಚ್ಚಿಸುತ್ತೀರಿ ಮತ್ತು ಹೊಸ ಇವೆಂಟ್ ಅನ್ನು ಟ್ರಾನ್ಸಾಕ್ಷನ್ ಒಳಗಡೆ ಸೇರಿಸುತ್ತೀರಿ. ಒಂದು ವೇಳೆ ಇನ್ನೊಂದು ಪ್ರಕ್ರಿಯೆಯು ನಿಮ್ಮ ಮೊದಲೇ ಅದನ್ನು ಮಾಡಿದ್ದರೆ, ಯೂನಿಕ್ ಕನ್ಸ್ಟ್ರೈಂಟ್ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಅದನ್ನು ಮರುಪ್ರಯತ್ನಿಸುತ್ತೀರಿ ಅಥವಾ ಕಮಾಂಡ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತೀರಿ.
ಒಂದುជាក់ಾತ್ಮಕ ಉದಾಹರಣೆಯನ್ನು ಪರಿಗಣಿಸಿ. ನೀವು ಇನ್ವೆಂಟರಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ನಡೆಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸೋಣ. quantity ಕಾಲಮ್ ಹೊಂದಿರುವ ಏಕೈಕ inventory ಸಾಲಿನ ಬದಲಿಗೆ, ನೀವು inventory_events ಟೇಬಲ್ಗೆ ಇವೆಂಟ್ಗಳನ್ನು ಸೇರಿಸುತ್ತೀರಿ. ItemReceived ಹತ್ತು ಯೂನಿಟ್ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ItemReserved ಎರಡು ಯೂನಿಟ್ಗಳನ್ನು ತೆಗೆಯುತ್ತದೆ. ItemShipped ಮೂರು ಯೂನಿಟ್ಗಳನ್ನು ತೆಗೆಯುತ್ತದೆ. SKU-42 ರ ಪ್ರಸ್ತುತ ಸ್ಟಾಕ್ ತಿಳಿಯಲು, ನೀವು ಸಂಬಂಧಿತ ಇವೆಂಟ್ ಪೇಲೋಡ್ಗಳನ್ನು ಕೂಡಿಸಬೇಕು. ಮೂರು ದಿನಗಳ ಹಿಂದಿನ ಸ್ಟಾಕ್ ತಿಳಿಯಲು, ನೀವು ಆ ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ವರೆಗೆ ಮಾತ್ರ ಕೂಡಿಸಬೇಕು. ಕಳೆದ ಮಂಗಳವಾರ ನಿಮ್ಮ ಶಿಪ್ಪಿಂಗ್ ಲಾಜಿಕ್ನಲ್ಲಿನ ದೋಷದಿಂದ ತಪ್ಪು ಸಂಭವಿಸಿದ್ದರೆ, ನೀವು ಸರಿಯಾದ ಕೋಡ್ ಮೂಲಕ ಇವೆಂಟ್ಗಳನ್ನು ಮರುಪ್ರತಿಷ್ಠಾಪಿಸಿ ನಿಜವಾದ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯಬಹುದು. ಸರಳ UPDATE ಸ್ಟೇಟ್ಮೆಂಟ್ ಮೂಲಕ ನೀವು ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
ತೊಂದರೆಗಳಿಂದ ನಿಮ್ಮನ್ನು ದೂರವಿಡುವ ತತ್ವಗಳು
Postgres ಮೇಲೆ ನಿರ್ಮಿಸುವುದು ಶಿಸ್ತಿನ ಅಗತ್ಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. ಈ ಕೆಳಗಿನ ತತ್ವಗಳು ಇವೆಂಟ್-ಸೋರ್ಸ್ಡ್ ಸಿಸ್ಟಮ್ಗಳಿಗೆ ನೇರವಾಗಿ ಅನ್ವಯಿಸುತ್ತವೆ.
ಸರಳವಾಗಿಡಿ. ಸಂಕೀರ್ಣತೆಯು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ. ಒಂದು ಕೆಲಸ ಮಾಡುವ ಫ್ಲೋ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಸಾಮಾನ್ಯ ಇವೆಂಟ್ ಫ್ರೇಮ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಆಸೆಯನ್ನು ತಡೆಯಿರಿ. ಮೌಲ್ಯವನ್ನು ಸಾಬೀತುಪಡಿಸಲು ಒಂದೇ ಟೇಬಲ್, ಇವೆಂಟ್ಗಳನ್ನು ಸೇರಿಸಲು ಒಂದು ರೆಪೊಸಿಟರಿ ಫಂಕ್ಷನ್ ಮತ್ತು ರೀಡ್ ಮಾಡೆಲ್ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಒಂದು ಪ್ರೊಜೆಕ್ಷನ್ ವರ್ಕರ್ ಸಾಕಾಗುತ್ತವೆ. ಒಂದುជាក់ಾತ್ಮಕ ಸಮಸ್ಯೆ ಎದುರಾದಾಗ ಮಾತ್ರ ಪರಿಕರಗಳನ್ನು ಸೇರಿಸಿ.
ಸಣ್ಣದಾಗಿ ಪ್ರಾರಂಭಿಸಿ. ನಿಮ್ಮ ಇಡೀ ಮೊನೊಲಿತ್ ಅನ್ನು ಮರುಬರೆಯಬೇಡಿ. ಆಡಿಟ್ ಟ್ರೈಲ್ನ ಪ್ರಯೋಜನವು ಹೆಚ್ಚಿರುವ ಒಂದು ಬೌಂಡೆಡ್ ಕಾಂಟೆಕ್ಸ್ಟ್ (bounded context) ಅನ್ನು ಆರಿಸಿ. ಬಿಲ್ಲಿಂಗ್ ಲೆಡ್ಜರ್, ವರ್ಕ್ಫ್ಲೋ ಇಂಜಿನ್ ಅಥವಾ ಇನ್ವೆಂಟರಿ ರಿಸರ್ವೇಶನ್ ಸಿಸ್ಟಮ್ ಉತ್ತಮ ಅಭ್ಯರ್ಥಿಗಳಾಗಿವೆ. ಆ ಒಂದು ಪೈಪ್ಲೈನ್ ಅನ್ನು ಎಂಡ್-ಟು-ಎಂಡ್ ನಿರ್ಮಿಸಿ. ಅದನ್ನು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಚಲಿಸಲು ಬಿಡಿ. ನಂತರ ಅದನ್ನು ವಿಸ್ತರಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಿ.
ಮೊದಲು ಯಶಸ್ಸನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಎಂಬುದು ಡಿಫಾಲ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅಲ್ಲ; ಇದು ನಿರ್ದಿಷ್ಟ ಅಗತ್ಯಗಳಿಗೆ ಪರಿಹಾರವಾಗಿದೆ. ನಿಮ್ಮ ಅಗತ್ಯವು ಕೇವಲ ಇತ್ತೀಚಿನ ಸ್ಥಿತಿಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಮಾತ್ರ ಆಗಿದ್ದರೆ, CRUD ವೇಗವಾಗಿ ಮತ್ತು ಅಗ್ಗವಾಗಿರುತ್ತದೆ. ನಿಮಗೆ ಟೆಂಪೊರಲ್ ಕ್ವೇರಿಗಳು (temporal queries), ಕಟ್ಟುನಿಟ್ಟಾದ ಆಡಿಟಿಂಗ್ ಅಥವಾ ಬೇಡಿಕೆಯ ಮೇರೆಗೆ ರೀಡ್ ಮಾಡೆಲ್ಗಳನ್ನು ಮರುನಿರ್ಮಿಸುವ ಸಾಮರ್ಥ್ಯ ಬೇಕಿದ್ದರೆ, ಆಗ ಇವೆಂಟ್ಗಳು ಅರ್ಥಪೂರ್ಣವಾಗುತ್ತವೆ. ನೀವು ಯಾವುದನ್ನು ನಿರ್ಧರಿಸುವ ಮೊದಲು ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯಿರಿ.
ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಮೊದಲು ಅಳೆಯಿರಿ. ಸಾಧಾರಣ ಹಾರ್ಡ್ವೇರ್ನಲ್ಲಿರುವ ಆಧುನಿಕ PostgreSQL ಸರಳವಾದ ಅಪೆಂಡ್-ಓನ್ಲಿ (append-only) ಟೇಬಲ್ ಮೂಲಕ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸಾವಿರಾರು ಇವೆಂಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸಬಲ್ಲದು. ನಿಮ್ಮ ಮಾನಿಟರಿಂಗ್ ಸರಳ ಪರಿಹಾರಗಳು ಮುಗಿದಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವವರೆಗೆ ನಿಮ್ಮ ಇವೆಂಟ್ ಸ್ಟೋರ್ ಅನ್ನು ಶಾರ್ಡ್ ಮಾಡಬೇಡಿ ಅಥವಾ ಸಂಕೀರ್ಣ ಪಾರ್ಟಿಷನಿಂಗ್ ಯೋಜನೆಗಳನ್ನು ಪರಿಚಯಿಸಬೇಡಿ. ನೀವು ಕ್ವೇರಿ ಮಾಡುವ ಫೀಲ್ಡ್ಗಳನ್ನು ಇಂಡೆಕ್ಸ್ ಮಾಡಿ. ಅಪೆಂಡ್-ಓನ್ಲಿ ವರ್ಕ್ಲೋಡ್ಗಳಿಗಾಗಿ autovacuum ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡಿ. ನಂತರ ಮತ್ತೆ ಅಳೆಯಿರಿ.
ಎಲ್ಲವನ್ನೂ ಪರೀಕ್ಷಿಸಿ. ನಿಮ್ಮ ಇವೆಂಟ್ ಹ್ಯಾಂಡ್ಲರ್ಗಳನ್ನು (event handlers) ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಮಾಡಿ. ಅಪೆಂಡ್ ಪಾತ್ (append path) ಅನ್ನು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ ಮಾಡಿ. ಎಲ್ಲಕ್ಕಿಂತ ಮುಖ್ಯವಾಗಿ, ವಿಫಲತೆಯ ಸನ್ನಿವೇಶಗಳನ್ನು (failure scenarios) ಪರೀಕ್ಷಿಸಿ. ಎರಡು ನೋಡ್ಗಳು (nodes) ಏಕಕಾಲದಲ್ಲಿ ಒಂದೇ ಸ್ಟ್ರೀಮ್ಗೆ ಅಪೆಂಡ್ ಮಾಡಿದಾಗ ಏನಾಗುತ್ತದೆ? ಬ್ಯಾಚ್ನ ಮಧ್ಯದಲ್ಲಿ ಪ್ರೊಜೆಕ್ಷನ್ ವರ್ಕರ್ (projection worker) ಕ್ರ್ಯಾಶ್ ಆದಾಗ ಏನಾಗುತ್ತದೆ? ನಿಮ್ಮ ಆಪ್ಟಿಮಿಸ್ಟಿಕ್ ಕನ್ಕರನ್ಸಿ (optimistic concurrency) ಮತ್ತು ಅಟ್-ಲೀಸ್ಟ್-ಒನ್ಸ್ ಡೆಲಿವರಿ (at-least-once delivery) ಗ್ಯಾರಂಟಿಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಿರಿ.
ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಇವೆಂಟ್ಸ್ ಟೇಬಲ್ ಬೆಳೆಯುತ್ತಾ ಹೋಗುತ್ತದೆ. ಅಪ್ಡೇಟ್ಗಳು ರೋ (row) ಸಂಖ್ಯೆಯನ್ನು ಸ್ಥಿರವಾಗಿರಿಸುವ ನಾರ್ಮಲೈಸ್ಡ್ ಸ್ಕೀಮಾದಂತಲ್ಲದೆ, ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಡಿಟಿವ್ (additive) ಆಗಿರುತ್ತದೆ. ಟೇಬಲ್ ಗಾತ್ರ, ಡಿಸ್ಕ್ I/O ಮತ್ತು ನಿಮ್ಮ ರೈಟ್ ಮಾಡೆಲ್ (write model) ಹಾಗೂ ರೀಡ್ ಮಾಡೆಲ್ ಪ್ರೊಜೆಕ್ಷನ್ಗಳ (read model projections) ನಡುವಿನ ವಿಳಂಬವನ್ನು (lag) ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಬಳಕೆದಾರರು ಹಳೆಯ ಡೇಟಾವನ್ನು ಗಮನಿಸುವ ಮೊದಲೇ ಪ್ರೊಜೆಕ್ಷನ್ ವಿಳಂಬದ ಬಗ್ಗೆ ಅಲರ್ಟ್ಗಳನ್ನು ಹೊಂದಿಸಿ.
ಮ್ಯಾನುಯಲ್ ಕೆಲಸಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ. ಮ್ಯಾನುಯಲ್ ಸ್ಕೀಮಾ ಬದಲಾವಣೆಗಳು, ಮ್ಯಾನುಯಲ್ ಪ್ರೊಜೆಕ್ಷನ್ ರೀಬಿಲ್ಡ್ಗಳು ಮತ್ತು ಮ್ಯಾನುಯಲ್ ಇವೆಂಟ್ ರಿಪ್ಲೇಗಳು ಟಿಕಿಂಗ್ ಟೈಮ್ ಬಾಂಬ್ಗಳಿದ್ದಂತೆ. ನಿಮ್ಮ ಮೈಗ್ರೇಷನ್ ಸ್ಟ್ರಾಟಜಿಯನ್ನು ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿ. ನೀವು ಇವೆಂಟ್ ಸ್ಕೀಮಾವನ್ನು ವಿಕಸನಗೊಳಿಸಿದರೆ (evolve), ಹಳೆಯ ಇವೆಂಟ್ಗಳನ್ನು ಮಧ್ಯರಾತ್ರಿಯಲ್ಲಿ ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಹೊಸ ಲಾಜಿಕ್ ಮೂಲಕ ರಿಪ್ಲೇ ಮಾಡಲು ಅಪ್ಕಾಸ್ಟಿಂಗ್ (upcasting) ಅಥವಾ ರೂಪಾಂತರವನ್ನು (transformation) ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ.
ನಿಮ್ಮ ಆಯ್ಕೆಗಳನ್ನು ದಾಖಲಿಸಿ. ನಿರ್ದಿಷ್ಟ ಸ್ಟ್ರೀಮ್ಗಳು ಏಕೆ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ, ಪ್ರತಿ ಇವೆಂಟ್ ಪ್ರಕಾರದ ಅರ್ಥವೇನು ಮತ್ತು ತಂಡವು ಯಾವಾಗ ಇವೆಂಟ್ಗಳ ಬದಲಿಗೆ CRUD ಅನ್ನು ಆರಿಸಿಕೊಳ್ಳಬೇಕು ಎಂಬುದನ್ನು ಬರೆದಿಡಿ. ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಕಾಗ್ನಿಟಿವ್ ಲೋಡ್ (cognitive load) ಅನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. ಉತ್ತಮ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಹೊಸ ಇಂಜಿನಿಯರ್ಗಳು ತಪ್ಪು ಊಹಿಸಿ, ನಿರ್ಣಾಯಕ ಸ್ಟ್ರೀಮ್ಗೆ ತಪ್ಪಾದ ಇವೆಂಟ್ಗಳನ್ನು ಅಪೆಂಡ್ ಮಾಡದಂತೆ ತಡೆಯುತ್ತದೆ.
ತಿಂಗಳುಗಟ್ಟಲೆ ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುವ ಬಲೆಗಳು
ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಡೈಗ್ರಾಮ್ನಲ್ಲಿ ಸುಂದರವಾಗಿ ಕಾಣಿಸಬಹುದು ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ನೋವಿನಕಾರಿಯಾಗಿರಬಹುದು. ಈ ಬಲೆಗಳ ಬಗ್ಗೆ ಎಚ್ಚರವಿರಲಿ.
ಸಂಕೀರ್ಣತೆಯನ್ನು ಕಡಿಮೆ ಅಂದಾಜಿಸುವುದು. ಸ್ಟೇಟ್ ಅನ್ನು ಮರುನಿರ್ಮಿಸಲು ಇವೆಂಟ್ಗಳನ್ನು ರಿಪ್ಲೇ ಮಾಡುವುದು ಪರಿಕಲ್ಪನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ. ಆದರೆ ಐಡೆಂಪೊಟೆನ್ಸಿ (idempotency) ನಿರ್ವಹಣೆ, ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಸ್ನ್ಯಾಪ್ಶಾಟಿಂಗ್ (snapshotting) ಮತ್ತು ಅಗ್ರೆಗೇಟ್ಗಳಾದ್ಯಂತ ಪರಿಹಾರಕ ವಹಿವಾಟುಗಳನ್ನು (compensating transactions) ನಿರ್ವಹಿಸುವುದು ಅಷ್ಟು ಸರಳವಲ್ಲ. ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಣ್ಣ ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಿ. ಒಂದೇ ಬಾರಿಗೆ ಒಂದು ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪರಿಹರಿಸಿ.
ಓವರ್-ಇಂಜಿನಿಯರಿಂಗ್. ನಿಮ್ಮ ಇವೆಂಟ್ ಪ್ರಮಾಣವು ಒಂದು ದಿನ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಂಡು ಮಲ್ಟಿ-ನೋಡ್ Kafka ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಡಿ. Postgres ನಿಮ್ಮನ್ನು ಅಚ್ಚರಿಯ ಮಟ್ಟಿಗೆ ಮುಂದೆ ಕೊಂಡೊಯ್ಯಬಲ್ಲದು. ನಿಮ್ಮ ಪ್ರಸ್ತುತ ಸೆಟಪ್ನಲ್ಲಿ ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗದ ಅಳತೆ ಮಾಡಬಹುದಾದ ಬಾಟಲ್ನೆಕ್ (bottleneck) ಇದ್ದಾಗ ಮಾತ್ರ ಹೊಸ ಮೂಲಸೌಕರ್ಯವನ್ನು ಪರಿಚಯಿಸಿ.
ತಾಂತ್ರಿಕ ಸಾಲವನ್ನು (technical debt) ನಿರ್ಲಕ್ಷಿಸುವುದು. ಹಳೆಯ ಇವೆಂಟ್ ಸ್ಕೀಮಾಗಳು ಎಂದಿಗೂ ಉಳಿಯುತ್ತವೆ. ನೀವು ನಿಮ್ಮ OrderCreated ಪೇಲೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಹಳೆಯ ರೂಪದಲ್ಲಿ ಇಂದಿಗೂ ಹತ್ತು ಮಿಲಿಯನ್ ಐತಿಹಾಸಿಕ ಇವೆಂಟ್ಗಳಿರುತ್ತವೆ. ಈ ಸಾಲವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ. ಬ್ಯಾಕ್ವರ್ಡ್-ಕಂಪ್ಯಾಟಿಬಲ್ ರೀಡರ್ಗಳು ಅಥವಾ ಮೈಗ್ರೇಷನ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ಯೋಜಿಸಿ. ಹಳೆಯ ಇವೆಂಟ್ಗಳ ಹೊರೆ ಪ್ರತಿಯೊಂದು ಹೊಸ ಫೀಚರ್ ಅನ್ನು ನಿಧಾನಗೊಳಿಸದಂತೆ ನೋಡಿಕೊಳ್ಳಿ.
ತಂಡಕ್ಕೆ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗದ ಪರಿಕರಗಳನ್ನು ಆರಿಸಿಕೊಳ್ಳುವುದು. ಕೇವಲ ಒಬ್ಬ ವ್ಯಕ್ತಿಗೆ ಮಾತ್ರ ಅರ್ಥವಾಗುವ ಅತ್ಯುತ್ತಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಕೂಡ ವಿಫಲವಾಗುತ್ತದೆ. ನಿಮ್ಮ ತಂಡಕ್ಕೆ Postgres ಮತ್ತು SQL ತಿಳಿದಿದ್ದರೆ, ಅಲ್ಲಿಂದಲೇ ಪ್ರಾರಂಭಿಸಿ. ನೀವು ವಿಶೇಷವಾದ ಇವೆಂಟ್ ಸ್ಟೋರ್ ಅನ್ನು ಪರಿಚಯಿಸಿದರೆ, ಬೆಳಗಿನ ಎರಡು ಗಂಟೆಗೆ ಅದನ್ನು ಡಿಬಗ್ ಮಾಡಲು ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಾಚರಣೆಯ ಪರಿಣತಿಯನ್ನು (operational expertise) ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ಒಂದು ಪ್ರಾಯೋಗಿಕ ಆರಂಭಿಕ ಬಿಂದು
ಈ ವಿಧಾನವು ನಿಮ್ಮ ಸಮಸ್ಯೆಗೆ ಹೊಂದಿಕೆಯಾದರೆ, ಐದು ಕ್ವಾರ್ಟರ್ಗಳ ಮರು-ಬರಹಕ್ಕಾಗಿ ಕಾಯಬೇಡಿ. ಈ ವಾರವೇ ಪ್ರಾರಂಭಿಸಿ.
ನಿಮ್ಮ ಪ್ರಸ್ತುತ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಿ. ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail) ನಿಜವಾದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಬಹುದಾದ ಸ್ಥಳವನ್ನು ಹುಡುಕಿ. ಬಹುಶಃ ಅದು ಪ್ರಸ್ತುತ ಒಂದೇ status ಕಾಲಮ್ ಅನ್ನು ಹೊಂದಿರುವ ಆರ್ಡರ್ ಸ್ಟೇಟ್ ಮೆಷಿನ್ ಆಗಿರಬಹುದು. ಅಥವಾ ಬ್ಯಾಲೆನ್ಸ್ ತಿದ್ದುಪಡಿಗಳಿಗೆ ಮ್ಯಾನುಯಲ್ ಡೇಟಾಬೇಸ್ ಪ್ಯಾಚ್ಗಳು ಬೇಕಾಗುವ ಹಣಕಾಸಿನ ಲೆಡ್ಜರ್ ಆಗಿರಬಹುದು. ಸ್ಟೇಟ್ ಅನ್ನು ಓವರ್ರೈಟ್ ಮಾಡುವುದು ನಿಮಗೆ ತೊಂದರೆ ನೀಡಿದ ಒಂದು ಕೊರತೆಯನ್ನು ಆರಿಸಿ.
ನಂತರ ಇಂದು ನೀವು ಮಾಡಬಹುದಾದ ಒಂದು ಸಣ್ಣ ಸುಧಾರಣೆಯನ್ನು ಆರಿಸಿ. ಒಂದು ಇವೆಂಟ್ ಟೇಬಲ್ ರಚಿಸಿ. ಒಂದು ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಮಾಡೆಲ್ ಮಾಡಿ. ಆ ಇವೆಂಟ್ಗಳಿಂದ ರೀಡ್ ಮಾಡೆಲ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಒಂದು ಪ್ರೊಜೆಕ್ಷನ್ ಬರೆಯಿರಿ. ಅದನ್ನು ಫೀಚರ್ ಫ್ಲ್ಯಾಗ್ (feature flag) ಅಡಿಯಲ್ಲಿ ನಿಯೋಜಿಸಿ (deploy). ಅದು ನೈಜ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.
PostgreSQL ನೊಂದಿಗೆ ಇವೆಂಟ್ ಸೋರ್ಸಿಂಗ್ ಎಂಬುದು ಮಾಯವಲ್ಲ. ಇದು ವಸ್ತುಗಳು ಎಲ್ಲಿವೆ ಎಂಬುದನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಅವು ಅಲ್ಲಿಗೆ ಹೇಗೆ ಬಂದವು ಎಂಬುದನ್ನು ತಿಳಿಯಬೇಕಾದ ತಂಡಗಳಿಗೆ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಸಾಧನವಾಗಿದೆ. ನಿಧಾನವಾಗಿ ನಿರ್ಮಿಸಿ, ಪ್ರಾಮಾಣಿಕವಾಗಿ ಅಳೆಯಿರಿ ಮತ್ತು ನಿಮ್ಮ ನೈಜ ಅಗತ್ಯತೆಗಳು ಆರ್ಕಿಟೆಕ್ಚರ್ಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಲಿ.