You mention that records are "altered using DELETE and INSERT not UPDATE". If that's the case then can you confirm that the growth is in the database files alone and not the log files as well?
If you have a lot of throughput and every UPDATE is being doubled as a DELETE/INSERT then you will probably see higher than usual log growth - that should be find so long as your backups are done regularly and the log gets truncated nicely.
I would get a spreadsheet document and start logging data/log sizes each day to see how long before you run out of practical room. (Perhaps you get a nice chart that shows a decent trend line aiming towards your maximum disk space) You don't specify the maximum space available, but even with 1TB plus of storage, you might see disk usage causing I/O issues if its particularly "busy".
If you can show that you are going to reach capacity very soon, it might make for a good argument for management ;)
Things that will lessen the growth (slightly). Converting datetime to datetime2, nvarchar to varchar etc where appropriate will shave some bytes (off the data and the indexes on the data), but you will probably need downtime to do this. Run http://www.brentozar.com/blitzindex/ on key tables, you may find indexes with 0 read counts that can be safely dropped if nobody intends to use them.
Make sure all your tables have good clustered indexes, in my (limited) experience large tables can be halved in size if they don't already have one, and if you follow best practices you get a lot less fragmentation: https://www.simple-talk.com/sql/learn-sql-server/effective-clustered-indexes/
This may buy you time, but only structural changes will solve the root of the problem.