Coder Legion - Recent posts tagged only

How to Build a B2B Prospect List That Is Worth Contacting

Tue, 15 Sep 2026 15:50:00 +0000

A useful B2B prospect list is not a large file of email addresses. It is a small, explainable set of companies that can buy your offer, plus the people who are likely to own the problem. Build the targeting rules first, inspect 20 companies manually, and only then spend credits or time revealing contact details.

Partner disclosure. This guide includes a partner link to Apollo. If you create an account or purchase through it, I may earn a commission at no extra cost to you. The targeting method also works with other research tools.

Short answer: define one offer, one company profile, one buying situation, one buyer role, and explicit exclusions. Translate those rules into a search, then calculate the percentage of the first 20 results that you would genuinely contact. If fewer than 14 are good fits, fix the criteria before scaling the list.

What a qualified prospect list contains

The file should answer why each company belongs. Contact data is useful only after that decision. A list with 80 relevant accounts is usually more workable for a solo consultant or small agency than 5,000 records bought under a broad industry label.

Layer	Question it must answer	Example
Offer	What specific outcome can you help create?	Reduce manual quote follow-up for commercial suppliers
Account fit	Which companies can buy and use that outcome?	Independent US suppliers with 10 to 100 employees
Buying situation	What observable condition makes the problem plausible now?	Hiring sales staff, opening locations, or using a relevant CRM
Buyer role	Who owns the process, budget, or operational pain?	Owner, sales director, or operations manager
Exclusions	Who should not enter the list?	Consumer-only shops, franchises with centralized buying, and direct competitors

Step 1: write the ICP before opening a database

An ideal customer profile is a testable description of a company, not a slogan such as "small businesses that need growth." Start with evidence from current customers, past projects, sales conversations, or businesses that already buy a comparable service.

Copy this compact worksheet into a document or spreadsheet:

Offer:
Business problem:
Industry or business model:
Geography served:
Employee or revenue range:
Required technology or process:
Useful timing signal:
Primary buyer role:
Secondary buyer role:
Hard exclusions:
Reason each included company can plausibly buy:

Keep the first version narrow. If the offer helps both dental groups and manufacturing distributors, treat them as separate segments. They have different workflows, buyers, language, and reasons to act.

When the first segment is ready, use the Apollo free trial checklist to test a 25-company sample, contact quality, credit use, and one reviewed sequence before paying. If the unresolved question is which research system to use, compare Apollo with LinkedIn Sales Navigator by contact-data, relationship-context, and outreach needs before adding another subscription.

Step 2: search for companies before people

Company selection comes first because a correct job title at the wrong company is still a bad prospect. In Apollo, start in Companies and combine only filters that express the ICP. Common starting dimensions include location, employee count, industry, company keywords, technologies, hiring activity, and funding. Advanced filter access depends on the account plan.

Use a signal only when it has a clear connection to the offer. "Recently funded" is not automatically useful. It matters when the new capital changes the company's likely need, budget, staffing, or systems. The same rule applies to hiring and technology filters.

Targeting rule	Good use	Weak use
Industry	Narrow a known vertical with similar operations	Select every loosely related category
Employee count	Approximate process complexity and buying capacity	Treat headcount as proof of budget
Technology	Find businesses using a system you integrate or replace	Add popular tools with no relation to the offer
Hiring	Identify a current operational change tied to the problem	Assume any job opening means purchase intent
Buying intent	Prioritize an already qualified account set	Use a broad topic as the only qualification rule

Step 3: add the buyer roles

After the account set looks credible, move to People and identify two or three role families. Titles vary, especially in small companies. A 15-person business may have an owner handling operations, while a 90-person company may have a dedicated operations manager and sales director.

Economic buyer: can approve the purchase or commit budget.
Process owner: experiences the broken workflow and understands the operational detail.
Technical reviewer: checks access, integration, security, or implementation requirements.

Avoid adding every senior title at the account. If your offer fixes lead routing, the finance director is not automatically relevant just because the title is senior. Use job function, seniority, and title keywords together, then exclude roles that clearly cannot own the problem.

Step 4: validate 20 records before spending more

Apollo says saved-search counts can change as records, enrichment, scoring, and your saved contacts change. Treat search output as a moving candidate set, not a purchased truth. Open the first 20 companies and check the criteria against current public evidence.

Open the company website and confirm the business still operates.
Confirm the company sells to the market your offer serves.
Check geography, approximate size, and any required technology or process.
Confirm the selected person's role is current and relevant.
Remove agencies, directories, subsidiaries, competitors, or consumer businesses that slipped through.
Record a short reason to include or reject each row.

Example rejection: suppose BrightPath Marketing has 12 employees and the founder title matches your filters. If your ICP targets direct commercial suppliers, the record still fails because the company is an agency. The size and title matched; the business model did not.

Score the sample as contact, research further, or reject. A useful initial threshold is 14 contactable companies out of 20. That 70% threshold is a working quality gate, not an industry benchmark. Tighten or loosen it only after you understand why records fail.

Step 5: fix the rules, not individual rows

The rejected rows show what the search is missing. If franchises keep appearing, add ownership or keyword exclusions. If enterprise companies dominate, reduce the employee range. If the right accounts appear but the wrong people do, change the role logic without rebuilding the account search.

Failure in the sample	Rule to revisit
Companies sell to consumers, not businesses	Industry, keywords, business model, and exclusions
Companies are too large or too small	Employee range and market segment
Correct companies, irrelevant people	Job function, title variants, seniority, and exclusions
Many closed, merged, or stale businesses	Manual verification and data-source fit
Almost no companies match	Whether the ICP describes a real accessible market

Step 6: build the first working list

When the sample passes, save the company search and create one list per segment. Apollo distinguishes total results, net-new records, and records already saved to your account. Keeping segments separate makes later research, messaging, and measurement easier.

Start with 50 to 100 companies, not every result. Add contact data only for the role set you plan to research. Apollo currently uses credits for actions such as revealing verified net-new emails, phone data, enrichment, and some AI research. Exact credit use depends on the plan and action, so review the confirmation and account usage before a bulk operation.

Before importing the list into a CRM or outreach workflow, normalize company domains, remove duplicates, suppress existing customers and opt-outs, and verify the contact data. The lead deduplication guide shows how to keep repeated records from creating duplicate CRM contacts or parallel follow-ups.

The next step is research, not auto-send. The lead outreach drafts case shows how public company context can feed a human-reviewed draft queue. If those prospects later become inbound or engaged leads, the lead follow-up cost guide explains the separate automation decision.

What not to do

Do not buy a broad exported list before proving the account criteria.
Do not treat a verified email as proof that the person wants contact or that delivery is guaranteed.
Do not target a role only because it is senior.
Do not use AI research or intent data as the only reason to include a company.
Do not upload customer or prospect data unless you have the right to process it.
Do not automate outreach until suppression, opt-out, sending, and legal requirements are defined for the relevant region.

Apollo's current terms limit the service to appropriate B2B activities, prohibit spam and unlawful marketing use, and state that supplied data may contain errors, omissions, or duplicates. The user remains responsible for checking data and complying with applicable law. A prospecting platform helps organize research. It does not create permission or remove judgment.

Verification checklist

The offer and business problem fit in one sentence.
Company criteria and exclusions are observable.
The account search is reviewed before the people search.
Buyer roles own the problem, budget, or implementation decision.
At least 14 of the first 20 companies pass manual review, or the rules are revised.
The first working list stays small enough for real research.
Credit use is checked before any bulk reveal or enrichment.
No outreach starts until verification, suppression, and compliance rules exist.

Sources checked

Apollo for a small B2B test

Build the first 20-company sample

Create one narrow search and verify the first results before revealing a large contact list. I may earn a commission if you sign up or purchase through this link, at no extra cost to you.

Create a free Apollo account

Originally published on FloxoLab.

Apollo Free Trial: What You Can Test Before Paying

Sat, 05 Sep 2026 15:50:00 +0000

Direct answer: create an Apollo Free account first and do not activate the one-time 14-day paid-plan trial until your test segment is ready. Use Free to define the market and filters. During the trial, inspect 25 companies, verify 10 contacts, reveal only the data you need, test one sequence with your own inbox, and measure credit use. Upgrade only if the sample is good enough and a paid feature removes a real constraint. Otherwise, let the workspace return to Free.

Partner disclosure. This guide includes a partner link to Apollo. If you create an account or purchase through it, I may earn a commission at no extra cost to you.

This guide has one narrow job: evaluate Apollo before paying. It does not replace the B2B prospect list guide, which covers ICP, company filters, buyer roles, and exclusions. If you have not chosen the research system yet, use the Apollo vs LinkedIn Sales Navigator comparison first. Use the separate Apollo pricing guide for the current plan table, credit costs, add-ons, and small-team scenarios. Here, the outcome is a written pass, upgrade, or revert decision based on one representative segment.

Apollo Free account and free trial are not the same thing

Current fact	What it means for your test
Free account	A persistent $0 workspace for preparing filters and trying limited prospecting tools. You can keep it after the trial.
Paid-plan trial	An eligible Free account can start one 14-day trial of Basic or Professional. Custom plans do not have a self-serve trial.
No credit card required	You can evaluate the trial without entering a card. At the end, upgrade or return to Free.
Trial credit allowance	Apollo's public pricing FAQ currently says 50 credits plus 5 mobile credits. Check the confirmation screen because Apollo is rolling out a new credit system.
Bulk action limit	You can select up to 25 records at once for a bulk save or action during the trial.
Phone and calling limits	The trial documentation lists up to 20 phone-number accesses, 60 total calling minutes, and 10 minutes per call.

Checked in a live Free workspace on August 11, 2026: the account showed a $0 Free plan, 75 monthly credits, two sequences, and five AI Assistant chats. The same workspace had already used its Professional trial. Your allowance can differ during Apollo's credit-system rollout, so the numbers inside your own Billing screen are binding.

If you upgrade during the trial, Apollo says the trial ends immediately and unused trial days or credits do not carry over. You can switch between Basic and Professional during the original 14-day window, but the clock does not reset. Do the useful testing before you buy.

Prepare a small test pack before starting the clock

The trial becomes valuable when you know what a good result looks like. Pick one market, one offer, and one buying role. A broad search across several industries will make the database look busy, but it will not tell you whether Apollo can support your actual outreach process.

Write the segment. Define geography, industry, company size, buyer role, and at least three exclusions.
Choose 25 companies. This fits the trial's bulk-selection ceiling and is large enough to expose weak filters.
Choose 10 contacts. Verify their current role and company manually before spending more credits.
Name required fields. Decide whether you truly need work email, phone, LinkedIn URL, company website, headcount, or technology data.
Set pass criteria. For example, require at least 20 of 25 companies to fit and 8 of 10 sampled contacts to hold the expected role. These are evaluation thresholds, not Apollo accuracy claims.
Prepare one safe message. Use your own or a controlled test inbox first. Do not make live cold sends the first sequence test.

A practical 14-day Apollo trial schedule

Days	Test	Evidence to keep
Before trial	Build the segment, exclusions, sample sheet, and pass criteria on Free.	One ready 25-company test pack.
1-2	Rebuild the search and test filters that matter to your market.	Saved search plus notes on false positives and missing companies.
3-5	Inspect 25 companies and 10 contacts against public company pages and professional profiles.	Fit, role, stale-data, and uncertain-data labels.
6-7	Reveal only the email or phone data needed for the sample and review credit history.	Credits before and after each action.
8-10	Build one sequence and send it only to a test inbox or controlled recipient.	Merge fields, timing, stop rules, unsubscribe path, and reply behavior.
11-12	Test AI Assistant or the dialer only if either feature affects the buying decision.	Time saved, credit use, errors, and required manual review.
13-14	Score the result, document the required plan, and upgrade or revert.	A written decision with no unused trial work left behind.

Test one: can Apollo isolate the right market?

Start with company filters, then add people filters. Review the first 25 companies one by one. A company passes only when it matches the real market, not merely because Apollo assigned a nearby industry label. Record why every false positive entered the list, then tighten one filter at a time.

Confirm the company still operates, serves the target geography, and fits the intended size range.
Check whether subsidiaries, agencies, recruiters, consultants, or competitors should be excluded.
Review job titles for function and seniority. Similar titles can represent very different buying authority.
Save the clean search only after the sample meets the written company-fit threshold.

Pass: the search repeatedly produces companies and roles that a human reviewer would accept. Fail: the apparent list size collapses after manual checks or depends on exclusions you cannot express consistently.

Test two: measure contact quality and credit use together

Apollo's terms explicitly say its data may contain errors, duplicates, and omissions. Treat a reveal as a candidate record, not a guarantee. For 10 contacts, verify current employer and role from a public company page or professional profile. Mark records as confirmed, stale, conflicting, or uncertain.

Before revealing anything, open Settings > Billing > Credit usage & AI > History. Record the starting balance, reveal the smallest useful sample, then inspect the history again. Apollo's current system can charge different actions for email, phone, enrichment, connected calls, AI research, exports, and other features. The confirmation shown before an action and the resulting history are more reliable than an old blog post or remembered price table.

Do not spend the trial proving volume. Ten carefully checked contacts reveal more about fit than hundreds of unreviewed records. Spend mobile credits only when phone data is part of the real workflow.

Test three: build one sequence without risking your domain

Create one short sequence for the chosen segment. Add a few controlled records that you own, review every merge field, and send to a test inbox. You are evaluating the workflow, not trying to prove that a 14-day blast can generate revenue.

Check the sender name, reply-to address, timezone, daily schedule, and delay between steps.
Preview records with missing company names, first names, or custom fields.
Confirm what happens after a reply, bounce, unsubscribe, manual removal, or booked meeting.
Keep the first live volume low and monitor the sending mailbox outside Apollo as well.
Verify any mailbox-provider restriction shown in your workspace before connecting an important domain.

Apollo can organize sequencing, but it cannot guarantee inbox placement, replies, meetings, or revenue. Your list quality, sender reputation, message relevance, consent basis, and local marketing rules still matter. Apollo's terms place responsibility for lawful use and verification on the customer.

Test AI Assistant only when it saves a real step

Apollo's current documentation gives Free accounts five AI Assistant chats per billing cycle and up to 10 messages in each chat. Paid access currently offers more generous use. Chatting does not automatically consume credits, and Apollo asks for confirmation before a credit-consuming action. Still, verify every output and avoid entering sensitive information.

A useful test is narrow: ask the assistant to create or refine the saved search for your written segment, then compare the result with your manual filter setup. Record whether it saved time and whether you had to correct industries, titles, exclusions, or geography. Do not upgrade because the assistant produced fluent text. Upgrade only if it reduces repeatable research work without weakening control.

If calling matters, verify dialer access before choosing a trial

Apollo's dedicated trial help page says the dialer is available only in the Professional trial. The current in-account Basic plan card we checked listed a US dialer. Because these official surfaces conflict, do not assume either is universal. Review the exact trial confirmation screen or ask Apollo support before activation if calling is part of the purchase decision.

If dialer access appears, test it with your own or an explicitly consenting recipient first. Confirm number setup, recording settings, call outcome logging, and credit use. The trial documentation lists 60 total minutes and a 10-minute limit per call, which is enough for workflow evaluation but not a calling campaign.

What the Apollo trial cannot prove

That every email, phone number, company attribute, or job title is current and accurate.
That messages will reach the inbox or that a mailbox will preserve its sender reputation.
That a segment will produce replies, meetings, pipeline, or revenue at scale.
That having access to contact data gives you permission to use it in every jurisdiction.
That the credit allowance or feature limits in your trial will remain unchanged later.

The trial can prove something narrower and still valuable: whether Apollo finds enough plausible records for one market, whether your team can verify and organize them efficiently, whether the credit economics are visible, and whether the paid workflow is meaningfully better than staying on Free.

Choose Basic or Professional by the feature you must prove

Start with Basic when the decision is mainly about search, saved lists, enrichment, and simple sequences. Choose Professional only when a Professional-level workflow is genuinely part of the buying decision, such as advanced sequencing, reporting, team controls, or the dialer access confirmed for your workspace. Do not select the larger trial merely to explore more menus.

Avoid activating either trial until you can name the decisive feature in one sentence. If the Free account already supports the recurring work and the paid feature does not save enough time or improve control, returning to Free is the correct outcome.

