BranchesTags

Repository files navigation

node-concurrency-patterns

A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.

The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.

The strategies include:

  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints

The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.

See also docs/PLAN.md for the full progression and docs/tests-overview.md.

Setup

npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is kept in the named postgres_data volume; Redis is intentionally ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres volume, dropping its schema and data. Re-run docker:up + migrate afterward to get back to a clean database.

Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute TypeScript directly through Node's built-in type stripping; Vitest transforms test files and their imports. The erasableSyntaxOnly compiler option keeps the application source compatible with Node's native execution. There is no build step.

About

Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.

Topics

advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
node-concurrency-patterns
A learning project exploring different ways to protect shared state when concurrent Node.js operations race to modify the same resource.
The project uses a simple locker checkout invariant: a locker can have at most one active checkout. Concurrent requests deliberately race against that invariant, then several strategies are implemented and tested to understand where each one provides its guarantee.
The strategies include:
  • in-process keyed mutexes
  • PostgreSQL advisory locks with READ COMMITTED isolation
  • Redis-based distributed locks
  • optimistic concurrency control
  • PostgreSQL constraints
The goal is not just to make the race disappear, but to understand why each strategy works, what its coordination boundary is, and what changes when the application runs across multiple Node.js processes.
See also docs/PLAN.md for the full progression and docs/tests-overview.md.
Setup
npm ci
npm run docker:up # Postgres (localhost:5433) + Redis (localhost:6379)
npm run migrate
npm run typecheck
npm test
  • npm run docker:down stops and removes the containers. Postgres data is
kept in the named postgres_data volume; Redis is intentionally
ephemeral and starts empty the next time the containers are created.
  • npm run docker:reset stops the containers and deletes the Postgres
volume, dropping its schema and data. Re-run docker:up + migrate
afterward to get back to a clean database.
Requires Node >=24.7 (see .nvmrc). Runtime commands such as migrate execute
TypeScript directly through Node's built-in type stripping; Vitest transforms
test files and their imports. The erasableSyntaxOnly compiler option keeps
the application source compatible with Node's native execution. There is no
build step.
About
Node.js concurrency patterns explored through practical race conditions, synchronization strategies, and consistency guarantees.
Topics
advisory-locksconcurrencydatabase-lockingmutexnodejspostgresqlqueuesrace-conditionstransactionstypescript
Resources
Readme
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages