Channel
@MidnightCommit
On this record: Topic · Growth · Engagement · Reactions · Posts · Citations · Cite this entry
122subscribers
+23 since we began measuring on 8 August 2026
Risers and fallers across the register · movement among entries of Under 1,000.
| Telegram ID | -1003923333092 |
|---|---|
| Type | Channel |
| Username | @MidnightCommit |
| Created | Between 1 April 2026 and 2 July 2026 — estimated from Telegram’s id allocation, not measured. How this range is calculated. |
| First recorded | 9 August 2026 |
| Last confirmed live | 22 October 2026 |
| Measurements held | 10 |
| Confirmed unchanged | 2 times, most recently 22 October 2026 |
| On Telegram | t.me/MidnightCommit |
Technology — a classification, not a measurement. An on-box language model (Qwen3.6-35B-A3B-FP8, prompt version 1) read this channel’s own recent posts on 26 September 2026 and assigned it the closest of 31 fixed categories, at 97% confidence. This is a model’s judgement about what the channel is likely to be about, not a fact this register measured the way a subscriber count or a view count is measured — it can be revised on a later pass, and it carries no weight anywhere else on this page. How this classification works, and why it has no browse page of its own yet.
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 15 Oct 2026, 01:00 | 122 | +1 |
| 8 Oct 2026, 01:01 | 121 | +3 |
| 27 Sept 2026, 18:16 | 118 | +4 |
| 14 Sept 2026, 03:36 | 114 | +6 |
| 5 Sept 2026, 13:01 | 108 | +4 |
| 29 Aug 2026, 12:06 | 104 | +3 |
| 23 Aug 2026, 11:18 | 101 | +1 |
| 15 Aug 2026, 02:37 | 100 | +1 |
| 9 Aug 2026, 11:17 | 99 | no change |
| 8 Aug 2026, 00:19 | 99 | first reading |
20 posts held, back to 2 July 2026 — the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 1 page of Telegram’s post history, 20 posts per page.
Nothing published in the last 30 days. ERR and ER are rolling 30-day measures, so there is nothing to compute — we hold 20 posts for this entry, the most recent from 9 August 2026. An engagement rate over an empty window would be a number about nothing.
21 reactions across 12 posts, in 5 distinct kinds. The most used accounts for 42.9% of them.
| Reaction | Count | Share | Share, drawn |
|---|---|---|---|
| ❤ | 9 | 42.9% | |
| 🔥 | 6 | 28.6% | |
| 👍 | 4 | 19.0% | |
| 🆒 | 1 | 4.76% | |
| 👏 | 1 | 4.76% |
No sentiment is inferred, and none should be read in. This table is ordered by count and by nothing else. Emoji do not carry stable meaning across languages or communities — 🙏 is thanks in one channel and mourning in another — so we publish which ones were pressed and how often, and pass no judgement on what an audience meant by them.
Precision. Telegram publishes reaction counts per emoji and short-forms each one — 4.34K, 1.2M — so any single kind at or above 1,000 reaches us at three significant figures, and only counts below 1,000 are exact. The shares above are ratios of those figures and carry the same error. This is also why the total here can differ slightly from a reaction total printed elsewhere on the page: both are sums of the same rounded parts, taken over samples with different edges.
Coverage. Reactions were read on 12 of the 20 sampled posts in this sample. Summed by Telegram’s own count on each post — not by adding up the per-emoji breakdown above — those same posts carry 21 reactions in total: the kind of figure the paragraph above means by “a reaction total printed elsewhere on the page”.
Measured over the 20 most recent posts we hold, published 2 July 2026 to 9 August 2026, using the newest reading held for each. Telegram Stars are excluded: they are a payment, not a reaction, and they have their own section.
connection Pooling چطور ارتباط با Database رو بهینه می‌کنه؟ 🤔 وقتی یه درخواست وارد یه Backend Service میشه، معمولاً نیاز داره برای گرفتن یا تغییر دادن داده‌ها با Database ارتباط برقرار کنه. در نگاه اول شاید ساده به نظر برسه: درخواست میاد → Connection ساخته میشه → Query اجرا میشه → Connection بسته میشه اما توی یه سیستم واقعی که صدها یا هزاران درخواست در ثانیه دریافت می‌کنه، این مدل می‌تونه تبدیل به یه مشکل بزرگ بشه.…
🔥1
Signed Denver
Redis چطور کلیدهای منقضی شده رو حذف می‌کنه؟ 🤔 یکی از قابلیت‌های مهم Redis، امکان تعیین زمان انقضا برای کلیدهاست. مثلاً می‌تونیم یک کلید بسازیم که فقط برای چند دقیقه معتبر باشه. این قابلیت برای چیزهایی مثل Sessionها، Cacheها، OTPها و... خیلی استفاده میشه. اما یک سؤال جالب وجود داره: وقتی برای یک کلید مقدار TTL تعیین می‌کنیم، Redis چطور متوجه میشه زمانش تمام شده؟ Redis چطور زمان انقضا رو ذخیره می‌کنه؟ 🧠 وقتی برای یک…
🔥2👏1
Signed Denver
Database Replication دقیقاً یعنی چی؟ 🧠 Replication یعنی ایجاد چند نسخه از داده‌ها روی چند Database Server مختلف. توی این معماری، معمولاً یه Node اصلی داریم که مسئول دریافت تغییرات داده هست و Nodeهای دیگه یک کپی از داده‌ها رو نگهداری می‌کنن. هدف اصلی Replication این نیست که فضای بیشتری برای ذخیره‌سازی داشته باشیم. هدف اصلی اینه که بتوانیم تعدا Request بیشتری رو مدیریت کنیم و فشار روی Database اصلی رو کم کنیم. به زبا…
❤3
Signed Denver
TCP Connection چطور ساخته و بسته میشه؟ 🤔 وقتی یک Client می‌خواد با یک Server ارتباط برقرار کنه، معمولاً اولین چیزی که به ذهنمون میاد اینه که: "یک Connection ساخته میشه و بعد داده‌ها رد و بدل میشن." اما پشت این Connection ساده، یک فرآیند دقیق وجود داره که TCP برای ایجاد یک ارتباط قابل اعتماد انجام میده. TCP فقط یک کانال برای ارسال داده نیست؛ بلکه مسئولیت‌هایی مثل اطمینان از رسیدن داده‌ها، ترتیب درست Packetها و مدیریت…
Signed Denver
چطور تعداد Requestها رو کنترل می‌کنیم؟ 🤔 وقتی یک API یا یک سرویس در اختیار کاربرا قرار می‌دیم، یکی از مشکلاتی که دیر یا زود باهاش مواجه می‌شیم، حجم زیاد Requestهاست. این حجم زیاد می‌تونه دلایل مختلفی داشته باشه؛ از استفاده‌ی عادی کاربرا گرفته تا یک Client که به دلیل خطا تعداد زیادی درخواست ارسال می‌کنه یا حتی یک حمله‌ی عمدی که هدفش مصرف منابع سیستم هست. اگر هیچ محدودیتی روی تعداد Requestها وجود نداشته باشه، یک Clien…
🔥1
Signed Denver
Leaky Bucket 🪣 Leaky Bucket از نظر ایده شباهت‌هایی به Token Bucket داره، اما هدف اصلی اون کنترل نرخ خروجی Requestهاست. توی این الگوریتم، Requestهای ورودی وارد یک Queue میشن و با یک سرعت ثابت پردازش میشن. یعنی حتی اگه تعداد زیادی Request در یک لحظه وارد سیستم بشه، خروجی با یک Rate مشخص انجام میشه. این رفتار باعث میشه فشار ناگهانی روی بخش‌های دیگر سیستم کاهش پیدا کنه و Traffic ورودی به شکل کنترل‌شده‌تری پردازش بشه. ا…
❤2
Signed Denver
Redis چطور با یک Thread تعداد زیادی Request رو مدیریت می‌کنه؟ 🤔 وقتی درباره‌ی Performance صحبت می‌کنیم، معمولاً یکی از اولین چیزهایی که به ذهنمون میاد استفاده از Threadهای بیشتره. منطق هم ساده به نظر میرسه: Thread بیشتر یعنی کار بیشتر، پس سرعت بالاتر. اما Redis سال‌هاست با یک مدل متفاوت کار می‌کنه. Redis بخش اصلی پردازش Commandهای خودش رو با یک Thread اصلی انجام میده و با همین معماری می‌تونه تعداد زیادی Request رو د…
❤1
Signed Denver
NGINX چطور هزاران Connection رو همزمان مدیریت می‌کنه؟ 🤔 توی پست قبلی درباره‌ی مدل مدیریت Request توی NGINX صحبت کردیم و دیدیم که NGINX به جای ساختن Worker جدید برای هر Request، از تعداد محدودی Worker Process استفاده می‌کنه. اما یه سؤال مهم باقی می‌مونه: چطور همین تعداد محدود Worker می‌تونن هزاران Connection همزمان رو مدیریت کنن؟ جواب این سؤال به مفهومی به اسم Event Loop برمی‌گرده. مشکل اصلی کجاست؟ 🧠 وقتی یه Request…
❤1
Signed Denver
چرا Nginx برای هر Request یک Process جدید نمی‌سازه؟ 🤔 وقتی اسم Web Server میاد، معمولاً اولین چیزی که به ذهنمون میاد اینه که یک Request وارد میشه، سرور اون رو پردازش می‌کنه و جواب رو برمی‌گردونه. اما چیزی که کمتر بهش توجه میشه، اینه که خود Web Server چطور تصمیم می‌گیره این Requestها رو مدیریت کنه. این تصمیم تأثیر مستقیمی روی Performance، مصرف Memory و تعداد Connectionهایی داره که سرور می‌تونه همزمان مدیریت کنه. معما…
👍4
Signed Denver
Redis چطور تغییرات رو بدون متوقف کردن سرویس روی Disk ذخیره می‌کنه؟ 🤔 توی پست قبلی درباره‌ی RDB صحبت کردیم و دیدیم Redis چطور با استفاده از ()fork و Copy-On-Write از داده‌های داخل Memory یه Snapshot می‌گیره. اما RDB یه محدودیت مهم داره: چون Snapshotها در بازه‌های زمانی مشخص ساخته میشن، ممکنه تغییراتی که بعد از آخرین Snapshot اتفاق افتادن، در صورت Crash شدن Redis از بین برن. اینجاست که مکانیزم دیگه‌ی Redis برای Persis…
❤2
Signed Denver
RDB چه مزایا و معایبی داره؟ 💡 یکی از بزرگ‌ترین مزیت‌های RDB اینه که فایل خروجی معمولاً حجم کمی داره و ردیس بعد از Restart می‌تونه خیلی سریع‌تر داده‌ها رو دوباره Load کنه. همچنین چون نوشتن Snapshot به صورت دوره‌ای انجام میشه، فشار کمتری روی دیسک ایجاد می‌کنه. اما مشکل اصلی اینجاست: RDB آخرین وضعیت Memory رو ذخیره نمی‌کنه، بلکه آخرین Snapshot گرفته‌شده رو ذخیره می‌کنه. یعنی اگر ردیس Crash بشه، ممکنه تغییراتی که بعد ا…
Signed Denver
ردیس چطور بدون متوقف کردن سرویس از داده‌ها Snapshot می‌گیره؟ 🤔 وقتی درباره‌ی ردیس صحبت می‌کنیم، معمولاً اولین چیزی که به ذهنمون میاد سرعت بالای اون به خاطر نگهداری داده‌ها داخل رم هست. اما همین موضوع یه سؤال مهم ایجاد می‌کنه: اگه تمام داده‌های ردیس داخل رم باشن، بعد از Restart شدن سرویس یا کرش شدن سرور چه اتفاقی برای اطلاعات میفته؟ اینجاست که مفهوم Persistence وارد ردیس میشه. ردیس با اینکه یه دیتابیس In-Memory محسوب…
Signed Denver
Showing the 12 most recent of 20 posts we hold for @MidnightCommit. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked ≈ was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.
Republished by
Channels on the register that have forwarded this channel's posts into their own feed.
Built only from forwarded posts we have actually read, on both sides. Coverage is early and deliberately incomplete: a missing link means we have not read the post that would prove it, never that the relationship does not exist. Counts are distinct forwarded posts observed, so they only ever go up as we read more.
Named by 1 registered channel — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.
Named by
Channels on the register whose posts name this channel's handle.
A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.
A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 15 October 2026 — this entry's latest reading, not the date you are reading this.
“Midnight Commit” (@MidnightCommit), 122 subscribers as measured 15 October 2026. Telegram Register, tgregister.com/channel/MidnightCommit.
Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.