Use this upgrade-or-revert scorecard

Question	Upgrade signal	Revert signal
Did targeting pass?	The 25-company sample met the written fit threshold.	Manual review removed too much of the list.
Was contact data useful?	The verified sample supported the intended channel.	Too many records were stale, conflicting, or missing.
Were credits predictable?	The team can estimate monthly use from actual history.	Required actions consume credits too quickly or unclearly.
Did the sequence work safely?	Fields, timing, replies, and stop rules behaved as expected.	The process still needs constant manual correction.
Did a paid feature matter?	It removed a measured bottleneck in the real process.	The Free account already covers the useful work.

What not to do during the trial

Do not activate before the segment, sample, and acceptance criteria are ready.
Do not reveal every available field when the workflow only needs one channel.
Do not treat database access as proof of accuracy or legal permission.
Do not test deliverability by sending a large cold campaign from a valuable domain.
Do not upgrade early. Apollo says that immediately ends the trial.
Do not judge Apollo by record count alone. Judge the verified fit and usable workflow.

Sources checked

Trial rules, credit behavior, AI limits, sequence controls, and legal boundaries were checked on August 11, 2026. Apollo can change plans, allowances, and product behavior.

Apollo partner link

Test one qualified segment

Understanding the Consumption-Based Model in Cloud Computing

Sat, 22 Aug 2026 08:44:28 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

Cloud computing has transformed the way organizations build and deploy applications. Instead of purchasing expensive servers and networking equipment upfront, businesses can access computing resources on demand and pay only for what they use.

This pricing approach is known as the consumption-based model, and it is one of the biggest reasons cloud computing has become so popular.

What Is the Consumption-Based Model?

The consumption-based model (also called pay-as-you-go pricing) is a cloud billing approach where customers are charged based on their actual resource usage rather than paying a fixed amount in advance.

Whether you're using virtual machines, databases, storage, or networking services, your bill depends on how much you consume.

Think of it like your electricity bill—you pay for the units you use instead of paying a fixed amount every month regardless of consumption.

Traditional Infrastructure vs Cloud Consumption

Traditional Infrastructure	Consumption-Based Cloud
Large upfront hardware investment	No upfront infrastructure purchase
Pay even when servers are idle	Pay only for resources you use
Capacity planning required	Scale resources up or down instantly
Hardware maintenance is your responsibility	Cloud provider manages infrastructure

This shift helps organizations avoid spending large amounts of money before they even launch an application.

Key Benefits

1. No Upfront Costs

Traditional IT requires purchasing servers, storage devices, networking hardware, software licenses, and data center infrastructure before deployment.

With cloud computing, you can start using services immediately without these initial investments.

2. Pay Only for What You Use

You're billed based on actual resource consumption.

Examples include:

Compute hours for virtual machines
Storage space used
Number of database transactions
Data transferred over the network
Function executions in serverless platforms

If your application uses fewer resources, your costs decrease automatically.

3. Scale When Needed

Cloud platforms allow resources to grow or shrink depending on demand.

For example:

During a product launch, your application can automatically add more servers.
After traffic decreases, unnecessary resources can be removed to reduce costs.

This elasticity is difficult and expensive to achieve with traditional infrastructure.

4. Better Cost Optimization

Since billing reflects actual usage, organizations are encouraged to monitor workloads and optimize resources.

Common cost-saving practices include:

Shutting down unused virtual machines
Choosing smaller instance sizes
Using auto-scaling
Deleting unused storage
Monitoring cloud spending regularly

A Real-World Example

Imagine you're building an e-commerce website.

Traditional Approach

You purchase servers capable of handling holiday shopping traffic, even though most of the year they remain underutilized.

Result:

High upfront investment
Idle resources
Ongoing maintenance costs

Consumption-Based Cloud

You deploy your application in the cloud.

During normal days, only a few virtual machines run.
During festivals or sales, additional instances automatically start.
Once traffic returns to normal, extra resources shut down.

You only pay for the additional resources while they are actually running.

Consumption-Based vs Subscription-Based Pricing

Consumption-Based	Subscription-Based
Pay for actual usage	Fixed monthly or yearly fee
Flexible costs	Predictable costs
Ideal for changing workloads	Best for consistent workloads
Easy to scale	Usually includes predefined resource limits

Both pricing models have their place, and many cloud providers offer a combination of the two depending on the service.

Things to Keep in Mind

Although the consumption-based model helps reduce unnecessary spending, costs can increase unexpectedly if resources are left running or applications generate more traffic than expected.

To avoid surprises:

Set spending budgets
Enable billing alerts
Monitor resource usage
Remove unused services
Review monthly cloud bills

Cost management is an important part of working with cloud platforms.

Conclusion

The consumption-based model is one of the defining characteristics of cloud computing. Instead of making large capital investments, organizations can treat IT infrastructure as an operational expense, paying only for the resources they consume.

This flexibility allows startups to launch with minimal investment, helps enterprises optimize costs, and enables developers to build scalable applications without worrying about purchasing physical infrastructure.

Whether you're preparing for the AZ-900 Azure Fundamentals certification or simply learning cloud computing, understanding the consumption-based model is essential because it explains why cloud services are both flexible and cost-effective.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Understanding Systemd.exec - Part 1: How to Secure Applications Running in Systemd?

Sat, 02 May 2026 02:27:26 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on GitHub. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

If you are running applications with systemd and want to restrict how they interact with Linux kernel features (like filesystem, processes, and capabilities), you can use the systemd.exec configuration options.

In this article I will be going to explain how to use these options to secure your application.

What are systemd.exec options?

Systemd.exec options are a set of configuration options that are used to configure how a systemd service interacts with the Linux kernel.

This feature is mainly used to provide security for the applications running in systemd.

Why we need this option in first place?

Hardening services (Postgres, Nginx, workers, etc) which are mostly open to the internet
Reducing blast radius after compromise
Lightweight (no container overhead)

How is this different from Docker?

Works on a single process/service.
Applies restrictions on top of the host.
Uses kernel features (namespaces, cgroups, capabilities)
Shares the same root filesystem (by default)
No packaging, no images

What is the real usecase?

Let's take an example of service.

/etc/systemd/system/myapp.service

Inside this file, we can control:

Where the app runs
Which user it runs as
What it can access
How secure / isolated it is
What resources it can use

Most common options

Run a service as non-root (security)

Set User= Group= to a non-privileged user (e.g. postgres, www-data).
This will prevent the service from running as root, which can lead to security vulnerabilities.

For example:

[Service]
User=postgres
Group=postgres

Restrict filesystem access

Set ProtectSystem= ProtectHome= ReadWritePaths= ReadOnlyPaths= to control filesystem access.
This will make service only read/ write specifed directory.

Example:

[Service]
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Isolate runtime environment (like lightweight container)

Set PrivateTmp=yes NoNewPrivileges=yes to isolate runtime environment.
As there is no container like docker this will be running in the host but under private tmp and no new privileges.

Example:

[Service]
PrivateTmp=yes
NoNewPrivileges=yes

Limit resources (avoid abuse / crashes)

Set CPUQuota= MemoryMax= MemoryHigh= MemoryLimit= MemoryAccounting= to limit resources.
If we want specific service to use only limited resources, we can use these options.

Example:

[Service]
CPUQuota=50%
MemoryMax=512M

Provide controlled writable directories Set ReadWritePaths= ReadOnlyPaths= to control filesystem access. This will make service only read/ write specifed directory.

Example:

[Service]
ReadWritePaths=/var/lib/postgresql
ReadOnlyPaths=/var/lib/postgresql/16/bin

Drop dangerous privileges

Set CapabilityBoundingSet= to drop dangerous privileges.
This will make service only able to run commands with specific privileges.

Example:

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

Run temporary / ephemeral services Set RuntimeDirectory= StateDirectory= LogsDirectory= to run temporary / ephemeral services. This will run the service in a temporary / ephemeral directory.

Example:

[Service]
RuntimeDirectory=myapp
StateDirectory=myapp
LogsDirectory=myapp

Limit process / thread count Set TasksMax= to limit process / thread count. This will make service only able to run with specific process / thread count.

Example:

[Service]
TasksMax=100

Restrict access to system calls Set SystemCallFilter= SystemCallArchitectures= to restrict access to system calls. This will make service only able to use specific system calls.

Example:

[Service]
SystemCallFilter=open,read,write,close
SystemCallArchitectures=amd64

Security measures for Docker Engine Set Delegate=yes to run Docker Engine with specific privileges. This will make Docker Engine only able to run with specific privileges.

Example:

[Service]
Delegate=yes

Conclusion

We could able to use systemd.exec options to secure application running in systemd.

But Until we integrate with real application and test these options, we can't be sure about the security.

In the next article we will see how service react with integrations of these options.

Reference Man Page Systemd : https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.
⭐ Star it on GitHub: https://github.com/HexmosTech/git-lrc

Five Caching Strategies Every Backend Dev Should Know

Sun, 19 Apr 2026 19:33:53 +0000

Five Caching Strategies Every Backend Dev Should Know

If you build backend systems, you eventually run into caching.

Someone says “just put Redis in front of it” and suddenly your app is faster… until you start seeing stale data, cache misses, and weird bugs when you deploy.

This post explains five core caching strategies in plain language:

Cache-Aside
Read-Through
Write-Through
Write-Back
Write-Around

You’ll see how each one works, what can go wrong, and when to use it.

A cache is just a faster, smaller copy of some data. The hard part is keeping that copy useful: when to fill it, when to read from it, and when to update or skip it.

1. Cache-Aside (Lazy Loading)

Idea: The application talks to the cache and the database. It “checks the cache first, then falls back to the DB” and fills the cache on a miss.

If the key is in the cache (a hit), just return it. Super fast.


If the key is missing, the app queries the database instead.


The app stores the result in the cache and returns it to the user.

Why people love it

Simple and flexible: logic lives in your code; you control what goes in the cache.
Resilient: if the cache dies, the app can still read from the DB (just slower).
Memory-efficient: only data that is actually read gets cached.

What can go wrong

The first request for a key is slow (cold cache).
If the DB is updated outside your code path (e.g. admin tool, another service), the cache can serve stale data until TTL expires or you manually invalidate.

When to use

Great default for read-heavy apps (blogs, product catalogs, many dashboards).
When you’re just adding caching to an existing codebase and want full control.

2. Read-Through

Idea: The application pretends the cache is the main database.

It calls the cache for every read. On a miss, the cache layer itself fetches from the DB, stores the result, and returns it.

With Cache-Aside, your app code calls both cache and DB. With Read-Through, your app only calls the cache; a loader behind the cache talks to the DB.

Pros

Cleaner application code: your code only knows “get from cache”.
Cache libraries or infrastructure can handle loading, retries, and metrics.

Cons

If some writes go directly to the DB (bypassing the cache API), the cache can easily become stale.
You need a cache provider or library that supports read-through loading.

When to use

Larger teams where you want centralized cache logic, not ad-hoc caching scattered everywhere.
Situations where infra/platform team owns the cache layer.

3. Write-Through

So far we talked about reads. Now let’s talk about writes: how we keep cache and DB in sync.

Write-Through means:

On a write, update the cache and the database synchronously. Only when both succeed is the write considered “done”.

Flow

User updates something (e.g. changes quantity in a cart).
App writes the new value into the cache.
App also writes the same value into the database.
Only if both succeed do we return “OK” to the user.

Pros

Strong consistency: cache and DB always match for that key.
Reads from the cache always see the latest value.

Cons

Slower writes: every write has to hit both cache and DB before returning.
If DB is slow, your API write latency is also slow.

When to use

When correctness matters more than raw speed:
- balances in a wallet / bank,
- inventory in an e‑commerce site,
- data where a stale read would be really bad.

4. Write-Back (Write-Behind)

Write-Back trades strict consistency for speed.

On a write, update only the cache and return success quickly. Later, an async process flushes those changes to the database.

Flow

User sends a write.
App writes to cache and returns 200 OK immediately.
A background worker or the cache itself periodically writes batched updates into the DB.

Pros

Very fast writes: app isn’t blocked waiting for DB.
Great for high-throughput workloads:
- counters (views, likes),
- logs / telemetry,
- social feed events.

Cons

Risk of data loss: if the cache crashes before flushing to DB, those changes are gone.
DB is eventually updated, not immediately.

When to use

Write-heavy workloads where losing a tiny fraction of data is acceptable:
- metrics, dashboards, click-streams,
- non-critical logs.

5. Write-Around

Write-Around takes a different approach:

Writes skip the cache and go straight to the DB. The cache is only filled later when data is read.

Flow

A write goes directly into the database.
The cache is not updated.
On the next read, the app (or cache) sees a miss:
- loads from DB,
- populates the cache,
- and returns the value.

Pros

Prevents “polluting” the cache with data that is written but rarely read.
Good when you have big write batches (imports, ETL jobs) that users won’t read immediately.

Cons

The first read after a write is always a cache miss (slower).
More frequent DB reads if many keys are only read once.

When to use

Large imports, archival data, logs that might be read only occasionally.
Systems where memory is tight and you want the cache to focus on truly hot data.

Side-by-side comparison

Here’s a quick comparison of these five strategies using the labels you provided.

How teams typically choose

To connect this with the interactive content you built:

These charts show two things:

Cache-Aside dominates in real systems because it’s simple and resilient.
Write-Back gives the fastest writes but carries the most risk; Write-Through is safest but slower on each write.

Which caching strategy should you pick? (a practical rule-set)

If you only remember one thing from this post, remember this: you pick a caching strategy based on the cost of a stale read and the cost of a slow write.

Here’s a fast, real-world decision guide:

Most read-heavy apps (catalogs, blogs, dashboards):
- Start with Cache-Aside.
- Add TTLs and a plan for invalidation if data changes.
You want a clean abstraction and centralized caching (platform/infra owned):
- Use Read-Through so product code only depends on the cache API.
A stale read would be painful (wallet balances, inventory, “did my payment go through?”):
- Prefer Write-Through (consistency > speed).
Writes are hot and you can tolerate some eventual consistency (counters, analytics, clickstream):
- Consider Write-Back, but only with durability guardrails (below).
You write lots of data that is rarely read (imports, ETL, logs):
- Use Write-Around to avoid polluting the cache.

Two failure modes teams hit in production (and what to do)

Caching rarely fails in obvious ways. It fails with “the DB is melting” or “why is data stale?”. Two patterns show up everywhere.

1) Cache stampede (thundering herd)

Symptom: a hot key expires (or cache restarts), and suddenly thousands of requests miss at once and slam the DB.

Mitigations:

Request coalescing / single-flight: only one request recomputes the value; others wait and reuse it.
Stale-while-revalidate: keep serving a slightly stale value while one background refresh updates it.
Jittered TTLs: add randomization to expiration times so many keys don’t expire at the same second.

2) Hot key / hotspotting

Symptom: one key becomes so popular (home feed, trending item, auth config) that a single cache shard or a single DB row gets hammered.

Mitigations:

Shard the key (e.g. trending:v1:0..N) and merge results.
Use a two-layer cache: per-instance in-memory (tiny TTL) + shared Redis.
Precompute or cache at a higher level (edge/CDN) if the data is public.

What to monitor so caching doesn’t become “magic”

Whatever strategy you choose, watch these:

Cache hit rate (overall and by endpoint)
DB QPS (does caching actually reduce it?)
p95/p99 latency (cache helps only if tail latency improves)
Eviction rate / memory pressure (are you constantly evicting hot data?)
Stale reads / correctness signals (app-specific: inventory mismatches, stale dashboards, etc.)

If you can’t measure these, caching will eventually surprise you.

Putting it all together (for a newbie)

If you’re just starting with caching:

Start with Cache-Aside for reads. It’s simple, safe, and easy to reason about.
Add Read-Through if you want a cleaner abstraction and your cache provider supports it.
For writes:
- Use Write-Through when you absolutely need the cache and DB to agree on every write.
- Use Write-Back when you care a lot about write speed and can tolerate a little risk.
- Use Write-Around when you write lots of data that users won’t read immediately.
Whatever you choose, always:
- Set reasonable TTLs,
- Have a plan for invalidating keys,
- And monitor hit rate and latency so you can adjust over time.

With just these five strategies, you can handle most caching problems you’ll run into as a backend engineer.